Consistency issues in events on_placed/removed_equipment

[LiroxDeYamon]

Hello!

Its really hard to do things with equipment as their events are inconsistent in naming, behavior and provided data.
Below is what i noticed so far an how I suggest fixing it.

Naming:
on_equipment_inserted and on_player_placed_equipment have different names ("inserted" != "placed"),
while on_equipment_removed and on_player_removed_equipment are consistent enough.
1. Doesn't really needs fixing, but it'll be nice to have consistent naming,

Behaviour:
equipment_inserted events are called per-item,
while equipment_removed events are called once.
2. I suggest changing equipment_removed events to be called per equipment removed.

Provided data:
equipment_inserted events provide equipment as LuaEquipment
but inside equipment_removed events its apparently just a string (I understand that it also has count, but its inconvenient).
All the equipment events lack ItemStack that was used/produced;
My suggestions are:
3. Include ItemStack that was used/produced
4. With suggestion 2 - provide equipment as LuaEquipment OR without suggestion 2 - provide table with all removed equipment

I wonder if any of this even possible to implement, but thanks in advance!

[Rseding91]

Unfortunately #1 #3 is just not currently viable due to how many places and ways the event can be sent (the current count is 15 places across robots, mods, direct player actions, copy-pasting spidertron settings and so on). #2 #4 is not possible because by the time the equipment is removed - it is gone - deleted - no longer exists. So, there is no equipment to provide in any event.

[LiroxDeYamon]

Interesting, what about ItemStack (#3)?

[Rseding91]

Sorry, I meant #3 and #4. I updated the post.

[BraveCaperCat]

Unfortunately #1 is just not currently viable due to how many places and ways can send the event (the current count is 15 places across robots, mods, direct player actions, copy-pasting spidertron settings and so on). #2 is not possible because by the time the equipment is removed - it is gone - deleted - no longer exists. So, there is no equipment to provide in any event.

#1 can be done very easily...
Just find all instances of "on_player_placed_equipment" and replace them all with "on_player_inserted_equipment". (or "on_equipment_inserted" and "on_equipment_placed")

No? When an equipment is removed, it's placed in the inventory of the player/robot/whatever that removed it, unless it was deleted by a script. (in which case, it wouldn't be removed by a player) Even if it then turns into a LuaItem, we should at least get that LuaItem. Also, #2 refers to making the `equipment_removed` events be called for each equipment removed and not about providing the equipment. (that's #4)

[LiroxDeYamon]

Unfortunately #3 is just not currently viable due to how many places and ways can send the event (the current count is 15 places across robots, mods, direct player actions, copy-pasting spidertron settings and so on). #4 is not possible because by the time the equipment is removed - it is gone - deleted - no longer exists. So, there is no equipment to provide in any event.

#1 can be done very easily...
Just find all instances of "on_player_placed_equipment" and replace them all with "on_player_inserted_equipment". (or "on_equipment_inserted" and "on_equipment_placed")

No? When an equipment is removed, it's placed in the inventory of the player/robot/whatever that removed it, unless it was deleted by a script. (in which case, it wouldn't be removed by a player) Even if it then turns into a LuaItem, we should at least get that LuaItem. Also, #2 refers to making the `equipment_removed` events be called for each equipment removed and not about providing the equipment. (that's #4)

#2 is kinda useless without #4
Btw, how does the event provide equipment name and quality if the instance is already gone?

[Rseding91]

#2 is kinda useless without #4
Btw, how does the event provide equipment name and quality if the instance is already gone?

Recording the ID (name and quality) before removing the equipment is simple. In Lua terms its as simple as:

Code: Select all

local name = equipment.name
local quality = equipment.quality.name
grid.take(equipment)
send_equipment_removed(name, quality, 1)

[LiroxDeYamon]

#2 is kinda useless without #4
Btw, how does the event provide equipment name and quality if the instance is already gone?

Recording the ID (name and quality) before removing the equipment is simple. In Lua terms its as simple as:

Code: Select all

local name = equipment.name
local quality = equipment.quality.name
grid.take(equipment)
send_equipment_removed(name, quality, 1)

So equipment is accessible before the event, thats interesting.
What if you just save all of the data as LuaEquipment but readonly? Like, not the link to the object, but deepcopy?
This could solve #4 if paired with #2.

What about ItemStack? does grid.take(equipment) output ItemStack?

[Rseding91]

So equipment is accessible before the event, thats interesting.
What if you just save all of the data as LuaEquipment but readonly? Like, not the link to the object, but deepcopy?
This could solve #4 if paired with #2.

This is asking for a complete re-write of how LuaObjects work on the engine side and is not something I have any interest in attempting.

What about ItemStack? does grid.take(equipment) output ItemStack?

It does not and that goes back to what I first mentioned: the number of ways and number of places that both put and take equipment are spread across too many places to be worth attempting something like this. The logic that does the evening is separate from the logic that does the actual changes to the equipment grid so there's no way for the event logic to know which stack(s) any equipment came from (if any) or which stack(s) the equipment went to (if any).

[LiroxDeYamon]

This is asking for a complete re-write of how LuaObjects work on the engine side and is not something I have any interest in attempting.

Ok then what about extra data table containing equipment's shield, max_shield, energy, max_energy, etc?
You already provide some data like name and quality, so that prob shouldn't be that hard to implement.