Moderator: GZDoom Developers
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.
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.
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.
Graf Zahl wrote:I need testing material, not material to find out what bad stuff may have been used.
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 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.
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?
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.
Users browsing this forum: No registered users and 0 guests