If a release contains a config.json, this is only deleted if it is in the root zip path, so this doesn't work in the cases where the zip contains only a folder with the mod contents. To fix it, now the config file is searched in the zip "inner path".
The same issue was when trying to read the manifest.json to use its pathsToPreserve when updating a mod: it wouldn't find the manifest and it would fallback to the pathsToPreserve of the installed local mod instead of the new version. This is especially important when a mod initial release doesn't include a pathsToPreserve but added it on a new version (example), the user would have its save data deleted after updating the mod. This is also fixed in this PR.
Example gifs since Rai likes them. ::D
The example is the one described in #176, a The Vision release that had a config.json with "enabled": false, when installing the mod the user had to manually enable it because of this.
If a release contains a
config.json, this is only deleted if it is in the root zip path, so this doesn't work in the cases where the zip contains only a folder with the mod contents. To fix it, now the config file is searched in the zip "inner path". The same issue was when trying to read themanifest.jsonto use itspathsToPreservewhen updating a mod: it wouldn't find the manifest and it would fallback to thepathsToPreserveof the installed local mod instead of the new version. This is especially important when a mod initial release doesn't include apathsToPreservebut added it on a new version (example), the user would have its save data deleted after updating the mod. This is also fixed in this PR.Example gifs since Rai likes them. ::D The example is the one described in #176, a The Vision release that had a
config.jsonwith"enabled": false, when installing the mod the user had to manually enable it because of this.Before:
After: