[2.0.60] Removing a mod can invalidate buttons from other mods in mod_gui flow

[Gorfiend7]

If two mods add buttons to the the mod gui button flow (mod_gui.get_button_flow), then one mod is removed from a save, sometimes buttons from the remaining mod become invalid. Whether this happens appears to depend on the order the buttons were added, or possibly the mod load order.

Reproduction steps:

1) Download and enable the attached mods (simple mods to demonstrate this issue - they each create a button in the mod_gui, and reference that button in the button clicked and on_player_cursor_stack_changed events).

2) Start a new game, and make a save.

3) Disable mod "AAAA", then reload the save.

4) Notice that both buttons have been removed from the top-left mod gui flow.

5) Pick up something with your cursor to trigger the event, and observe a crash due to the button now being invalid:

Code: Select all

Error while running event BBBB::on_player_cursor_stack_changed (ID 36)
LuaGuiElement API call when LuaGuiElement was invalid.
stack traceback:
	[C]: in function '__index'
	__BBBB__/control.lua:33: in function <__BBBB__/control.lua:

There appears to be an order dependency here - if in step 3 you instead disable mod "BBBB" and reload the save, the issue does not occur. The button created by AAAA is still in the button flow, clicking it works, and the cursor change event continues to work.

Ideally, removing an unrelated mod should not invalidate buttons created by a different mod, and not be dependent on the order those buttons were created.

[chrisgbk]

This is more of an implementation technicality and an issue in the second mod.

Whichever mod creates mod_gui first owns mod_gui, so if the mod that creates it is removed, those elements (and their child elements, including other mods) are destroyed. This invalidates any saved references in storage.

08-14-2025, 22-09-31.png (98.07 KiB) Viewed 228 times

Every access to an element has to be guarded to account for such things occurring - that's why the valid member exists. if a reference is not valid, then the existence of the element should be queried through the API to check if it still exists and a new reference saved if so, otherwise the element should be recreated if needed.

[Gorfiend7]

I see. That's a bit surprising, but I suppose it makes sense. Thanks for the explanation.

Since this mod_gui is a shared space, I wonder if it would be possible to make it not be owned by a specific mod, or transfer ownership or something instead of destroying it. But maybe that's not realistic.


At least I know what's going on now - I ran into this issue with a couple other mods that started crashing due to an invalid gui element, with seemingly no reason for it to have become invalid. But I think this explains what happened. I would suggest adding a warning/notice about this possibility to the documentation for mod_gui, but does that exist anywhere?

[boskid]

I will classify this as Not a bug.

There are no reasonable behavior changes possible here because having gui owned by a mod X not get deleted when mod X is deleted could possibly leave trash on the screen, and it is not guaranteed that if there are elements inside of a gui element that they will handle removal of the parent gui element that belongs to a different mod. Given that the mod-gui.lua works from a mod context, it falls into the same restrictions as any other gui.