Use Application.persistentDataPath for mutable files
While packaging (and patching) the game for Nix, I found that the game tries to write stuff to
Application.dataPath, however this path should be read-only and of course causes trouble packaging if the user doesn't have access to the data path (for example if it's mounted read-only, like on NixOS).
Unity3d already takes care of that in a cross-platform way using
persistentDataPath, which for example on GNU/Linux boils down to
$XDG_CONFIG_HOME/unity3d/Subterranean Games/War For The Overworld (btw. you might want to rename that to Brightrock Games) which is a standard location for config files.
Note that even the way Unity3d handles this is a bit oversimplified as for example
$XDG_DATA_HOME would be more suitable for things such as save game data, but better so than writing to
Of course the
GameSettings class would need a bit more work, because if
Settings.txt doesn't exist in
dataPath should be used (which would also be very useful for other stuff, because it's backwards-compatible).
Would be really great if you could change this, so I don't need to patch the assembly every time the game is updated.
This should also make the game less annoying with AV software on Windows btw. ;-)
Thanks :-) I'd really appreciate if you'd fix this.
Customer support service by UserEcho
Note that I'm still on version 2.0.1 because the GOG version hasn't been updated to 2.0.2. If it's been fixed in 2.0.2 already feel free to close :-)
This is currently being reviewed by our QA Analyst. So I'll mark it to show as such. :)
To make patching this less tedious I now implemented a generic patcher for common problems in games using Mono, so this is what needs to be patched for WFTO, at least for the settings and saving/loading. I didn't test the editor though...
Unfortunatly its just too messy at this stage. We will endeavour to make less of a mess of our read-only paths in future.
Changing this would require the game to migrate existing player data to the new path, this is just out of scope for what we are doing with WFTO at the moment.
Thank you for the continued effort so far, we will remember this issue and reevaluate at a later date when we are making changes