I was just wondering if there could be a better way to save ini entries for mods that have their own specific settings.
I'm aware that this has been a bit of a thorny issue for a long time but I just opened up my ini to find almost 3000 lines of mod specific entries, and I don't actually run too many of the kinds of mods that often require such entries.
Too many of the entries had quite cryptic names, so in many cases I couldn't even tell which mods the entries were for. So that meant it wasn't particularly easy for me to prune out the ones that I no longer wanted, so I just nuked my ini file and set things up from scratch again. I guess if I replay any of the mods, I'll just have to set them up as I go too.
So, is there any way that this situation could be improved from the engine side? GZDoom is already very good at identifying which lump within which WAD/PK3 causes an error, so perhaps could that same logic be used to identify the source WAD/PK3 for the ini values?
For me, ideally, there would be an ini folder of some sort where mod specific ini values were saved in their own sensibly named file and could therefore be identified easily and removed if necessary. Perhaps that is a security risk, or something that would be problematic across platforms?
Anyway, I just thought it was worth asking the question. If a user such as myself who doesn't use too many mods that write to the ini found a few thousand lines of entries, I shudder to think what the ini files for people with the huge mod loadouts that I see posted in these forums might be like.
A Better Way for Mod Specific ini Values to be Saved?
Moderator: GZDoom Developers
-
-
- Posts: 26824
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
-
- Posts: 13882
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: A Better Way for Mod Specific ini Values to be Saved?
This is something that's been in desperate need of addressing for a very long time.
I think the solution that I would propose is giving a namespace to the mod cvars, which can be defined in cvarinfo (i.e. namespace = "awesomemod")
These namespaces would be attached to the cvars in question (which can be stored in the cvar struct with their regular data) then when the .ini save happens they get their own [awesomemod.cvars] section, which then in turn is loaded up on startup. But this is purely theoretical - I have no idea how easy this would be to implement.
Of course, then the issue comes up what to do when there's two cvars with conflicting names - there's no easy way to make them truly unique to the namespaces in question. For that, I would propose a console warning - but there's really not much you can do about it, here. You'll just have to accept that there will be issues if two mods use the same cvar name. (Which is why it makes it a good idea to name your cvars after your mod, i.e. awesomemod_awesomecvar). So the console warning ideally will warn you of that, hopefully.
I think the solution that I would propose is giving a namespace to the mod cvars, which can be defined in cvarinfo (i.e. namespace = "awesomemod")
These namespaces would be attached to the cvars in question (which can be stored in the cvar struct with their regular data) then when the .ini save happens they get their own [awesomemod.cvars] section, which then in turn is loaded up on startup. But this is purely theoretical - I have no idea how easy this would be to implement.
Of course, then the issue comes up what to do when there's two cvars with conflicting names - there's no easy way to make them truly unique to the namespaces in question. For that, I would propose a console warning - but there's really not much you can do about it, here. You'll just have to accept that there will be issues if two mods use the same cvar name. (Which is why it makes it a good idea to name your cvars after your mod, i.e. awesomemod_awesomecvar). So the console warning ideally will warn you of that, hopefully.
-
- Spotlight Team
- Posts: 430
- Joined: Tue Oct 05, 2010 12:04 am
- Graphics Processor: nVidia with Vulkan support
Re: A Better Way for Mod Specific ini Values to be Saved?
Why not just dedicate a separate folder for .ini files that aren't the main engine settings? and then have each wad a separate .ini file with the defined namespace as the filename? Lot easier to ensure there aren't mod conflicts if it's on the user to set this name, rather than GZD trying to solve this itself.
-
- Lead GZDoom+Raze Developer
- Posts: 49204
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: A Better Way for Mod Specific ini Values to be Saved?
Because that isn't 'just' that easy...?
-
- Spotlight Team
- Posts: 430
- Joined: Tue Oct 05, 2010 12:04 am
- Graphics Processor: nVidia with Vulkan support
Re: A Better Way for Mod Specific ini Values to be Saved?
I do understand that the phrase "just do it" isn't a very productive thing to say to developers and is very reflective on my understanding of the source, but it probably would be great for the discussion at hand if it was outlined on why that approach isn't 'just that easy'. I would definitely like to know why what I suggested couldn't be done.
-
- Posts: 159
- Joined: Sun Feb 17, 2019 9:29 am
Re: A Better Way for Mod Specific ini Values to be Saved?
I was thinking about it some time ago , too
viewtopic.php?f=4&t=15005&start=5175#p1196486
I feel at this point it is all up to mod creators , for example something like
DoomRLA nobulletcasings=0 is easy to distinguish
while
LI nwho=0 is not (completely made up these two)
Btw what is the difference between [Doom.Player.Mod] entries and [Doom.LocalServerInfo.Mod] entries ?
I recently took time and reduced my .ini file to 20 kb , by only leaving entries that I changed from the default for mods I usually play , and controller settings , deleting everything else related to 3rd party mods , no need to say it took much time
viewtopic.php?f=4&t=15005&start=5175#p1196486
I feel at this point it is all up to mod creators , for example something like
DoomRLA nobulletcasings=0 is easy to distinguish
while
LI nwho=0 is not (completely made up these two)

Btw what is the difference between [Doom.Player.Mod] entries and [Doom.LocalServerInfo.Mod] entries ?
I recently took time and reduced my .ini file to 20 kb , by only leaving entries that I changed from the default for mods I usually play , and controller settings , deleting everything else related to 3rd party mods , no need to say it took much time

-
-
- Posts: 26824
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: A Better Way for Mod Specific ini Values to be Saved?
Did you keep a copy of that cut down ini? If so, if you rename it to just gzdoom.ini (no usernane) and leave it in your GZDoom directory, if you ever have to delete your actual ini again, GZDoom will read that one and will create a new username ini with the changes from gzdoom.ini already in place. At least, it used to do that. I haven't checked for a while but I don't see why it would have changed.