Replacing the options menu in user mods

Here, developers communicate stuff that does not go onto the main News section or the front page of the site.
[Dev Blog] [Development Builds] [Git Change Log] [GZDoom Github Repo]

Moderator: GZDoom Developers

Re: Replacing the options menu in user mods

Postby Graf Zahl » Sun Jun 11, 2017 10:45 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Replacing the options menu in user mods

Postby Rachael » Sun Jun 11, 2017 10:47 am

How about a lexicon in the source that blacklists outdated features and then simply removes them when it encounters them?
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Replacing the options menu in user mods

Postby Graf Zahl » Sun Jun 11, 2017 10:54 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Replacing the options menu in user mods

Postby _mental_ » Sun Jun 11, 2017 10:54 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Replacing the options menu in user mods

Postby Caligari87 » Sun Jun 11, 2017 10:55 am

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.

8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Replacing the options menu in user mods

Postby MTrop » Sun Jun 11, 2017 10:59 am

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).
MTrop
 
Joined: 08 Jul 2013

Re: Replacing the options menu in user mods

Postby Rachael » Sun Jun 11, 2017 11:06 am

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.

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Replacing the options menu in user mods

Postby Jimmy » Sun Jun 11, 2017 11:08 am

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.

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. :?
Jimmy
I picked a fine day to be lactose intolerant
 
 
 
Joined: 10 Apr 2006
Location: Perth, WA
Twitch ID: JimmySquared

Re: Replacing the options menu in user mods

Postby Graf Zahl » Sun Jun 11, 2017 11:16 am

'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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Replacing the options menu in user mods

Postby Graf Zahl » Sun Jun 11, 2017 11:24 am

Rachael wrote:
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.

I don't think that's even necessary.


I need testing material, not material to find out what bad stuff may have been used.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Replacing the options menu in user mods

Postby Rachael » Sun Jun 11, 2017 11:29 am

Graf Zahl wrote: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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Replacing the options menu in user mods

Postby MTrop » Sun Jun 11, 2017 11:42 am

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.


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?
MTrop
 
Joined: 08 Jul 2013

Re: Replacing the options menu in user mods

Postby Arctangent » Sun Jun 11, 2017 11:48 am

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.
User avatar
Arctangent
squawky
 
Joined: 06 Nov 2014
Discord: SquawkyAtan#2371

Re: Replacing the options menu in user mods

Postby AFADoomer » Sun Jun 11, 2017 11:49 am

Graf Zahl wrote:
Rachael wrote:
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.

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.
User avatar
AFADoomer
 
Joined: 15 Jul 2003

Re: Replacing the options menu in user mods

Postby Graf Zahl » Sun Jun 11, 2017 12:01 pm

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?


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.

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.


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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

PreviousNext

Return to Developer Blog

Who is online

Users browsing this forum: No registered users and 1 guest