Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PeridexisErrant]

Several of the packs in this GitHub collection are lagging behind. Several of these like Ironhand, Mayday, Taffer, and Tergel have only been updated to 0.42.05 and are months old. This, despite the fact that some have used and uploaded (DFFD) packages for later DF versions (42.06, 43.02, 43.03...), without updating the GitHub repositories.

What this means is that, while DFHack and certain utilities that many players swear are essential for them to play are (currently) limited to 42.06, while finding graphics packs for that version is becoming difficult since GitHub is still stuck at .05 and a lot of people seem to be jumping on the 0.43 bandwagon.

Imagine, say, months from now where someone regales an amazing story about an amazing fort or adventure they had in a world generated with a mod based on 42.06. And he shares his save or worldgen settings, with others wanting to look at it or play the same world/site. Except, DFFD doesn't have their favorite graphics pack for 42.06 any more because it got updated-over or deleted and the GitHub for their favorite pack either stopped dead at 42.05 or skipped over 42.06 from .05 to some later version.

Edit:

...Exactly.  Some, which have been picked up by maintainers who don't want to use GitHub (eg Ironhand by GoldenShadow), should probably be suspended or something but I haven't looked at this lately.

Maybe send a friendly reminder about their GitHub repository?
Wait... They said that they don't want to use GitHub? Or does it just seem that way?

Yeah, it's not a great situation.  Things are improving though, in that we've got more people signed up who can update anything on Github - better that nobody *has* fixed it yet than nobody *can* fix it, IMO.  And ideally when you're updating a pack you do it in stages if there's something not compatible with either end, and add the tag.  (eg .05 is compatible with .06, and 43.x is all compatible too so far).  So fewer actual compatibility breaks than you might think!

GoldenShadow and Burned politely declined to join, and Burned asked that his graphics not be added.
Others have joined or have pending invites, but haven't pushed updates to github.  I think it's pretty rude to bug people about it though, since I'm not helping either due to lack of time.

Concerning the purpose of this group, Peridexis told me, "The aim is to make maintaining a pack as easy as possible." Does everyone agree with this?

I agree, moving to github makes it easier to maintain. Having a standard distribution format helps too. Though I would argue that a big part is "to make getting an up to date pack as easy and fast as possible for the end user". It does make it easier for maintainers too, but not more simple. It makes it easier by adding another layer of complexity (standard distribution format, github organization).

Fair.  I do think the simple/easy tradeoff is worth making in this case though, since it could allow eg. automatic DF-updates and computer checking of the format.

[jecowa]

What determines which packs are included in this repository? It looks like maybe it's any pack whose author choses to host it here, in addition to all the packs that are no longer being maintained by their original authors?

Exactly.  Some, which have been picked up by maintainers who don't want to use GitHub (eg Ironhand by GoldenShadow), should probably be suspended or something but I haven't looked at this lately.

Here's some info that might help determine which repos should be considered active and which ones should be suspended.

The GitHub versions of these packs look to be the most up-to-date versions, and these packs have no other active maintainers:

• Afro
• Obsidian
• Phoebus

These packs are being actively maintained by their original authors here on GitHub:

• CLA
• AutoReiv

This pack's author is inactive, but it only edits a single objects file:

• Jolly Bastion

These packs are being maintained by people who don't/no longer use GitHub:

• Spacefox
• GemSet
• Mayday
• Ironhand
• Rally-Ho
• Wanderlust

These packs' authors don't don't use GitHub. And they also don't edit any objects files:

• Taffer
• Tergel

[Taffer]

These packs' authors don't don't use GitHub. And they also don't edit any objects files:

• Taffer

Github. It's been the primary download for my pack ever since DFFD switched hosts. I've also updated to new releases on Github pretty consistently, often the same day the release hits.

Minimal update to 0.43.01, including the keybindings. Life is happening. All current projects put on hold--not abandoned--for the next while (ie, rewritten creature descriptions, updates to my tilesets, updating my DFgraphics repository).

I'll still keep things updated for new releases, but I don't even have DF installed at the moment. I still welcome contributions to the rewritten creature descriptions.

I'll see what I can do about updating the DFGraphics repository for my pack. I wasn't aware it needed any updating apart from the actual tilesets: it uses older versions of my work, but I don't edit any raw files and no new jobs were added for the creature graphics recently so there shouldn't be anything to update at present. I've been putting off updating the tilesets because I knew I'd be redrawing them in a few weeks anyways.

Kindly consider my DFgraphics repository maintained, and poke me in my tileset thread (or via PM or over Github) if it needs touching. I'll use that as the "Starter/Newbie Pack" resource for my set, for maintainers or users. I'm not sure what access I have to it at at present.

While I'm here, what subset of my tilesets should I include? I have almost no usage data whatsoever on what parts of my pack get used, and no interest in cluttering up the Newbie Pack with all 32 current tilesets. I've been maintaining a sans-serif font for years now at the request of one user (who didn't post after), but I haven't ever seen it used to my recollection, nor have I had any comments on it. By what little usage metrics I have, I'd be better off including my "dwarves are letters" version, because I have at least 2 users of those sets. I've seen screenshots of all four wall variants, so I'll keep those in.

[jecowa]

These packs' authors don't don't use GitHub. And they also don't edit any objects files:

• Taffer

Github. It's been the primary download for my pack ever since DFFD switched hosts. I've also updated to new releases on Github pretty consistently, often the same day the release hits. Evidently I need to start doing so in the DFGraphics repo as well.

Sorry, I was looking at the commits to each pack on the DFGraphics repo to try to determine who used GitHub. Maybe we can make the one on the DFGraphics automatically sync itself with your repo. Or maybe we can replace the copy on the DFGraphics group with a link to your repo. I'm not really sure what the options all are. It seems silly for you to have to update two, though.

While I'm here, what subset of my tilesets should I include? I have almost no usage data whatsoever on what parts of my pack get used, and no interest in cluttering up the Newbie Pack with all 32 current tilesets. I've been maintaining a sans-serif font for years now at the request of one user (who didn't post after), but I haven't ever seen it used to my recollection, nor have I had any comments on it. By what little usage metrics I have, I'd be better off including my "dwarves are letters" version, because I have at least 2 users of those sets. I've seen screenshots of all four wall variants, so I'll keep those in.

I don't have usage data for your graphics pack, but from the poll from about a week ago, most users use the default settings. I think your "serif, straight, hollow" has been the default for a while, but it looks like your "serif, straight, solid" was the original version. So those might be good ones to include.

I don't think it's necessary to include all 32. I think you only need to include the 16 "dwarf letters" versions. With graphics turned on, a user will get the smiley faces; with graphics turned off, a user will get the dwarf letters. I don't have a problem with having more tilesets as options, but that seems like extra work for you to maintain.

[Taffer]

Sorry, I was looking at the commits to each pack on the DFGraphics repo to try to determine who used GitHub. Maybe we can make the one on the DFGraphics automatically sync itself with your repo. Or maybe we can replace the copy on the DFGraphics group with a link to your repo. I'm not really sure what the options all are. It seems silly for you to have to update two, though.

I don't think it's necessary to include all 32. I think you only need to include the 16 "dwarf letters" versions. With graphics turned on, a user will get the smiley faces; with graphics turned off, a user will get the dwarf letters. I don't have a problem with having more tilesets as options, but that seems like extra work for you to maintain.

Good ideas there. It would be a mistake to link the whole repositories: the folder structures are too different. My folder structure works well for people installing manually, but isn't a good fit for DFGraphics. (Contrariwise, the DFGraphics format isn't great for manual installations without the aid of a program). The tilesets would need to be renamed links directly to my own tilesets. I'll find time this week to get it all sorted out. Thanks. Perhaps we could do the same for other repositories (eg, CLA).

[CLA]

the DFGraphics format isn't great for manual installations without the aid of a program

How so?

[Taffer]

the DFGraphics format isn't great for manual installations without the aid of a program

How so?

Editing ini files is, in my limited experience, far beyond the comfort level of most users for some reason, even if the change is simple. My understanding it that the Starter Pack/Lazy Newb Pack themselves originated to help users avoid this, not just as "DFHack and related utilities conveniently pre-packaged". Even Masterwork includes an elaborate GUI at this point. I have no direct evidence to back this, but I expect that if my download was restructured to require users to change the tileset in init.txt to use the alternates, hardly anybody would do so. As it is, they just have to copy and paste.

For example, I put some alternate dwarf graphics in my pack after I read some discontent that I removed beards and include helpful instructions on how to enable them in the graphics files, but I'm reasonably sure that hardly anybody that downloads my pack has even noticed them.

[CLA]

[...]

I agree, but that's not the case with the dfgraphics repo. At least not with mine, maybe I'm doing something wrong. The init file that comes with the download already contains the references to the CLA tileset and has GRAPHICS set to YES. You only need to download the "source code" and drop it into a fresh DF install.

[Rydel]

These packs are being maintained by people who don't/no longer use GitHub:
...

• Rally-Ho

I do use GitHub.  I just apparently misunderstood how this was linked the the original repo - I thought it was a clone that would update automatically.  I've pushed the missing changes to this version and shouldn't have issues in the future.

[Taffer]

I agree, but that's not the case with the dfgraphics repo. At least not with mine, maybe I'm doing something wrong. The init file that comes with the download already contains the references to the CLA tileset and has GRAPHICS set to YES. You only need to download the "source code" and drop it into a fresh DF install.

You're not doing anything wrong: I just have a lot of tileset options, which need to be set in init.txt (if you use the DFGraphics repository)

[PeridexisErrant]

I agree, but that's not the case with the dfgraphics repo. At least not with mine, maybe I'm doing something wrong. The init file that comes with the download already contains the references to the CLA tileset and has GRAPHICS set to YES. You only need to download the "source code" and drop it into a fresh DF install.

You're not doing anything wrong: I just have a lot of tileset options, which need to be set in init.txt (if you use the DFGraphics repository)

Check out how the Phoebus repo does this - a default tileset (etc) is set in init.txt, and all the others are in data/art.  You can install just by drag-and-drop, and then change the init if you don't like the default tiles.

[jecowa]

You can install just by drag-and-drop, and then change the init if you don't like the default tiles.

Taffer doesn't think most players would be comfortable with editing the init files, so he prepares several copies of his tileset each with its own init files. It looks like a third of Taffer users use the LNP. The rest of Taffer users prefer to play on the latest version of Dwarf Fortress.

[jecowa]

     Here's an updated breakdown of packs in the DFGraphics repo:

These packs are "orphans" and are only being maintained in the DFGraphics repo:

Pack Name Last Updated Afro   5 days ago (Jecowa) Obsidian   5 days ago (Jecowa) Phoebus   5 days ago (Jecowa)

These packs are being maintained on the DFGraphics repo by their original or current authors:

Pack Name Last Updated Rally-Ho   2 days ago (Rydelfox) Spacefox   4 days ago (Nopal-Dwarf) CLA   13 days ago (claireanlage) AutoReiv   15 days ago (AutoReiv) Taffer   soon (Taffer)

These packs are being maintained by people who don't/no longer use GitHub (sorted by activity level):

Pack Name Last Update for Version           Notes Ironhand 2016-05-22 (GoldenShadow) v0.43.03 Mayday 2016-04-07 (Tallcastle) & 2016-05-13 (Habbadax) v0.43.03 GemSet 2016-01-15 (DragonDePlatino) v0.42.04 Modifies the most objects files. Wanderlust 2015-12-10 (Kynsmer) v0.43.03 Only copy "inorganic_stone_soil" and not any objects or init files. (It only need to modify that one objects file.) Tergel 2015-12-06 (CowThing) v0.43.03 Does not modify any objects files.

This pack's author is very inactive, but it only edits a single objects file:

Pack Name Last Updated for Version           Notes Jolly Bastion 2012-05-21 (AlexanderOcias) v0.34.10 Only modifies "plant_standard" and "d_init".

[PeridexisErrant]

Habbadax (Mayday maintainer) expressed interest and has a pending invite, but is not yet on Github.  I'll invite Tallcastle too.  Will also invite Kynsmer (re: Wanderlust). 

Jolly Bastion doesn't need a dedicated maintainer -- luckily!

And @Jecowa, thanks heaps for stepping up and helping out with this

[Taffer]

Don't multi-racial forts imply that all races need all jobs in their graphics definitions, or am I missing something? This is how I've been distributing my own sets for some time. I'm re-basing my graphics text files on Rally-Ho's graphics text files because they're clean and nicely formatted, but the goblins, for example, are missing almost every non-military job. Many graphics sets have this same problem from what I've seen, although I haven't looked at all of them. I have nice goblin and kobold monarch graphics, for example, but they'd never show according to these RAW files.

Information on these issues would please be greatly appreciated. In the past I just copied and pasted all of the dwarf definitions to the elves, humans, goblins, and kobold files. Ideally, I'd just like to sync my own graphics files (apart from filenames and TILE_PAGE names, of course) with Rally-Ho or something, but these files don't appear complete to me. (Or I have graphics that can't ever be used by the game, like my goblin/kobold monarch tiles).

When goblins end up ruling a dwarven civilization in the current version, do they just revert to a "g" with most graphics packs? Do they revert to using the default definition ([DEFAULT:RALLYHO_GOBLIN:0:0:AS_IS:DEFAULT])? These files have been a sore point for me for a while, for that matter: while documentation exists, when I last looked at these files it was scattered and most graphics files were/are half-filled with commented out graphics definitions and odd formatting/spacing issues, making it difficult to decipher them. It doesn't help that I haven't played Dwarf Fortress with graphics enabled--apart from brief testing--in a long time.