4.9.0 configs ?

[Kappes Buur]

Highlights:

• modern standards compliant configuration storage on Windows

What does that mean?

It seems that 4.9.0 can run without an ini file and thus does not read the autoexec.cfg file as usual.

[Graf Zahl]

autoexec.cfg is not what this about, this is a user-provided file that's only read but never written to.
What I mean with that is that storing the config alongside the EXE in the same folder is not how modern software is supposed to be written. The stored application settings are either supposed to be put in the AppData folder, or in our case where users are allowed to edit that file, somewhere below "Documents".
Same for savegames, they are also supposed to be somewhere in the user folder.

Such a setup is now the default - if you do not want that, you have to put a "gzdoom_portable.ini" in your installation folder, then it will mostly behave as before, with the sole exception of no longer personalizing the INI's file name.

[Kappes Buur]

Thank you for the clarification.
It's working again.

[NightFright]

But you can still specify any ini manually via -config launch parameter and it will use that as well then, I assume.

[Graf Zahl]

Yes, that part hasn't changed. This is just about those gzdoom-{username}.ini files which no longer exist.

[NightFright]

Great then, for I am switching between different inis via DoomRunner for a quick change of settings, i.e. default, vanilla style and Doom CE. No problem with this change from my side.

[Enjay]

As the only person who uses my computer, and with my computer only set up with a single user account, I find all these conventions and standards designed to allow different user accounts on the one machine annoying and counter-intuitive*. However, I also understand the need to be standards compliant. So, I'm behind the decision, I just don't like that it had to be made.

*part of this will be because I am an old fart who started working with single-user PCs that booted to DOS and everything went exactly where you chose to put it, in folders that you had named manually via the MD command.

[NightFright]

Without intending to start a discussion, personally I prefer the portable approach since if you ever reinstall your OS (which may result in reformatting your C: drive), all custom configs are wiped if you haven't made backups before. Since my games are stored on a different drive, everything remains save if you avoid those user directories.

Then again, how often does one still do a clean reinstallation with reformatting the drive these days? Windows recovery option is usually good enough. So yeah, it's all good.

[Graf Zahl]

Let's be clear about one thing.

I wanted to get rid of this bastard-approach for a long time. Either you go portable and use a single name for all users accessing the folder, or you respect user accounts and store it in the User folder. But not like ZDoom did it, i.e. attaching the user name to the filename.

So the only thing that was to be decided is what to default to.

[Enjay]

As I've said here, and in the release thread, I'm not a fan of the fact that the standard exists in the way that it does but, given that the standard does exist, I think that GZDoom takes a very neat, understandable and tidy approach to how to comply.

It seems to work precisely as it should, and it should be easy to describe to people how to find their ini files etc when, inevitably, people ask such questions.


I wonder, however, how will things be handled in these cases:

A person has more than one copy of GZDoom installed (e.g. 4.9.0 official and a git build, or just two separate GZDoom installs for whatever reason).

Someone has made a stand alone game that does not use an altered exe and so they might have GZDoom installed and StandAloneGame installed, but both using GZDoom.exe (which I guess is just a variant of the above but, in such a case, the details in the ini required for the stand alone game are likely to be different to those of the base GZDoom ini needed just for playing Doom).

[Graf Zahl]

A person has more than one copy of GZDoom installed (e.g. 4.9.0 official and a git build, or just two separate GZDoom installs for whatever reason).

In that case you need a portable setup - obviously. But I'd think everybody doing this stuff knows that already.

Someone has made a stand alone game that does not use an altered exe and so they might have GZDoom installed and StandAloneGame installed, but both using GZDoom.exe (which I guess is just a variant of the above but, in such a case, the details in the ini required for the stand alone game are likely to be different to those of the base GZDoom ini needed just for playing Doom).

Normally that's not an issue because each game has its own config section. And if not the maker really deserves to be slapped with a wet fish.
For a commercial release you'd at least want to replace your icon, though, and make sure that internally the proper name gets used which requires a custom EXE anyway.

[NightFright]

That solution with the dummy ini to enable portable mode is nothing new for me. Eduke32 is already doing it like that for quite some time now, too. As long as there's a way to keep things the way they were, even if it's not the default behavior any more, I am OK with everything.

[Rachael]

I might be more of a "neonate" than "an old fart" but I play extremely large games at times (>60gb in some cases) and I am actually extremely happy with the separation of my personal data from the program data, because it lets me play with a clean slate easily without making an entirely separate install.

Granted, this is definitely not the case with GZDoom, but as someone who has shipped 2 and a half commercial games on the GZDoom engine, I actually completely overrode the config code to use OS user folders on 2 of them (well technically 1.5 since Disdain is still demo-only at the moment), for a number of reasons:

1) Steam by default installs into Program Files, and installs its games into there, too. Only recently did GZDoom get code that completely disallowed portable installations to that folder. However you can still install Steam onto external media, which GZDoom does not account for. This inherently makes the cloud saves system completely incompatible - where are the saves? Are they in the user folders or are they in the application folder? Well - modern standards DO dictate that GZDoom was doing it the wrong way anyhow, so I changed it to do it the standard way so that Steam's cloud saves feature would actually work properly.

2) Building on the previous reason, Windows has been trying to become more POSIX-compatible over the years. In fact recently case sensitivity has been introduced to NTFS file systems (but it is disabled by default). Whether we like it or not, Windows is first and foremost a business OS, and large businesses have a lot of users. When you look at the Windows Server side of things you absolutely must have some form of user separation, so Windows NT introduced this in the same way Unix does it - at the time it was called the "Documents and Settings" folder, which later got renamed to Users in Windows Vista. This move allowed the games to move to a single standard for all platforms - the folders might be named differently, but it is possible to use environment variables to hash that out automatically and without hassle.

3) Allowing write access to the program's folder directly is inherently insecure. If the program faults for any reason (i.e. bug) and it writes to the wrong file, you could potentially overwrite your program's data, maybe even the executable itself. Granted this could be fixed easily with Steam's repair tool, but what if the fault goes unnoticed, and is exploited by a malicious actor? (Extremely unlikely, but it's a case that must always be accounted for) The next time you launch the game you very well could be running malicious code directly on your machine. Putting programs and games in read-only areas of the system helps to mitigate (read: not solve, just lessen the numerity) these kinds of attacks.

After I announced this change being put into Hands of Necromancy, I put in a pull request to make this a compile-in definition. However, Graf decided to go in a different direction - he decided to simply follow OS standards, instead, and I think this was a good idea.

[Captain Keen burner]

I have a quick question about this: what if I like to play with different settings? For example, I have multiple GZDooms with different wads in them, different settings, etc. Some are software rendering, some are hardware rendering. Some have mouselook enabled, some don't. This way I can just play and never have to adjust settings.

If everything defaults to an .ini file in Documents, is there a simple way to have different configurations? Since GZDoom is such a small file size my Doom Wads folder literally just has multiple versions of it in different folders with the settings and iwads that I want. I found it very convenient to do it this way, even if it's "dated". So is there a simple way to now have different config settings?

Does that make sense? Thanks!!

[Rachael]

Use gzdoom_portable.ini instead, then, and it will be just fine.