Luamenu currently has widget:ActivateGame and widget:ActivateMenu to help the lobby overlay hide and activate itself when a game is loaded behind it. However, widget:ActivateGame seems to be called when the game finishes loading, rather than when it starts. This leads to the following bug:
Set up a singleplayer, locally hosted, game.
Click start
Keep your mouse still so it is still hovered over the start button.
Wait until the game has loaded 50%.
Click the mouse again.
Observe how the game finishes loading, then restarts and loads again. This happens because your second click was a click on the start button.
The lobby should have hidden itself as soon as the load screen appears, but instead, it acts as if it is hiding "behind" the load screen. My understanding of the load screen was that every lua state was suspended (apart from the lua load screen), so clicking on start was not a concern. Or perhaps the mouse click is buffered and sent to LuaMenu before widget:ActivateGame occurs, but I put echos on the start button that indicate that this is not the case. I don't know if this is a new bug, or if something changed in the years since I last looked at this area.
Interestingly, Spring.GetGameName() returns the name of the game that is loading. However, this doesn't help that much, because players can legitimately start a game by switching to the lobby and pressing start, even when a game is running. In this case, Spring.GetGameName() would not change, so it cannot be relied on to indicate when a game starts loading.
Another option is for LuaMenu itself to remember when it sends a Spring.Restart or Spring.Reload, and activate its own "Game Loading" behaviour. This would work most of the time, but open the door for spaghetti code and fudgy timers, and the stakes are too high. I say this because:
Spring has a delayed reaction to Spring.Reload. It used to reload instantly, taking away control from LuaMenu, but now the window sits there briefly and the lobby is fully interactable for that time.
I don't want to 100% rely on Spring.Reload doing anything at all, and load times can be quite long.
Mistakes in this area, ie blocking lobby interactions too strictly, will lead to bugs where players can't interact with anything at all, until they restart the whole program.
My suggestion is that the engine supply widget:StartLoadingGame. This would trigger when the loading screen appears. Chobby would use it to switch to the ingame UI, making the start button unclickable.
Luamenu currently has widget:ActivateGame and widget:ActivateMenu to help the lobby overlay hide and activate itself when a game is loaded behind it. However, widget:ActivateGame seems to be called when the game finishes loading, rather than when it starts. This leads to the following bug:
The lobby should have hidden itself as soon as the load screen appears, but instead, it acts as if it is hiding "behind" the load screen. My understanding of the load screen was that every lua state was suspended (apart from the lua load screen), so clicking on start was not a concern. Or perhaps the mouse click is buffered and sent to LuaMenu before widget:ActivateGame occurs, but I put echos on the start button that indicate that this is not the case. I don't know if this is a new bug, or if something changed in the years since I last looked at this area.
Interestingly, Spring.GetGameName() returns the name of the game that is loading. However, this doesn't help that much, because players can legitimately start a game by switching to the lobby and pressing start, even when a game is running. In this case, Spring.GetGameName() would not change, so it cannot be relied on to indicate when a game starts loading.
Another option is for LuaMenu itself to remember when it sends a Spring.Restart or Spring.Reload, and activate its own "Game Loading" behaviour. This would work most of the time, but open the door for spaghetti code and fudgy timers, and the stakes are too high. I say this because:
My suggestion is that the engine supply widget:StartLoadingGame. This would trigger when the loading screen appears. Chobby would use it to switch to the ingame UI, making the start button unclickable.