[Suggestion] Use folder/directory in Variables Files of Skin Packager

[Cariboudjan]

Can we please add a folder location to the Variables Files to preserve all files/folders contained in X directory of the RMSKIN? RMSKIN creates the folder with all of its contents if the folder does not exist in the existing location, or, if it does exist, ignores it completely.

Basically it would be the closest thing to allowing Variables Files and Merge to be used simultaneously.

[creewick]

+1 for the suggestion
It would be much easier to preserve files of skin suite like so, instead of selecting them one by one

RMSKIN creates the folder with all of its contents if the folder does not exist in the existing location, or, if it does exist, ignores it completely.

Although this may not work good, if for example:
- User installed v1 of the skin
- Author published v2 with some new files in persisted directory
- User updated to v2, but didn't get the new files, as the directory already exists

Maybe some kind of recursive checking "copy if not exists" for every file would work better in this case

[Yincognito]

Can we please add a folder location to the Variables Files to preserve all files/folders contained in X directory of the RMSKIN? RMSKIN creates the folder with all of its contents if the folder does not exist in the existing location, or, if it does exist, ignores it completely.

Basically it would be the closest thing to allowing Variables Files and Merge to be used simultaneously.

I'll let the devs answer this, but in the meantime, if you find it inconvenient to add all the variable files in the said folder via specifying multiple files by separating them with pipes (|), e.g. illustro\Clock\Variables.inc | illustro\Feeds\Variables.inc in that box (not sure if a wildcard like SomeConfigFolder\*.inc is possible there to solve the issue that way), you could use a variable storing if the current skin load is after an upgrade or not (say, IsUpgrade=1 initially, made IsUpgrade=0 via !WriteKeyValue on skin refresh) in a Lua script's Initialize() function to copy back the said folder from the corresponding @Backup folder. Probably inconvenient as well, but could be a temporary workaround till such a suggestion is implemented.