Fix modoption crash

[GoogleFrog]

[t=00:00:24.799574][f=-000001] [liblobby] Error: [LuaVFS::Include(synced=false)][loadvfs] file=modoptions.lua status=-1 cenv=false vfsmode=Mmeb File not seen by VFS (missing or in different VFS mode)
[t=00:00:24.799733][f=-000001] [liblobby] Error: [LuaVFS::Include(synced=false)][loadvfs] file=modoptions.lua status=-1 cenv=false vfsmode=Mmeb File not seen by VFS (missing or in different VFS mode)
stack traceback:
	[string "libs/liblobby/lobby/observable.lua"]:51: in function '_PrintError'
	[string "libs/liblobby/lobby/observable.lua"]:43: in function <[string "libs/liblobby/lobby/observable.lua"]:43>
	[C]: in function 'UseArchive'
	[string "LuaMenu/widgets/chobby/components/configuration.lua"]:903: in function 'GetModoptions'
	[string "LuaMenu/Widgets/gui_modoptions_panel.lua"]:723: in function 'LoadModoptions'
	[string "LuaMenu/Widgets/gui_battle_room_window.lua"]:372: in function 'SetupInfoButtonsPanel'
	[string "LuaMenu/Widgets/gui_battle_room_window.lua"]:1840: in function 'InitializeControls'
	[string "LuaMenu/Widgets/gui_battle_room_window.lua"]:2201: in function 'eventListener'
	[string "libs/chiliui/chili/controls/object.lua"]:710: in function 'CallListeners'
	[string "libs/chiliui/chili/controls/object.lua"]:260: in function 'SetParent'
	[string "libs/chiliui/chili/controls/control.lua"]:237: in function 'SetParent'
	...
	[string "libs/liblobby/lobby/interface_shared.lua"]:300: in function '_SocketUpdate'
	[string "libs/liblobby/lobby/interface_shared.lua"]:325: in function 'SafeUpdate'
	[string "libs/liblobby/lobby/interface_shared.lua"]:336: in function <[string "libs/liblobby/lobby/interface_shared.lua"]:336>
	[C]: in function 'xpcall'
	[string "libs/liblobby/lobby/interface_shared.lua"]:336: in function 'Update'
	[string "libs/liblobby/LuaMenu/widgets/api_lobby.lua"]:70: in function <[string "libs/liblobby/LuaMenu/widgets/api_lobby.lua"]:69>
	(tail call): ?
	[C]: in function 'pcall'
	[string "LuaHandler/Utilities/crashHandler.lua"]:50: in function 'f'
	[string "LuaHandler/Utilities/specialCallinHandlers.lua"]:80: in function <[string "LuaHandler/Utilities/specialCallinHandlers.lua"]:76>

message(8).txt

I took some code from BAR chobby recently that purported to read modoptions from the game files. My guess is that it is broken somehow, or perhaps that it crashes if you don't have the game that is being hosted (due to modding).

[GoogleFrog]

When I try hosting a mod that I don't have, and then open Options, it just doesn't load the options panel. So I'm not really sure what is going on.

[GoogleFrog]

It happens when hosting FFA, so with stable ZK.

[GoogleFrog]

Fixed by deleting packages, pool and games. I've tried adding a safety too.

[sprunk]

code from BAR chobby recently that purported to read modoptions from the game files.

BAR's code doesn't work too well with modding. If you enter a modded game, F11 and then try to setup a vanilla game (where "modded" and "vanilla" means any two archives such that one is a VFS dependency of the other) it will still show the mod's modoptions. See beyond-all-reason/RecoilEngine#1397

BAR gets to do what they do because they don't support modding ~at all.

[GoogleFrog]

My goal was to support showing modoptions that the mod provides. I think someone wanted it (maybe future wars) and there is a risk that ZK modoptions will break a heavily modded game anyway. If a mod wants modoptions, it can include the vanilla ones, right?

Not being unable to load base ZK modoptions would be a problem (is that what you mean by entering a modded game and setting up vanilla? Is "enter" and "set up" the same operation?) Perhaps it is worth a revert. I had heard for a while that VFS was good enough to read modoptions, but with no examples forthcoming, but I had hoped that BAR had solved it.

[sprunk]

Not being unable to load base ZK modoptions would be a problem (is that what you mean by entering a modded game and setting up vanilla? Is "enter" and "set up" the same operation?)

Here's a dependency chain:

• vanilla ZK
• First Tier Mod, depends (via ./modinfo.lua) directly on vanilla ZK.
• Second Tier Mod, depends on First Tier Mod.

Scenario #1:

• run Chobby.
• use any method (skirmish, multiplayer, campaign - whatever) to get actually ingame (such that commanders spawn) using First Tier Mod. The technical background here is that both FTM.sdz and ZK.sdz archives are loaded into the engine's VFS.
• press F11 to get the Chobby overlay, but stay ingame and do not exit that game, all the following steps depend on the archives staying loaded on the VFS.
• get into any chobby battleroom GUI that lets you set game and modoptions (either skirmish or multiplayer battleroom).
• set game = vanilla ZK in the chobby battleroom GUI.
• click "set modoptions" in the chobby battleroom GUI.

The expected result here is that the popup with modoptions contains vanilla ZK's and not the mod's, because that is what the battleroom is set to (regardless of whether you are doing this from the F11 overlay and have a game running in the background or not; and if you are, regardless of what game).
The actual results in BAR chobby was some mix of errors ("vanilla ZK archive already loaded") and the mod's modoptions being shown (since the VFS has mod files override vanilla's, and both of them contain modoptions.lua).

Scenario #2: same, but go up a dependency tier, meaning get ingame (spawn commanders etc) with Second Tier Mod, then F11 back to chobby's battleroom gui and press the 'set modoptions' button while the battleroom is set to game = First Tier Mod.

The difference compared to scenario #1 is that we could have a hardcoded "make sure ZK itself works no matter what" behaviour but arbitrary mod hierarchies probably can't be hardcoded longterm.