Mod CVARs are not grouped by mod

[Kotti]

I noticed this while making some experiments with D4D.
CVARINFO has no facilities to group its content by mod, so if two mods happen to use the same CVAR name, it will actually be the same CVAR. Looking at the INI file seems to confirm it. It all gets dumped into either [Doom.Player.Mod] or [Doom.LocalServerInfo.Mod].

[Graf Zahl]

This just seems to be the tip of the iceberg. The entire config handling is poorly equipped to handle such broad gameplay mods in a robust fashion.

[Korell]

Personally, I use a separate ini file for each game/mod that I play with GZDoom, using a batch file with the necessary GZDoom parameters for each one. This way, any custom commands and settings that I use are kept for just the game/mod in question. Whilst I can understand why you might want to put all of the settings into a single ini file, I think it could lead to some very large ini files over time if someone plays a lot of different mods, and then if ever there are two or more different mods with the same name (or two different versions of the same mod that you switch between) then with a single ini file it could confuse which one the settings are for. If it were possible for GZDoom to create new ini files for each mod based on the primary gzdoom.ini file (say gzdoom-<username>-<modname>.ini then could that work around this issue?

[Graf Zahl]

I don't think it needs to go that far. Just replacing '.Mod' in the section names with the WAD name containing the CVARINFO lump would fix the problem.

[Caligari87]

I'd be overjoyed if that could be made to cover the Weapon State keybinds too

[Graf Zahl]

Since you mention it: Keybinds not defined through KEYCONF are also a big problem because they are not mod specific.
The entire config handling needs a serious workover for mods that add new content through CVARINFO and KEYCONF.
ZDCMP2, for example tends to leave garbage behind in the global Doom namespace everytime it is played.

[Rachael]

Well with that in mind, provisions should be made for child ports doing that, as well. Zandronum defines a lot of CVars that never get used by GZDoom and GZDoom just tosses them into the "unknown" section when it finds them. Of course, this will have to be well commented in the source hopefully obviously enough so that they find it when they do their merge.

[Graf Zahl]

That's different.
ZDoom stores CVARINFO based variables in a special section - but there's only one - if two mods have the same named CVAR they interfere with each other.