Allow Settings Menu and Main Menu swapping or custom settings.

[MapleWheels]

Good day Undertow,

With the recent overhaul to scripting we've done to evilfactory/LuaCsForBarotrauma, we are now considering implementing a pre-patching system to allow people to have an easier time doing Settings Menu, Main Menu and Prefab patching. However, in order to do so, some changes to menus on the code side are required from upstream or it would break CI since these are changed very often.

I am willing to do the work but I would like to know if this would be accepted in the first place. The proposed changes are some of the following (please indicate which of these are preferred/acceptable to you):

1. Settings Option Registration System to allow plugin developers either via XML and/or by code to register settings and keybinds to be changed. This is how I've done things in Modding Toolkit. This covers >95% of use cases for this change.
2. Allowing plugins to register their own instance of a menu which would be used in lieu of the vanilla menu if available, this would be done by the plugin providing a delegate to a factory method implementing an interface.
3. Extending on 2, alternatively, mark the menu generation functions as public virtual and allow them to override it via inheritance instead of an interface.

I have already made a menu framework mod here that implements the Settings Registration idea from above, what we're trying to do is something similar to this without all of the reflection and cursed code.

If you want to see it in practice, then take a look here and see the screenshots: https://steamcommunity.com/sharedfiles/filedetails/?id=2905375979

If you have any other ideas I am open to suggestions. Thank you for your time.

Regards,

[Regalis11]

Hello!

I agree that this would be a really useful thing to have in the vanilla game.

To me the first option seems the most flexible (although probably also the most complex). I'd assume that options 2 and 3 would make it difficult to get custom settings for multiple mods to show up in the settings.

[MapleWheels]

Yes, I agree that Option 1 is the best one for most use cases. Supporting 2 and 3 would be more of allowing third-parties to implement their own menus for their purposes this would probably only be used by toolkits and frameworks (like mine or LuaCsForBarotrauma) or by mods doing overhauls.

So, we have a few ways of approaching this:
A. Option 2/3 and have LuaCsForBarotrauma (Luatrauma) implement Option 1.
B. Have vanilla implement Option 1 for XML (and core functionality) and Luatrauma implement the CSharp/Lua Extensions.
C. Have vanilla implement the full API and have Luatrauma users simply consume the API.

My thoughts are:

• Option A has the limitation that only Lua and CSharp users can consume the API but is the most straightforward to implement and use. This would essentially be me re-implementing my toolkit in Luatrauma for others to consume.
• Options A and B allow a separation of responsibilities between the Luatrauma and Barotrauma teams as well opinionated differences (Luatrauma allows client-side only mods in multiplayer gameplay whereas vanilla does not).
• Options B and C require the implementation of a vanilla API to allow pure XML to make use of settings and probably will take the most amount of work by far.
  --- We will have to decide what the scope for this new API would be since full integration would mean reworking most XML-affected classes and/or the prefab system to allow streamlined value manipulation. Probably the least intrusive is to just pass the prefab data for user changes through a manipulator between rounds (in-round perf would suffer otherwise).
• Option B and C would be a large benefit to XML modders since it would allow users to change values.

What do you think would work best with the Baro team and the vanilla codebase?

Alternatively, we can take this as a sign to finally rework the menu codebase lol. Not going to lie, the GUI menu components code is pretty cursed/jank (getting sliders to work with nested frames was pain).

[Honkbinger]

@Regalis11

https://barotraumagame.com/baro-wiki/images/5/50/Honk.ogg

[Regalis11]

Sorry for taking so long to get back to this! Our programming team, and our review/QA pipeline are so congested that I think the option that requires the least changes to the vanilla game seems the most realistic, so I suppose Option A looks the most promising? Reworking the whole GUI code unfortunately feels like such an enormous task to pull of at this point, I doubt we have the resources to review and test something that big even if it required no code work from our part.

[MapleWheels]

Sorry for taking so long to get back to this! Our programming team, and our review/QA pipeline are so congested that I think the option that requires the least changes to the vanilla game seems the most realistic, so I suppose Option A looks the most promising? Reworking the whole GUI code unfortunately feels like such an enormous task to pull of at this point, I doubt we have the resources to review and test something that big even if it required no code work from our part.

Understandable. In light of this, I think the best option then for the vanilla codebase is to make a new tab in the settings menu for our use (since it's a hard-coded enum, alternatively reworking this from an enum to a dictionary would be great) and to add a subscriber function for third-party code to submit their own keybinds to show up in the keybinds tab under a new sub-menu.

I'll put together a demo mockup next week so you can better see this. Also @evilfactory .