Replacing the options menu in user mods

[Graf Zahl]

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.

[Rachael]

How about a lexicon in the source that blacklists outdated features and then simply removes them when it encounters them?

[Graf Zahl]

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.

[_mental_]

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.

[Caligari87]

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.

[MTrop]

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).

[Rachael]

What I really need for testing is a comprehensive set of mods with MENUDEF lumps that replace parts of the option menu.

I don't think that's even necessary.

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.

[Jimmy]

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.

Echoing this.

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.

[Graf Zahl]

'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.

[Graf Zahl]

What I really need for testing is a comprehensive set of mods with MENUDEF lumps that replace parts of the option menu.

I don't think that's even necessary.

I need testing material, not material to find out what bad stuff may have been used.

[Rachael]

I need testing material, not material to find out what bad stuff may have been used.

The latest D4D alphas are broken - Major Cooke wanted me to mention that.

[MTrop]

'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.

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?

[Arctangent]

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.

[AFADoomer]

What I really need for testing is a comprehensive set of mods with MENUDEF lumps that replace parts of the option menu.

I don't think that's even necessary.

I need testing material, not material to find out what bad stuff may have been used.

Wolf3D TC replaces the Options 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.

[Graf Zahl]

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?

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!

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.

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 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.

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.