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]

Moderator: GZDoom Developers

Re: Replacing the options menu in user mods

Postby Arctangent » Sun Jun 11, 2017 12:23 pm

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

I can't help but feel that disabling the menu should also disable the presets.

Especially considering I'm talking about a method of doing so that doesn't involve sneakily removing it from MENUDEF. If the player has no way of accessing the the compatflags menu, and the engine very well knows this, why would something within it stay relevant? I suppose it could still be changed through compatmode, but I dunno. Maybe just flat-out disabled user-defined compatflags would make sense in this sort of context, given that nearly all of those flags stem from a game that may not be remotely related to the standalone currently at hand.
User avatar
Arctangent
squawky
 
Joined: 06 Nov 2014
Discord: SquawkyAtan#2371

Re: Replacing the options menu in user mods

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

That may work - of course the decision making really needs to be completely detached from MENUDEF then.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Replacing the options menu in user mods

Postby Caligari87 » Sun Jun 11, 2017 12:31 pm

IMO disabling features because the menu has been altered is a really bad idea that can't account for every possible use case.

The truth is, if your project is so far removed from stock GZDoom that you MUST hide all those options, then you should be shipping a standalone engine with an edited gzdoom.pk3. Anything intended to run with the player's stock install shouldn't screw with stuff like that.

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 Tapwave » Sun Jun 11, 2017 12:31 pm

Graf Zahl wrote:That may work - of course the decision making really needs to be completely detached from MENUDEF then.

We could work out specific compatflags for IWADs and put them in GAMEINFO along with the compat-menu disabling option? That way it would make sure the proper flags are used without too much tinkering.
User avatar
Tapwave
On the GREEN!
 
Joined: 20 Aug 2011
Discord: Insulting#2455

Re: Replacing the options menu in user mods

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

Most compat flags can already be set through MAPINFO. These settings will always take absolute precedence and override anything else (because it can be assumed that if a map explicitly sets a specific value for a flag, that specific value is needed to run the map without errors.)
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Replacing the options menu in user mods

Postby Tapwave » Sun Jun 11, 2017 12:37 pm

Graf Zahl wrote:Most compat flags can already be set through MAPINFO. These settings will always take absolute precedence and override anything else (because it can be assumed that if a map explicitly sets a specific value for a flag, that specific value is needed to run the map without errors.)

Alright, sounds sensible. Should the option-hiding thing should be in MAPINFO too, then?
User avatar
Tapwave
On the GREEN!
 
Joined: 20 Aug 2011
Discord: Insulting#2455

Re: Replacing the options menu in user mods

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

I replaced the code with a menu merging logic now. Testing with Adventures of Square it looks like it picks the correct stuff, although there have been a few additions to the menu that I find a bit odd...

This is as far as I am willing to go here. This should preserve all newly added options but at the same time keep the protected menus intact.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Replacing the options menu in user mods

Postby ZZYZX » Sun Jun 11, 2017 5:32 pm

People can still hide the engine options with the main menu override. Sounds silly, doesn't make sense. Unless you want to block any modifications to the menus so that no one can replace anything anymore.
All you did here is breaking compatibility with old mods (I remember even Brutal Doom does that, Total Chaos does that, Nash's thing does that, every 4th mod does that actually) prematurely even before they tried to use nonexistent settings.

(got poked by Major Cooke elsewhere and pointed at this thread, hi)
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: Replacing the options menu in user mods

Postby Rachael » Sun Jun 11, 2017 5:42 pm

That's beside the point, ZZYZX - this wasn't trying to block people hiding the menu options, this was to block outdated menus from overriding the stock ones as they get updated.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: Replacing the options menu in user mods

Postby ZZYZX » Sun Jun 11, 2017 5:44 pm

Not beside. If I want to implement my own options menu, now I just need to hide the default one in the main menu and make a new item that opens my custom options menu for "options" line, which then can be outdated in future versions.
It won't change anything. The problem is not solved, but old mods already broken.

How many people are there that open the options menu directly by console command or a bind? Because those are the only ones who will be able to open the original non-replaced options menu after the main menu edit.

edit: directly related: http://www.mediafire.com/file/6vbbl067i ... eplace.pk3
pls stop breaking compatibility.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: Replacing the options menu in user mods

Postby GFD » Sun Jun 11, 2017 6:15 pm

Graf Zahl wrote:'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.
The simplest solution to deterring modders from overriding menus to make them more user-friendly is probably for the GZDoom developers to do it themselves. This has the added benefit of making the menus more user-friendly. Everyone wins!

The mod I've been working on is also one intended to reach a larger audience, and I also came to the conclusion that the menus needed to be simplified and made more user-friendly in order to achieve this effectively. (See: this comic edit Ed the Bat found.) My solution (made before the ability to add onto existing menus, and reached after quickly realizing that my redefining of the default menus was not a good plan) was to link to my "friendlier" options menu from the main menu, and keep ZDoom's default and fully-featured options menu, completely unmodified, inside an "advanced menu" item at the bottom of my options menu.

I think it'd be great if GZDoom did this itself: create a new, friendlier options menu to be the default, and keep the full "advanced" menu accessible from within it. The developers / community can assess for themselves the importance of all the available options to the layman, and work on making this new basic menu as user-friendly as possible. There should also be a new option within the advanced menu to make it appear instead of the basic menu when accessing "options" from the main menu.

In particular, one thing I think GZDoom desperately needs is full descriptions for menu items so that users can read up to learn exactly what all the settings do, rather than guessing based on their limited presentation. Long descriptions for menu options are available on the wiki, so it'd make sense for these to be available in-engine as well. There are a couple ways this could be done. One method (used by the Dolphin Emulator and DOOM 2016, for example) is to have a dedicated area at the bottom of the screen for showing a description of the selected menu item (and its options, if applicable). Another option is adding a way to access a "help" pop-up for any menu item, which brings up a scrollable text window, to ensure descriptions of any size can be used. Possible methods for accessing "help" include a (?) button that appears next to every item, or one in a corner that the user can activate to make the next menu item they activate bring up the help for it. A dedicated keybind (eg. right mouse button, shift key) for activating help would also be nice. In general, this description feature could also be used to display other relevant information, such as which file/mod added the option, and exactly what CVAR the menu option controls (should be an opt-in setting so as not to be an information overload for basic users).

Additionally, in making my own basic menu, I changed the names, presentation, and location/categorization of a bunch of the standard options because I found GZDoom's presentation of them inaccurate or misleading. I spent a lot of time working on this (though it was a while ago), so I'd love to contribute to a discussion about doing this in GZDoom proper.

(This post kind of turned into a feature suggestion as I wrote more about it. I'll still post it here—I did write it in response to this discussion on replacing options menus, after all—but mods can break this off into a separate Feature Suggestion thread if they want.)
User avatar
GFD
My brain's probably worth a lot of money!
 
Joined: 31 May 2010
Location: Canada

Re: Replacing the options menu in user mods

Postby Graf Zahl » Mon Jun 12, 2017 2:01 am

ZZYZX wrote:Not beside. If I want to implement my own options menu, now I just need to hide the default one in the main menu and make a new item that opens my custom options menu for "options" line, which then can be outdated in future versions.
It won't change anything. The problem is not solved, but old mods already broken.

How many people are there that open the options menu directly by console command or a bind? Because those are the only ones who will be able to open the original non-replaced options menu after the main menu edit.

edit: directly related: http://www.mediafire.com/file/6vbbl067i ... eplace.pk3
pls stop breaking compatibility.


This was about modders being careless with what they replaced, mostly because they did not realize what the consequences could be. The triggers for me were the MENUDEFs in Adventures of Square and D4D which hid important new options and brought back some obsolete old ones, being a genuine danger that users could misconfigure their game. This will especially become more dangerous because the 'Display options' menu is in desperate need of getting cleaned up, especially getting the system and the game options mixed in there properly separated.

I cannot do much about modders being assholes aside from retroactively dealing with their output. If you want to be an asshole and someone complains about your mod I could point the finger at you and say 'This guy just wanted to make his mod destructive.' For those edge cases there's the new command line option. But in the end the user can still just press F4 or type 'menu_options' in the console to get the real options menu instead of your butchered version. With an outdated replacement of the menu that would not have been possible anymore.

And let me be abundantly clear on this: I wouldn't mind one bit considering a compatibility setting that disables really badly behaving menus by adding a MENUDEF blacklist if some jerk thinks it is a good idea to do such shit.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Replacing the options menu in user mods

Postby Graf Zahl » Mon Jun 12, 2017 2:07 am

GFD wrote:
Graf Zahl wrote:'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.
The simplest solution to deterring modders from overriding menus to make them more user-friendly is probably for the GZDoom developers to do it themselves. This has the added benefit of making the menus more user-friendly. Everyone wins!


If you think that is needed we need some intended *USER* reworking the menus in a more user friendly fashion. Keep in mind that the developers are all seasoned programmers which tend to see things very differently and even may see user-friendliness in very different ways.

Yes, I know there are some issues with the menus, like I said, the Display Options menu is quite a mess, but I do not think they are that bad. And never forget that one person's irrelevant side-option may be another person's most essential setting.

But very obviously, any mod that starts tinkering with in-game option runs the risk of getting made obsolete by engine advancements. The FMod related sound options are a good example, there was quite a bit of stuff that got removed along with FMod.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Replacing the options menu in user mods

Postby ZZYZX » Mon Jun 12, 2017 2:10 am

Graf Zahl wrote:But in the end the user can still just press F4 or type 'menu_options' in the console to get the real options menu instead of your butchered version.

Have you tried? :lol:
Doesn't really matter though, got your point. Even though I think that hiding mod options instead isn't a good idea. Just like I said, BD is probably unconfigurable now, as I remember it was using a custom item in the Options menu.
Last edited by ZZYZX on Mon Jun 12, 2017 2:15 am, edited 2 times in total.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: Replacing the options menu in user mods

Postby Nash » Mon Jun 12, 2017 2:12 am

Graf, stop it with these imaginary enemies. No mod author is trying to be an asshole on purpose. We just wanted to design simpler menus for non-community users. There is absolutely zero malice involved.

We get your point, tinkering with engine menu is bad. You can't blame us though; there was no other friendly way to do it, modders were constantly asking for more robustness for custom menudef but a lot of menudef-related feature suggestions were ignored for years and then one day chucked into the bin during the forum cleanup, it's a miracle the AddMenuOption one even got noticed.
User avatar
Nash
Nash Muhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia

PreviousNext

Return to Developer Blog

Who is online

Users browsing this forum: No registered users and 2 guests