Not sure how to handle this use case where you’ve submitted a new build, and many players will receive it as a “patch” as they already have the game installed. Their settings will get erased because they have .ini files that are different from the .ini files in the build.
It seems like you’re stuck with either:
a) not including .ini files in the depot, which means everything will be default and that’s no good
b) resetting the players’ settings whenever you submit an update, because the whole build is checked against the players’ game installs and the .inis will be found to be different
Maybe it’s possible to do some trick with the steam installscript to make it generate the .inis with the default settings and only if they are absent?
If an old .ini file contains user data, you should not overwrite it with a new .ini file.
If you make a patch to do that, your users will be angry at you. ;;;;;
I think you should make another .ini file and put it in the patch to solve this problem.
Also, I don’t think it’s a good idea to save user data affected by the patch in the .ini file.
To solve this problem more fundamentally, I recommend using the following functions.
Yeah but the problem is you can’t really upload a patch to Steam, only a full build that is used for both initial installation (players who don’t have the game) and for updating (players who have the game)
So you’re stuck with including .inis otherwise you are depriving players of default settings for the engine.
It’s possible to move all settings into a “Settings.bin” file with BasicSaveObject, and make it so the game creates this file after the game runs, but there’s some issues with this like a lot of work to move all player settings there, and ‘engine’ settings still getting reset if a player made changes to DefaultEngine or SystemSettings, and later downloads an update.
I’m kinda mulling over the idea of using Steam install scripts to run a process the first time the game is installed. By default the game build/depot would not have any .ini files in the UDKGame/Config folder, and when the game is installed for the first time an .exe will run that copies the default .ini files from a secret folder to UDKGame/Config. Then updates will not overwrite any settings because the install script does not run for updates.
You should only ship the Default*.ini files with your build (not the generated UDK*.ini files).
Your player’s generated UDK*.ini files will only be reset to default if you ship a change with it’s corresponding Default*.ini file.
So make sure not to open/save one of your Default*.ini files unless you are making an intended change to it.
It is annoying that to add a new control bind to DefaultInput.ini, it’s going to reset everyone’s controls. I guess you could consider avoiding using the .ini files for certain settings and just store them in a json file.
It’s also worth mentioning that each time the clocks change for daylight savings, all your .ini’s will get set to default. It’s very annoying and i don’t think you can solve it without recompiling from source.
Yes, you’re right about only shipping the Default files. That should stop some things from being erased.
But this is where it gets good, because the only way I know to solve the Daylight Savings bug, is to put all the most important settings into your own .ini file, which won’t get wiped because it has no Default… but of course now you don’t have default settings anymore.
I think I’m getting somewhere with the install script idea though, that should solve most of my problems.
;;;;;