I see, so I just stumbled opon the only package that does that and thus there is no need for me to fix this in a general way, I guess
Can you elaborate a bit on the Graphics pack list modification with checkboxes etc?
The checkbox was just a method, it may not be the best...
For the tileset selection a drop-down list would be ideal I think, so in the case of Phoebus show all tilesets in the art folder, default to the tileset in the init.txt.
Then there's the TWBT plugin:
First: it's mutually exclusive with TTF.
Then: it needs extra modifications to the init.txt: set PRINT_MODE to STANDARD, set GRAPHICS to YES. And most importantly: it uses 2 tilesets in the init.txt: FONT and FULLFONT is set to the text-only tileset, while GRAPHICS_FONT and GRPAHICS_FULLFONT is set to the graphics tileset.
For TWBT I think we should load these text only tilesets from a separate directory.
(Then there'll also be an override.txt and an override tileset in the art folder for sprite overrides, and extra tilesets for map view may come along, we are not there yet.)
I figured most addons, be it graphics, tilesets, utilities, whatever, are using dffd and thus focused on dffd. dffd also makes it really easy to check for new versions, as this is possible.
I looked at using a git repo for stuff like that. The only projects I know that uses git to update are good ol' sickbeard and related. I briefly looked at the code and dffd looked way easier
If it's any help we could put a version.txt in the root of the github repo, that tells you the latest commit hash. That way you could easily determine if you have the latest or not.
Github provides a nice "Download ZIP" link to essentially grab the complete repository, but it doesn't include contents of submodules. You'd need special parsing of that to download them individually (but then you might as well just manage them individually...), or a full-blown git client - both are certainly possible, but maybe going a bit too far...
Also, I'm not sure if Github *wants* to have X thousand people doing this on a regular basis... it's not a webhost, so using it as one might be problematic in the long run. That's part of the reason why I think it's important to not overspecialize this - it's okay to do something special for a particular host, but there needs to be a generic solution in case that host is no longer available.
No, a zip is not going to work for this, partly because the submodule problem, partly because grabbing the .zip won't have any benefit over grabbing them from dffd, and partly because we'd be banned from github eventually as you mentioned yourself.
However they
don't forbid using the service for this, they just advise against distributing large files. Going with a full git client that only grabs the changes would be within their terms, and the bandwidth would be much lower than now - like 20-30 mega for a full pack (like 40.08 - » 40.09) update vs the 100 mega from dffd, and a couple of kb-s for most of the bugfix updates.
Take Dwarf Therapist for example: It's about 29 mb uncompressed, but 24 mb of that is QT and other Frameworks which won't change most of the time between versions. So an update is like 5mb. If I only push a new therapist.ini for a new version it's only 7kb this way. Maybe even lower, I don't know if they do any compression with git transfers.
I'm too lazy to type it agin, so here's a quote:
Here's the system I envisioned: Everything in this flowchart (except the bottom level) is organized via github submodule/subtree linking, so updates should propagate to the user with minimum maintainer interaction.
This model would simplify package maintenance, keep the mods/graphic pack in sync across platforms, keep the end user always up-to-date without needing to download the same old 100mb .zip from dffd, and then run upgrade scripts or copy save games. As a side effect it'd also lower the bandwidth usage of ddfd, which may result in lower cost for Toady as well.
The central mod/graphics repo should be modareted/trimmed/pruned so the new players are not overwhelmed by options, but there should be a way for the advanced users or the pack maintainers to add mods to their repo/local install if it's missing from the central repo. (see minimod 5 and 6 on the chart)
DFFD would still be needed, the github license agreement advises against using the service for general distribution. An update services like in the flowchart would be within service terms however.
And I agree with your thinking that we shouldn't depend on a single service, but going with a git client would mean we could choose from more than one git services, and I don't want to migrate away from dffd completely, the full pack would still sit there, only the update service would use git.