I plan to do some ~things~ that I see long-term benefiting PyLNP. Is there any advantage to me making sure my libraries are cross-platform? I can look into Mono compatibility, but only if it's worth the time.
If you're planning on including them in PyLNP, then they should be cross-platform to avoid the need to maintain separate branches for other platforms. If you're talking about an external service that integrates with PyLNP (such as the utility information repository you mentioned in the wiki board), I don't think it would matter.
Preface: If I need to take this to a separate thread, let me know.
Re: lethosor's comments - that's what I'm not sure about. I definitely plan to expose an API that PyLNP could consume, but can see the advantage of having some of these libraries ready to roll in
if it's also something Pidgeot et al see themselves wanting to do down the road.
Ok, first task is structuring how things relate to each other. Here's my starting point:
I plan to have a website with an admin interface for managing this data (initially - hopefully some automation comes in down the road). First
Component would be Dwarf Fortress itself, which has no
Dependencies and I can populate all the releases that are available. Then my desktop app would notify (via checking the server API) when a new release has been posted.
I know there's an RSS for releases, but there's nothing I saw that points directly to a download link. I could scrape for it, but don't want to do that quite yet, so the update process on my end will still be manual although I can set up something to send me an email when RSS changes.
From there, you have to download/unpack the new DF (user-initiated, app just notifies it's available). This involves
- Archive the current DF folder
- Download the zip
- Unpack it
- Automatic processing of settings (migrate what we know works from user prefs, which are stored outside of init/d_init
- Manual settings (notify user if there's a new setting detected or if something couldn't be migrated because ~reasons~
- Install Components that can be (either no dependencies OR dependencies on DF with a Maximum Version "wildcarded")
- Notify user of "disabled" (not reinstalled) Components.
There should be a "test run" version of this that would spit out a summary of what tools you'd end up with, so you can decide whether you're ready to upgrade yet.
From there, Graphics Packs are next - one of the reasons for limiting the number of packs listed in PE's Starter Pack is that he doesn't have a good way of handling conflicts/installing/etc in the SP. I want to just have a list of all of them on the site, with functionality in the app to "download and install", as though you were choosing themes for Chrome or whatever. Admittedly, I don't know the first thing about how they work other than a vague assumption that it's image files that go in /data/art and some raws that get changed. If it's that easy, I should be ok, otherwise I'll be posting for help in the graphics area to understand just wtf I'm doing.
After that, looking to do utilities such as DT and QuickFort next. Hopefully by then it'll be pretty straight forward.
After that, I tackle DFHack and god help us all.