[1.1.55] Changing controller type clears LuaPlayer::opened but does not close custom GUI

[robot256]

Normal behavior:

1. Open the player inventory or entity GUI.
2. Observe that `player.opened` is set to this GUI (with e.g. `/c game.print(game.player.opened)`)
3. Change the player controller type (e.g. `/c game.player.set_controller{type = defines.controllers.god}`)
4. Observe that the inventory or entity GUI is closed.
5. Observe that `on_gui_closed` event is triggered.
6. Observe that `player.opened` is now nil.

Unexpected behavior:

1. Create a custom LuaGuiElement window and display it for the player.
2. Assign the custom LuaGuiElement window to `player.opened`. (This means it will be closed when the player presses "Escape", "E", or opens an entity, just like a vanilla GUI.)
3. Observe that `player.opened` is correctly set to this GUI (with e.g. `/c game.print(game.player.opened)`)
4. Change the player controller type with `player.set_controller{type = defines.controllers.god}`
5. Observe that the custom GUI remains visible.
6. Observe that `on_gui_closed` event is not triggered (in fact, no event is triggered).
7. Observe that `player.opened` is now nil.
8. Press E to open player inventory over top of the custom GUI.

What I expected to happen: That setting LuaPlayer::opened to the custom GUI would cause it to be closed upon using LuaPlayer::set_controller(), just like vanilla GUIs are. Or that there would be an event raised when the controller is changed, so that I can reassign player.opened correctly.

[Loewchen]

88294

The doc is quite clear as well:

This is only called if the player explicitly closed the GUI.

It's not advised to open any other GUI during this event because if this is run as a request to open a different GUI the game will force close the new opened GUI without notice to ensure the original requested GUI is opened.

[Pi-C]

Unexpected behavior:

1. Create a custom LuaGuiElement window and display it for the player.
2. Assign the custom LuaGuiElement window to `player.opened`. (This means it will be closed when the player presses "Escape", "E", or opens an entity, just like a vanilla GUI.)
3. Observe that `player.opened` is correctly set to this GUI (with e.g. `/c game.print(game.player.opened)`)
4. Change the player controller type with `player.set_controller{type = defines.controllers.god}`
5. …

What I expected to happen: That setting LuaPlayer::opened to the custom GUI would cause it to be closed upon using LuaPlayer::set_controller(), just like vanilla GUIs are. Or that there would be an event raised when the controller is changed, so that I can reassign player.opened correctly.

I've given some thought to requesting new events for players changing their controller types, similar to on_pre_player_toggled_map_editor and on_player_toggled_map_editor. I guess editor mode is more special, though (e.g. if player.character exists, it will be set to nil -- same as with god mode -- but in addition, the character will also be backed up and removed from the surface, to be restored when the player leaves editor mode again). Switching to god mode is more simple: no need to use set_controller there, it's enough to set player.character = nil. This could happen when mods exchange the player's character (e.g. "Jetpack" might temporarily put you in god mode when your default character is replaced with the flying version). Therefore, something like on_player_toggled_god_mode would be triggered more often than you'd like.

Side node: `player.set_controller{type = defines.controllers.editor}` will put you into editor mode without raising an event, while `player.toggle_map_editor()` would raise both on_pre_player_toggled_map_editor and on_player_toggled_map_editor. That's given me some headaches as I've got to make sure that the player really has the expected controller type …

[Klonan]

I've given some thought to requesting new events for players changing their controller types

Yea actually I have had similar problems before, player controllers being changed without any event,
I think a catch all event, like 'on_player_controller_changed' would be perfect

[Pi-C]

Yea actually I have had similar problems before, player controllers being changed without any event,
I think a catch all event, like 'on_player_controller_changed' would be perfect

This coming from you is good news!

Actually, I like the way this is currently working for the editor mode. It would be useful to split this catch-all event as well, so there'd be 'on_pre_player_controller_changed' firing before and 'on_player_controller_changed' firing after the change. For my use case, I wouldn't have to rely on other modsplayers using my remote interface and would still be able to store the character's properties while it's attached to the player when they change the controller by other means.

[robot256]

I agree that an event on_player_controller_changed would solve a lot of problems. But I also wonder if the game should be responsible for save-and-restore of the player.opened state when it knows the open GUI was not actually closed during the change. It seems cumbersome for every mod that includes a custom "active gui" to need to react to the controller change, when the only thing to do is check if they are still visible and reassign player.opened.