-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Settings Menu and Main Menu swapping or custom settings. #12771
Conversation
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. |
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: My thoughts are:
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). |
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 . |
c6b469b
to
ff56a7d
Compare
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):
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,