Wed Aug 26, 2020 5:11 pm
In order to investigate this, I'm going to need to find where and when GZDoom begins and writes out a new INI file, if it fails to find and/or read an INI file.
This bug is completely sporadic, so I suspect something isn't initializing properly when it happens. Ever since the new fullscreen variable was introduced, somewhere around that time, I've encountered moments of starting up where it just completely disregards the INI previously made and wipes it out.
Wed Aug 26, 2020 6:08 pm
So that explains why that happened to me the other night. I thought I was going insane.
Wed Aug 26, 2020 6:57 pm
Yeah I did too. This is annoying. It happens so rarely though.
Thu Aug 27, 2020 5:41 am
Major Cooke wrote:In order to investigate this, I'm going to need to find where and when GZDoom begins and writes out a new INI file, if it fails to find and/or read an INI file.
You can start from here
Sat Sep 26, 2020 3:32 pm
Unfortunately I haven't had much luck in tracking this issue. This is harder than I thought... Or maybe I'm overthinking it.
Wed Nov 04, 2020 9:47 am
This bug is still an issue as of 4.5. Can I please reopen this? It happened to me just today.
Wed Nov 04, 2020 10:30 am
I think what should be done going forward is making automatic backup copies of the configuration files, even if they end up being shoved into a folder.
Wed Nov 04, 2020 10:43 am
I don't think LZDoom is affected, this has never happened to me. I wonder since when this is a thing but must be something recent.
In LZDoom the code in FGameConfigFile::FGameConfigFile () is exactly the same so the problem must be somewhere else.
Wed Nov 04, 2020 10:53 am
Same here. I never ever lost a config file so it should be examined what other contributing factors may be there.
This sounds like GZDoom for some reason cannot open the INI - so what may block it?
Wed Nov 04, 2020 11:38 am
Just to make sure, you're not closing GZDoom while it's loading, right? Because I'm 99% sure that's what's causing GZD to eat my config files. You just have to time it reaaaaally carefully to trigger that. 10/10 times it's happened to me while I was opening and closing GZDoom all the time while modding. Haven't had a config get eaten ever since I started waiting for it to launch properly before closing it if I opened it by accident.
Wed Nov 04, 2020 11:57 am
I've been very consistent on just opening the console and typing "exit" in.
Wed Nov 04, 2020 1:09 pm
I never use that but certainly the code is different.
if (!insave) throw CExitEvent(0);
Wed Nov 04, 2020 1:49 pm
The last time I had it happen, I used the new relaunch button on script errors. I've also had it happen in a few cases when closing the startup window when the game is launching because I started it up twice by accident or something.
Wed Nov 04, 2020 2:54 pm
If the file can't be read it assumes it doesn't exist:
void FConfigFile::LoadConfigFile ()
FileExisted = false;
if (!file.OpenFile (PathName))
succ = ReadConfig (&file);
FileExisted = succ;
And FConfigFile::ReadConfig is different in both versions.
Wed Nov 04, 2020 4:18 pm
It then should create new gzdoom_<user name>.ini file.
Problem is, it eats/override existing ini file. I have my ini file renamed to gzdoom_portable.ini and Gzdoom still sometimes (rarely) corrupt it. I mean, if it was just "du du dudu....cant find/read ini file, well create new one then....gzdoom.get_name() + _ + windows.get_user_name()", as it should by default, but no, Gzdoom aware that it should use _portable name as a name for the "new" ini file.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.