I'd like to pack the whole /DF and /LNP folders into the /Resources directory, so I only provide a single .app that can be more easily upgraded. For this to work correctly, I need to store a few user settings outside the game folder, for eg: in ~/Documents/DF Data/
'Save'
'Macro'
'Help'
The launcher should check if these folders exist, and if not create and link them to the preset path, and reestablish the links if broken. Even better would be if this were a function, storing this data in .json.
[Issue created by fricy: 2014-08-31]
[Last updated on bitbucket: 2014-09-01]
[Comment created by Pidgeot: 2014-09-01]
Broken saves may not happen often, but they do happen, and when they do, something needs to be done. You can add the version string/DF folder name to get around it, but now you're back to having the user do manual work, so it seems to me like much of the point has been lost.
I can definitely understand what you're trying to do, but I want to keep the default functionality as consistent as possible across all three OSes, and that means this would need to be optional - Windows and Linux need DF, utilities etc. to be external, meaning they won't really benefit.
If it was only a matter of allowing the Resources folder to be used, I'd be okay with it, but simply doing that leads to problems - and trying to fix them all here seems to require a lot of assumptions about how OS X packs should work. That alone makes me very hesitant to even try to implement this.
If you want to fork the launcher and modify it to do this, you're welcome to do so, and if I get a well-made pull request that doesn't break anything else, I'll certainly consider including it - but at least for the time being, I have to mark this as WONTFIX.
[Comment created by fricy: 2014-09-01]
Unfortunately it's a valid concern, just got a help request from someone who has overwritten the whole pack folder, and lost all the saves. And I'm already using symlinks with the save folders to make them easier to find, so I know they work ok, this would only redirect them to a safer place.
What save breaking changes do you mean? If you save over an old save with a new version it will only work with the new version, and save breaking updates are pretty rare. (40.01-40.3 and 40.04-40.05), and it's only important in the bugfixing period, for the last 2 years we only had 34.11, and I expect to go quite a few months with 40.13 or so. But the multiple installation can be solved by ~/Documents/DF data/saves/(versionstring)/ to store the worlds, and symlink those to the proper places. Possibly this function could also be used to separate modded saves from vanilla saves, so at the start we could ask the user which game/settings to load.
[Comment created by fricy: 2014-09-01]
I want to hide everything from the user and move everything inside the .app/Resource folder, so the package can be upgraded by a simple drag-and-drop. For this to work I need to store some data outside of the package, and symlink these directories into the proper places. Most important is the save folder, but the macros folder is also a good candidate. Maybe there are other folders too, I'm not sure yet which one would benefit. So the launcher'd need to check if a preset directory exists, create it if it doesn't. If it exists just create a symlink. So the data/save folder would become a symlink pointing to /User/username/Documents/DF Data/saves. This might be interesting for linux users as well, not sure about windows. For the long term it'd be easier to create a function that'd read the data from the .json config and check/create these directories/links upon launch than hardcoding these paths into python. This shouldn't be easy to implement with the os.path.exists python function.
[Comment created by Pidgeot: 2014-09-01]
This sounds very fragile to me.
How are you planning on handling save-breaking changes? Have you considered that you're also removing the ability to run multiple DF versions independently?
[Comment created by Pidgeot: 2014-08-31]
You'll have to explain a little better exactly what you need and how it's supposed to work, because it sounds like there needs to happen a lot of extra things to make this all work the way you intend.
I'd like to pack the whole /DF and /LNP folders into the /Resources directory, so I only provide a single .app that can be more easily upgraded. For this to work correctly, I need to store a few user settings outside the game folder, for eg: in ~/Documents/DF Data/ 'Save' 'Macro' 'Help' The launcher should check if these folders exist, and if not create and link them to the preset path, and reestablish the links if broken. Even better would be if this were a function, storing this data in .json.
[Issue created by fricy: 2014-08-31] [Last updated on bitbucket: 2014-09-01]
[Comment created by Pidgeot: 2014-09-01] Broken saves may not happen often, but they do happen, and when they do, something needs to be done. You can add the version string/DF folder name to get around it, but now you're back to having the user do manual work, so it seems to me like much of the point has been lost.
I can definitely understand what you're trying to do, but I want to keep the default functionality as consistent as possible across all three OSes, and that means this would need to be optional - Windows and Linux need DF, utilities etc. to be external, meaning they won't really benefit.
If it was only a matter of allowing the Resources folder to be used, I'd be okay with it, but simply doing that leads to problems - and trying to fix them all here seems to require a lot of assumptions about how OS X packs should work. That alone makes me very hesitant to even try to implement this.
If you want to fork the launcher and modify it to do this, you're welcome to do so, and if I get a well-made pull request that doesn't break anything else, I'll certainly consider including it - but at least for the time being, I have to mark this as WONTFIX.
[Comment created by fricy: 2014-09-01] Unfortunately it's a valid concern, just got a help request from someone who has overwritten the whole pack folder, and lost all the saves. And I'm already using symlinks with the save folders to make them easier to find, so I know they work ok, this would only redirect them to a safer place. What save breaking changes do you mean? If you save over an old save with a new version it will only work with the new version, and save breaking updates are pretty rare. (40.01-40.3 and 40.04-40.05), and it's only important in the bugfixing period, for the last 2 years we only had 34.11, and I expect to go quite a few months with 40.13 or so. But the multiple installation can be solved by ~/Documents/DF data/saves/(versionstring)/ to store the worlds, and symlink those to the proper places. Possibly this function could also be used to separate modded saves from vanilla saves, so at the start we could ask the user which game/settings to load.
[Comment created by fricy: 2014-09-01] I want to hide everything from the user and move everything inside the .app/Resource folder, so the package can be upgraded by a simple drag-and-drop. For this to work I need to store some data outside of the package, and symlink these directories into the proper places. Most important is the save folder, but the macros folder is also a good candidate. Maybe there are other folders too, I'm not sure yet which one would benefit. So the launcher'd need to check if a preset directory exists, create it if it doesn't. If it exists just create a symlink. So the data/save folder would become a symlink pointing to /User/username/Documents/DF Data/saves. This might be interesting for linux users as well, not sure about windows. For the long term it'd be easier to create a function that'd read the data from the .json config and check/create these directories/links upon launch than hardcoding these paths into python. This shouldn't be easy to implement with the os.path.exists python function.
[Comment created by Pidgeot: 2014-09-01] This sounds very fragile to me.
How are you planning on handling save-breaking changes? Have you considered that you're also removing the ability to run multiple DF versions independently?
[Comment created by Pidgeot: 2014-08-31] You'll have to explain a little better exactly what you need and how it's supposed to work, because it sounds like there needs to happen a lot of extra things to make this all work the way you intend.