Updating to Steam Workshop without nuking INI

[kosmo111]

I have noticed that every time I update my mod on the Steam Workhop, the INI that I deploy with replaces their existing INI. To clarify, my mod uses its own INI file that allows them to configure various aspects of my mod. This is not relating to changing the default INI files the game comes with.

 

I have a few settings in the INI that I would like to respect across updates. Is this possible?

 

On a side note.... every time I deploy steam resets my name/description to the default and I have to update them manually on the workshop page. Is that normal?

Edited March 3, 2016 by kosmo111

[eXecator]

 

On a side note.... every time I deploy steam resets my name/description to the default and I have to update them manually on the workshop page. Is that normal?

 

same here...

Edited March 3, 2016 by eXecator

[davidlallen]

This is an interesting problem. Suppose you have an ini file foo.ini in your mod; you publish; and a player downloads. On their machine, the workshop directory for your mod now contains foo.ini with whatever contents you put there. Next, the user edits that copy of foo.ini. Next, you make changes to your mod and publish again. Steam updates the workshop directory on the player's machine. By definition, this will wipe out any local changes they had in their workshop directory. What else could it do?

 

I don't quite see how the steam downloader could figure out which parts of foo.ini you required to change, or where you may want the user's value to be kept. All the downloader can do is delete the old copy in the mod directory, and put all the new files there. But, that means there is no convenient place for the user to keep their changed ini file values. Even if they edited the merged ini files under My Documents, those changes will still be wiped out because your foo.ini file is newer.

 

It seems that users will need to keep copies of their changed ini file values in notepad, in a separate directory. Then, once they notice that your mod has updated, they will need to paste back their changed values, either into the workshop mod directory or the My Documents copy.

 

Can anybody think of a cleaner solution to the problem, where a user wants to change a mod's ini file?

[abeclancy]

Sooo why not just use another INI file?

 

Mod deploys with only \Config\YourModDefaults.ini. Mod loads all default values from this INI file. Mod saves \Config\YourModCurrent.ini. Users modify this file. You update your mod and update YourModDefaults.ini. Mod sees that the config between the files is different somehow, reacts accordingly.

 

The important thing would be that appropriate behaviors are defined in the mod for what to do on different configurations. Does Defaults just override Current all the time, or are the differences compiled together and the user is prompted for what to do with the differences?

 

Might be a little tricky to make sure that the two INI files are loaded appropriately, but I don't imagine it would be too difficult for someone a bit more familiar with UnrealScript. I'm just getting in to it for XCOM 2, so there's a lot I'm not sure about.

[bunnytrain]

Got an idea, but I haven't verified it. If the config file is missing, can you still compile? Because if you can, then maybe you can do something involving a child class inheriting a parent class, having the parent class's config come with the mod, and instructing players to create the config file the child class expects. That would cause configs in the child class to default to the parent class if not specified, and override if specified in the user-created file.

 

This might let you avoid nuking the child class's config file, but I'm not sure if Steam would also delete the extra file during mod updates.

[MachDelta]

According to the documentation it should be possible to create a config on demand. Try something like this as a test:

class myMod extends someClass config(DoesntExist);

var int myVar;

function InitMyMod()
{
    SaveConfig(); //flush to config
}

defaultproperties
{
    myVar = 4;
}

Because then you might not have to ship a config at all, just build and update it as needed from within the script itself. Seems a nice solution, I just haven't tried it.

[davidlallen]

I'm not sure how creating an ini file on the fly would work. AFAIK, the mod launcher is responsible for building and merging all the ini files before the game actually starts. So, by the time this ini file is written, it is too late, and the final ini files have already been written. Did I misunderstand your idea?

[aggies11]

I'm not sure how creating an ini file on the fly would work. AFAIK, the mod launcher is responsible for building and merging all the ini files before the game actually starts. So, by the time this ini file is written, it is too late, and the final ini files have already been written. Did I misunderstand your idea?

 

Sounds like they were saying that on first run of the mod it will create a new file "on the fly". The user can then edit that new file and the *next* time the game starts, those config values can be incorporated.

 

I'd imagine the idea is in response to that any file in the packaged mod will overwrite itself on workshop updates. So the only way around that is to create a file in the mod directory that isn't actually shipped in the packaged mod, so it can't overwrite.

 

You'd then have to be able to have the ability to detect if the file is present, if not create it, and if so take in it's values. Not familiar enough with Unrealscript to know if that is allowed for.

[MachDelta]

Aggies11 has the right idea. If you don't push a config to the workshop then it won't overwrite user's configs. But from within scripts you should still be able to pull values from a user config (if it exists) and if it doesn't exist, fall back to the defaultproperties. Telling the engine to save this config will hopefully write it out to the mod's working folder so that the values are accessible to the user for the next time the mod is run. The only downside is, as mentioned, users need to run the mod once in order for it to build a config that they can edit, which doesn't seem terribly inconvenient considering it's a one-time only thing. But there are several unknowns with the whole process since I haven't tried it myself. Maybe try a quick test mod to see how/if it works, even.