I like the direction that the update and dfhack segments seems to be going; if this is going to be a standard cross-platform thing the top priority is basic but flexible functionality.
It's probably also a good idea to select a standard format for holding configuration data early - in the windows version it's now mostly going into a text file, but using a defined XML standard would probably be a better choice (not that I have any experience with this). Keeping it extensible and well-formatted is important.
This looks great! I'd love to see this become the standard.
If you have any specifics that would make it easier for you to start using it, feel free to ask. 
Well, I learned my lesson with Dricus' java GUI - I'll stick with whichever has superior features and stability. From my reading of the OP you've already got most of it! Still to do:
- In utilities pane, don't show path or extension (ie "DwarfTherapist" instead of "Dwarf Therapist 23.2/DwarfTherapist.exe")
- Allow pack authors to configure the contents of the folders and links menu
- The DFHack tab (I don't actually care about this for 40.xx, and probably won't for a few months)
- Update notification tool
- Show which graphics pack is currently installed (current GUI just shows tileset name)
- Preserve non-graphics settings when changing graphics packs (I asume this will just happen once diffs are used)
Completing the items on this list would see me move over, purely for the sake of a single launcher on all platforms - it should focus development nicely. Other features not available on windows would be an inducement to move sooner - likewise my ability to understand the code!
Edit: I'm going to add these as issues on bitbucket, so we can keep track of the ones that aren't already there.
Loading graphics packs from a diff is an excellent idea. Besides saving space, it's a solid step toward a mod loader using the same mechanism. It would probably only support small to moderate raw-only mods, but this would include everything from Accelerated DF to Modest Mod and a host of minor tweaks. It should even be able to check compatibility, and only load non-conflicting mods.
It's going to require some thought and probably some experimentation to figure out what's the best route - the most straight-forward way would simply be to have a standard diff-format file and then first *try* to patch (and erroring out if the patch couldn't be applied), but it *may* be preferable to do a custom format and exploit the hierarchical structure imposed by indentation in the raws - I'm not currently sure if the indentation has any semantic meaning for the game code itself, or if it's only useful to a human. It's one of the things I need to consider carefully; a standard diff would be much simpler to do (Python already has diff-stuff built in), but a custom format would make it easier to use that idea for mods (and it would be possible to gracefully handle the case where two different mods want the same change to occur).
Of course, you would probably also want a way of removing a mod again - and it would be best if a complete rollback wasn't required to remove a patch applied early in the sequence - so there's some challenge in figuring out exactly how to do that. (Ideas, anyone?)
I would prioritise getting a working system in for graphics packs, and then extend it to mods after all core functionality is in.
A graphics pack in the current LNP consists of two parts. From the data folder, the contents of data/art/ delete and replace the installed folder; then from data/init/ init.txt, d_init.txt, and colors.txt overwrite the installed files (GUI'd settings are then restored). The raw folder then replaces the installed raw folder.
In my pack (unzipped), each graphics option is about 5MB of which 4MB is raws - with minimal changes. Using a diff for this would save a significant amount of space and stay reasonably modular. In all cases diffs should be compared to the pure vanilla raws (and other text files) exactly as they come out of the Bay12 download. The init files could also be done as a diff, since for graphics you only need to change [graphics:yes/no] and the four [*font:foo] tags (leaving the ubiqitious settings changes to a different diff. To extend this system to mods would then be very simple,
if the mods were written (or rewritten) to make the minimum effective change - using diffs from vanilla would mean that reorganising raws is generally a bad idea, which does bias this system to small mods (unless someone wants to rebase the whole thing, Meph).
To modify your installed mods, I would not go near removing diffs from the middle of a stack - rather rebuild the whole thing without whatever mod you want to remove. This dodges all kinds of problems with compatibility, as it should be checked every time.
Author
Topic: PyLNP 0.14e-pre1 - Cross-platform launcher with graphics pack patching (Read 326718 times)