-nocustommenu command line parameter

[Rachael]

This would force GZDoom to only use its internal MENUDEF and ignore a mod's custom menus - useful if certain vital options get hidden or if an included menu is outdated.

[Enjay]

Sounds like a good idea.

What would be your thoughts on how this would behave if a game had its own new IWAD (loaded with -IWAD (i.e. not autosupported via gzdoom.pk3) which contained a menudef lump?

[Rachael]

I think it should still use GZDoom's internal menu, depending on the game type that is loaded. The option is meant to be a "safe mode" override and is not intended to be used permanently - only as needed.

[Kinsie]

Should only be added after -nocustomdecorate, -nocustomzscript and -nocustomacs.

[Graf Zahl]

That's nonsense, Kinsie, because those features are gameplay related, but a badly defined menu can seriously screw up the intended UI setup.

[Kinsie]

Isn't D4D adding a fairly extensive upgrades menu that's necessary for gameplay progression? How will that work out? And what about similar gameplay-centric menus that future mods will include, if the ACS kludges seen in Psychic and DRLA are any indication?

This just seems like an edge-case that's kind of a weird alternative to telling some random, very specific mod's developer that their menus need to be updated. (Or just not playing that mod, or fixing it yourself... but where's the fun in either of those?)

[Graf Zahl]

That's not relevant. Read the original post for why this may be needed on occasion.

[Kinsie]

I read it and it still feels like it's in response to something very specific that nobody wants to mention, that could probably be better dealt with by just telling the developer of that very specific thing to make their menus less butt.

[Rachael]

I don't even know what "very specific thing" you are talking about. This is in response to some of the mods that have old MENUDEFs from early-to-mid 2.x versions of GZDoom and/or ZDoom.

[Graf Zahl]

The main issue, as always, is, that some people ignore all warnings they were given and happily create a mess - in this case the warning has been "do not mess around with the main options menu!".
Why the warning? Because, obviously, the menu will see some occasional changes when new features get added or things get refactored. Of course a certain type of modders never considers such banalities when they change things they shouldn't. A mod that adds its own settings in a separate menu will never fall victim to this.

[Major Cooke]

I admit the only reason why D4D has an options menu override is simply to put the D4D options at the top instead of the bottom. If there was something for that, where it would add the options to the top instead of the bottom, I'd gladly use it.

Yes, D4D adds an upgrade/akimbo menu but it's nothing to do with overriding the main options menu itself. That's far out of the way. GZDoom doesn't come with those, obviously. I'm not worried there.

[Graf Zahl]

I admit the only reason why D4D has an options menu override is simply to put the D4D options at the top instead of the bottom

So you effectively put aesthetics above robustness.

I think the best is how BoA does it: A completely separate BoA Options menu in the main menu. If you replace the base Options menu it will definitely break sooner or later.

[Major Cooke]

So you effectively put aesthetics above robustness.

No. I like being able to double tap enter and getting straight into the D4D options menu. Besides, I watch the changelogs DAILY. If I see something that changes it, I'm quick to act. It'd be nice to have something that can change it though so I don't have to worry about it -- but again, up top.

Yeah I suppose I could consider main menu variant...

[Kinsie]

Just use AddOptionMenu like the rest of us peons. If you feel so strongly about having the option up-top, commit AddOptionMenuButItsOnTheTop to the engine.

Having two separate "Options" selections on the main menu is kinda dumb, and there are more graceful ways to do it even in the current setup.

[Graf Zahl]

Besides, I watch the changelogs DAILY.

Can you guarantee that you still do this 5 years down the line? That's incredibly shortsighted thinking and I can guarantee you that your mod is no reason not to refactor the options menu if some internal changes need it - like the scaling cleanup.

And thanks for convincing me that the only viable option here is not just a new command line parameter but outright blocking the replacement of the main options menu. Even though this may inconvenience a few mods, the alternative would be bogus bug report of people not finding the scaling options and other stuff.