on_gui_element_destroyed

[curiosity]

A new event that is called when a LuaGuiElement is destroyed. It would be great if it was raised before the element is gone, so that you could get the element itself. But if not, the element's common identifying properties should be passed: name, index, player index, tags and parent element.

The purpose of this is to remove any external data related to the element. Right now I need to manage this manually and make sure to destroy all related data of the element I am destroying, and also all of its childrens' data, recursively.

[PFQNiet]

Likely should require registration, similar to entities being destroyed, otherwise a lot of irrelevant events could happen.

[Pi-C]

What about destroying a GUI element with children? If the event was raised just for the one element destroyed directly, it's possible that you don't remove a child element's data from your table. But if a event was raised recursively, for the destroyed element, its child elements, their child elements etc., this could be a lot of events raised on one tick.

Example: One of my mods requires research to unlock a selection tool which players can use to select entities and add them to the GUI. If the technology is unresearched by a force, I remove those GUIs of all players on that force. It's just a simple loop calling player.gui.screen[GUI_name].destroy() for all players, but each GUI could have hundreds of child elements (depending on how many entities the player has added) and raising the event for each individual element could result in some heavy load.

[curiosity]

If I have to go through all children in Lua, that doesn't make any difference.

Regarding the number of events, deletion is a one-time thing, you don't delete and recreate GUIs every tick. And the game already has such events, which it doesn't bother to batch. Compare on_built and placing a big blueprint.

[raiguard]

Looking at the code, I don't think adding this event will be feasible. The problem with adding events is that Lua scripts can break many guarantees that the base game code relies on, so wherever an event is added, we have to refactor away those guarantees and/or add a bunch of checks. Adding these checks would worsen performance when destroying GUIs, and GUI performance is already pretty bad. There is also overhead from the act of calling the event and constructing LuaObjects that would make it even worse.

[curiosity]

Barely more than one LuaObject in my original request, if you count tags. And if you go with the registration route, you could get away with no LuaObjects at all, since a unique registration number will be uniquely identifiable.

(and, TBH, bad GUI performance is hardly an argument to me when they have already refused my offer to improve it)

[boskid]

I am considering this to be implemented for 2.0 as there was "register_on_object_destroyed" implemented which has LuaGuiElement as one of the supported types. Amount of data provided is similar to register_on_entity_destroyed which is basically just the registration number and some useful identifier, anything more if you need to have you can capture from LuaGuiElement on your own inside of script state. Those notifications will have the same characteristics as entity_destroyed notifications: depending when changes happen, event may be raised in current or next tick.

[curiosity]

That's great news, thank you.