Replacing the options menu in user mods
Moderator: GZDoom Developers
-
- Lead GZDoom+Raze Developer
- Posts: 49192
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Replacing the options menu in user mods
I'd appreciate solutions that make it possible to add the genuine new options but also weed out all the stuff that is duplicated and/or obsolete. Duplicates should be relatively easy to find but obsolete and removed options are an entirely different matter. The only idea I have is to look for undefined CVARs or CCMDs.
-
- Posts: 13849
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: Replacing the options menu in user mods
How about a lexicon in the source that blacklists outdated features and then simply removes them when it encounters them?
-
- Lead GZDoom+Raze Developer
- Posts: 49192
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Replacing the options menu in user mods
Probably the best idea...
What I really need for testing is a comprehensive set of mods with MENUDEF lumps that replace parts of the option menu.
What I really need for testing is a comprehensive set of mods with MENUDEF lumps that replace parts of the option menu.
-
-
- Posts: 3819
- Joined: Sun Aug 07, 2011 4:32 am
Re: Replacing the options menu in user mods
I think that protection of menus should be optional and disabled by default.
If user wants original menu back he/she can enable this feature even if it will require to restart GZDoom.
Of course we can ask people here how many of them do care about redacted menus.
Sometimes I find this annoying but in general I don't care: console is still available, direct configuration file editing too.
Bad practice or not, if menu replacement was used for years in many mods then it's not good to break their configuration capabilities.
If user wants original menu back he/she can enable this feature even if it will require to restart GZDoom.
Of course we can ask people here how many of them do care about redacted menus.
Sometimes I find this annoying but in general I don't care: console is still available, direct configuration file editing too.
Bad practice or not, if menu replacement was used for years in many mods then it's not good to break their configuration capabilities.
-
- Admin
- Posts: 6196
- Joined: Thu Feb 26, 2004 3:02 pm
- Preferred Pronouns: He/Him
Re: Replacing the options menu in user mods
Just a side note: In my understanding one of the things that makes AddOptionMenu less desirable is that it puts the new entry at the bottom, and in an already long menu that makes it sub-optimal for mods that have a LOT of important options to change. Would there be some way that new entries could optionally be at the top of the list (or maybe have an arbitrary position)?
Also a request from Discord chat: Could it be made to at least not error on start-up and print warnings instead? To explain, it'd work in favor to have them overridden by the internal menus versus outright breaking the ability to load the mod.

Also a request from Discord chat: Could it be made to at least not error on start-up and print warnings instead? To explain, it'd work in favor to have them overridden by the internal menus versus outright breaking the ability to load the mod.

-
- Posts: 59
- Joined: Mon Jul 08, 2013 5:04 pm
Re: Replacing the options menu in user mods
If you make any part of your engine moddable, people are going to mod it, Graf. You cannot get around that.
In our defense, we have been looking for a way to change the options menu in Square in a way that both people can download a standalone release but still have the full options on just the PK3 release, which we are probably going to do, going forward.
The full set of options are just not applicable in a lot of circumstances regarding the game, so I saw it best to not overwhelm those outside the Doom Community with a bunch of options that they will not care about, confuse them, or will ruin the game in some way (disable jump/crouch in a game that requires it? unused inventory controls? chromatic aberration and SSAO in Square's art style? Have you SEEN how bad that looks?). When you are making something with the intent of broadening an audience outside of an intimate community, you have to make decisions regarding accessibility. And G/ZDoom, with all its features, gets more intimidating with each feature added, and we, as programmers, can't expect the layman to know or understand them.
I do like the idea of separating game- and engine-centric options. At least make one of those moddable (the game one, probably).
In our defense, we have been looking for a way to change the options menu in Square in a way that both people can download a standalone release but still have the full options on just the PK3 release, which we are probably going to do, going forward.
The full set of options are just not applicable in a lot of circumstances regarding the game, so I saw it best to not overwhelm those outside the Doom Community with a bunch of options that they will not care about, confuse them, or will ruin the game in some way (disable jump/crouch in a game that requires it? unused inventory controls? chromatic aberration and SSAO in Square's art style? Have you SEEN how bad that looks?). When you are making something with the intent of broadening an audience outside of an intimate community, you have to make decisions regarding accessibility. And G/ZDoom, with all its features, gets more intimidating with each feature added, and we, as programmers, can't expect the layman to know or understand them.
I do like the idea of separating game- and engine-centric options. At least make one of those moddable (the game one, probably).
-
- Posts: 13849
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: Replacing the options menu in user mods
I don't think that's even necessary.Graf Zahl wrote:What I really need for testing is a comprehensive set of mods with MENUDEF lumps that replace parts of the option menu.
Just take the options from the release versions of ZDoom 2.7.1, 2.8.1, GZDoom 1.8.6 and 2.4.0, and find anything that has been removed in 3.1 for these 4 mentioned versions, after weeding out the duplicates.
Your broken MENUDEFs are right in those 4 versions right there, and chances are those are the ones that have been duplicated in the mods themselves.
-
-
- Posts: 4725
- Joined: Mon Apr 10, 2006 1:49 pm
- Preferred Pronouns: He/Him
Re: Replacing the options menu in user mods
Echoing this.MTrop wrote:The full set of options are just not applicable in a lot of circumstances regarding the game, so I saw it best to not overwhelm those outside the Doom Community with a bunch of options that they will not care about, confuse them, or will ruin the game in some way (disable jump/crouch in a game that requires it? unused inventory controls? chromatic aberration and SSAO in Square's art style? Have you SEEN how bad that looks?). When you are making something with the intent of broadening an audience outside of an intimate community, you have to make decisions regarding accessibility. And G/ZDoom, with all its features, gets more intimidating with each feature added, and we, as programmers, can't expect the layman to know or understand them.
Rest assured that Square's menus will be addressed in light of this development, but the above is still very much what rings true for me and I'm sure for a host of other modders who would rather keep their menus simple and straightforward so as to use G/ZDoom for purposes outside of our little community. Rise of the Woolball is an example that springs immediately to mind, and it's kind of crazy that basically a day after being added as an IWAD, it's no longer functioning as it intended.

-
- Lead GZDoom+Raze Developer
- Posts: 49192
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Replacing the options menu in user mods
'Keeping menus simple and straightforward' is a dangerous thing. While you may think that some options can be omitted, that decision is still highly subjective and what's irrelevant for one person is essential for the next. And again: Since the menus can change there is no guarantee that an option you try to delete will forever remain where you try to delete it.
Just take the sound menu as an example: It got a lot of things changed recently due to the removal of FMod. So whatever you decide to do to 'simplify' matters can totally backfire when features are evolving. It can even cause some previously minor option to become very important and vice-versa.
The problem is not ADDING stuff to the existing menus. The real problems arise when people who are not qualified to assess the importance of certain options try to do anyway and decide to remove them.
To be honest, I still think the best course of action for mods that have their own settings is not to put them into the engine's submenus but instead - like BoA - create a new entry in the main menu. It's a lot easier on the users who do not have to deal with changing option menus between mods.
Just take the sound menu as an example: It got a lot of things changed recently due to the removal of FMod. So whatever you decide to do to 'simplify' matters can totally backfire when features are evolving. It can even cause some previously minor option to become very important and vice-versa.
The problem is not ADDING stuff to the existing menus. The real problems arise when people who are not qualified to assess the importance of certain options try to do anyway and decide to remove them.
To be honest, I still think the best course of action for mods that have their own settings is not to put them into the engine's submenus but instead - like BoA - create a new entry in the main menu. It's a lot easier on the users who do not have to deal with changing option menus between mods.
-
- Lead GZDoom+Raze Developer
- Posts: 49192
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Replacing the options menu in user mods
I need testing material, not material to find out what bad stuff may have been used.Rachael wrote:I don't think that's even necessary.Graf Zahl wrote:What I really need for testing is a comprehensive set of mods with MENUDEF lumps that replace parts of the option menu.
-
- Posts: 13849
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: Replacing the options menu in user mods
The latest D4D alphas are broken - Major Cooke wanted me to mention that.Graf Zahl wrote:I need testing material, not material to find out what bad stuff may have been used.
-
- Posts: 59
- Joined: Mon Jul 08, 2013 5:04 pm
Re: Replacing the options menu in user mods
Graf, while I agree with your points in terms of engine features and enhancements, these are largely additional options on top of games that are set-in-stone (Doom, Doom2, etc.) and their importance is assessed in terms of all them. When it becomes options relevant to a mod or (new) game, the importance of non-engine-specific options become subjective to the work.Graf Zahl wrote:'Keeping menus simple and straightforward' is a dangerous thing. While you may think that some options can be omitted, that decision is still highly subjective and what's irrelevant for one person is essential for the next. And again: Since the menus can change there is no guarantee that an option you try to delete will forever remain where you try to delete it.
Just take the sound menu as an example: It got a lot of things changed recently due to the removal of FMod. So whatever you decide to do to 'simplify' matters can totally backfire when features are evolving. It can even cause some previously minor option to become very important and vice-versa.
The problem is not ADDING stuff to the existing menus. The real problems arise when people who are not qualified to assess the importance of certain options try to do anyway and decide to remove them.
To be honest, I still think the best course of action for mods that have their own settings is not to put them into the engine's submenus but instead - like BoA - create a new entry in the main menu. It's a lot easier on the users who do not have to deal with changing option menus between mods.
I'm not sure where the "true balance" lies, though. In the past, adding a new standard and deprecating the old one involved creating a new definition standard (see MAPINFO to ZMAPINFO, for instance). Perhaps the same could be done with MENUDEF (to ZMENUDEF), and all earlier mods get a big, fat warning if it senses a new MENUDEF?
-
- Posts: 1235
- Joined: Thu Nov 06, 2014 1:53 pm
Re: Replacing the options menu in user mods
I think one of the major things worth considering along that line is just flat-out allowing a mod to remove the compatflags menu, maybe through GAMEINFO or something
There's really no reason at all for a standalone thing to have that - if it does use any of 'em, they're going to be messed with in MAPINFO in the first place.
There's really no reason at all for a standalone thing to have that - if it does use any of 'em, they're going to be messed with in MAPINFO in the first place.
-
- Posts: 1339
- Joined: Tue Jul 15, 2003 4:18 pm
Re: Replacing the options menu in user mods
Wolf3D TC replaces the Options menu...Graf Zahl wrote:I need testing material, not material to find out what bad stuff may have been used.Rachael wrote:I don't think that's even necessary.Graf Zahl wrote:What I really need for testing is a comprehensive set of mods with MENUDEF lumps that replace parts of the option menu.
In retrospect, yes, I should have just made the TC's custom options menu open when the user selected the 'Control' option, then have an entry in that that pointed to the internal Options Menu. But the in-place solution made sense (to me) at the time, and there was no AddOptionMenu capability - and at the time, the menu titles hadn't been exported to Language, so this was the only way to customize those, too.
-
- Lead GZDoom+Raze Developer
- Posts: 49192
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Replacing the options menu in user mods
I have to disagree. Especially when you are making an IWAD you cannot assume anything. People may make mods for your game that want to use the features you deem irrelevant. A good example is the Strife popups. They are not used by default in Doom but the bindings are still exposed because some mods out there actually use that feature!MTrop wrote: Graf, while I agree with your points in terms of engine features and enhancements, these are largely additional options on top of games that are set-in-stone (Doom, Doom2, etc.) and their importance is assessed in terms of all them. When it becomes options relevant to a mod or (new) game, the importance of non-engine-specific options become subjective to the work.
I'm not sure where the "true balance" lies, though. In the past, adding a new standard and deprecating the old one involved creating a new definition standard (see MAPINFO to ZMAPINFO, for instance). Perhaps the same could be done with MENUDEF (to ZMENUDEF), and all earlier mods get a big, fat warning if it senses a new MENUDEF?
That's the main issue here: You simply cannot know which options are needed and which are not. Most factors this depends on are outside any mod's control and may depend on what the end user loads along with it.
There's a reason why all compatibility options are active for all games, even when they were introduced by a specific one. They are often not needed for enabling them but just for checking them. So by removing the menu you take away that option from the user. That may fly remotely if you create an IWAD but for any PWAD it is a complete no-go, because the settings may be active and not work in conjunction with the mod - the user needs a way to turn them off.Arctangent wrote:I think one of the major things worth considering along that line is just flat-out allowing a mod to remove the compatflags menu, maybe through GAMEINFO or something
There's really no reason at all for a standalone thing to have that - if it does use any of 'em, they're going to be messed with in MAPINFO in the first place.
This is a typical example of what I meant by saying 'not qualified to assess the importance of certain options'. You people just ASSUME that they may not be relevant and then the odd user out who, for example got these set to 'Doom(strict)' for last playing a vanilla mod, gets stuck because his settings get in the way of the mod which thought it could conveniently disable that menu.