Add Modes

[keithharvey]

Closes #1040

Summary

Creates a dedicated Sharing tab that loads the game's modes/sharing/*.lua presets, applies per-mode values/locks/visibility, and shows ranked eligibility. Enables clean separation between sharing policy configuration and gadget implementation.

Changes

• New Sharing tab with Mode dropdown and organized category sections
• Load and apply declarative modes: set values, lock controls, hide rows
• Read the declarative ModeConfig presets from modes/sharing/
• Visual lock indicators with read-only overlays
• Display "Not Ranked" badge and communicate ranked eligibility to lobby (Note: this is currently ranked=true for every sharing mode)

Screenshot of BAR changes without this PR

This screenshot shows the BAR side WITHOUT the Chobby side. As you can see, it still works just fine, and this demonstrates specifically what this Chobby PR specifically does:

• populate the Sharing Mode dropdown
• hides and locks mod options based on the selected sharing mode

Related PRs

BAR: beyond-all-reason/Beyond-All-Reason#5704
Architecture: beyond-all-reason/Beyond-All-Reason#8018
Issue: #1040

Why

Moves sharing configuration from scattered individual modoptions to coherent, mode-driven policies. Players choose high-level intent (Enabled, Disabled, Easy Tax, Tech Core, Customize) rather than manually configuring multiple interdependent options.

Screenshots

(See the bar PR)

LLM Disclosure

The Chobby part of this PR was generated with grok-code-fast-1. I’d already written and reviewed and had a JSON version, then manually implemented the lua sharing mode type, each of the modes and modoption changes on the BAR side. I asked the model to update Chobby to match the new declarative format—needed only minor fixes, and it performed well. LGTM after full review.

[AntlerForce]

Marked as draft because I tested and this isn't working as-is. With BAR on branch pr/5074 and BYAR-Chobby on branch pr/1041 clicking on Skirmish does nothing and produces the following error:
[t=00:00:20.320549][f=-000001] [Chili] Error: in `Battle Room Window`:singleplayerWrapper : [string "LuaMenu/Widgets/gui_modoptions_panel.lua"]:1432: attempt to index global 'json' (a nil value) [t=00:00:20.322711][f=-000001] [Chili] Error: stacktrace: [C]: in UseArchive [string "LuaMenu/Widgets/gui_modoptions_panel.lua"]:1439: in LoadModoptions [string "LuaMenu/Widgets/gui_battle_room_window.lua"]:950: in SetupInfoButtonsPanel [string "LuaMenu/Widgets/gui_battle_room_window.lua"]:3209: in InitializeControls ... (18 calls) [string "LuaHandler/Utilities/specialCallinHandlers.lua"]:229 [string "libs/chiliui/chili/controls/object.lua"]:277: in SetParent [t=00:00:20.322772][f=-000001] [Chili] Error: In widget: Battle Room Window
infolog (22).txt

[keithharvey]

Converting this to draft again. It is technically ready for review (and entirely functional) on this side but the BAR side is not quite feature complete yet so holding off until the whole package is ready to go.

[burnhamrobertp]

When a mode has allowRanked false this forces ranked_game to '0', but I don't see anywhere that sets it back when you switch to a mode that does allow ranked. So if I pick a non-ranked mode and then switch back to a ranked one, won't ranked_game stay at '0'? And since it goes out through SetModOptions as a normal value change, I think it actually gets sent to the host, not just shown locally. It's also easy to miss because SetRankedModeAllowed just below doesn't seem to be defined anywhere, so nothing updates the battle-room UI. Could this restore ranked_game on the allowRanked path?

[burnhamrobertp]

This only sets or clears lockedOptions for keys that are in the new mode's modOptions, and lockedOptions itself looks like it's only reset when the window is first created, not here. So if mode A locks an option and you then switch to a Customize/retain mode that doesn't list it, won't that key keep its old lockedOptions entry and then get overwritten with the server value on Accept? I think someone who had set that option would see it silently revert. Would resetting lockedOptions at the top of applyMode, the same way modeLocked is rebuilt, fix it?

[burnhamrobertp]

This calls .get('categories') straight on whatever _modes() returns. If the fetched or cached json is ever not an object (a list, say), won't that throw an AttributeError right into the perl bridge? The accesses below it go through _as_dict but this first one doesn't. Could the top level be wrapped the same way?

[burnhamrobertp]

The user's key gets lowercased up at line 209, but locked_keys is built from the mod_options keys as-is. So if a mode locks 'ResourceMult' and someone passes resourcemult=something, won't this check miss it and apply the override anyway? I think BAR option names are all lowercase in practice so it may not bite today, but it makes the lock weaker than it looks. Lowercasing both sides would close it.

[burnhamrobertp]

This is a synchronous urlopen on what I understand is SPADS's single thread, with a 5s timeout and up to two URLs, so a slow or unreachable release could stall the host for around 10s on the first !mode after a rehost. From what I can see the vote-eligibility check reaches it too, which a normal player can trigger. It's once per version so not constant, but a multi-second freeze of the autohost still seems bad. Could this be backgrounded or moved to load time?

[burnhamrobertp]

I'm not deep in the SPADS side or a lot of this Lua, so some of this might be me misreading it.

1. Fetching game_modes.json over the network at runtime. The plugin pulls it from a GitHub release the first time someone runs !mode after a rehost. Is there a reason it has to be fetched at runtime instead of shipped inside the game archive the host already has synced? I get that the host can't regenerate it itself since it's baked in CI from the modes lua, but if CI is already producing the file, couldn't it be bundled into the archive so the host just reads it locally? My worry with the release fetch is that the failure modes are all silent: if the asset is missing, or the host's network is locked down, or the slug doesn't match, the host just quietly serves stale or empty data, which seems painful to debug for whoever is running the host.

2. How do we guarantee the host's modes match the version players are actually on? From what I can tell the right file is picked by slugifying the game's display name, and the schemaVersion field in the json isn't read by anything. If the pinned asset isn't there it falls back to a rolling channel file that isn't tied to the hosted version. Won't that let the host apply one version's settings while clients read a different version's modes out of the archive, with nothing flagging the mismatch? Even just checking schemaVersion and logging loudly when it falls back would help, I think.

3. The expansion logic lives in two places. The rule that turns a mode into its full set of modoptions is in the Lua resolver (moderesolver.lua) and again in the CI generator that bakes the json, in two different languages, and I don't see anything testing that they agree. Since the drift between copies looks like what caused several of the regressions this PR is already fixing, would a shared fixture or a test that runs both and compares be worth it? Otherwise I think it just drifts again the next time someone touches one side.