Print

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

[jecowa]

Don't multi-racial forts imply that all races need all jobs in their graphics definitions, or am I missing something?

Yes, you can define profession tiles for all the intelligent races now. I think most of them should be able to hold most positions. (Kobolds are too dumb to have professions though, except perhaps in mods. Meph might know more about that.)

 

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.

It's a lot of work to draw tiles for everything, so drawing professions for all the Goblins might have been a lower priority. CLA released a graphics pack template earlier that might have some info for goblin monarchs. http://dffd.bay12games.com/file.php?id=12090


 

Help would please be greatly appreciated cleaning my files up, if anybody's willing. 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).

I'm willing to help with stuff. Are you making a bunch of creature graphics for your tileset?

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])?

From what I've read, yes, that's what happens.

[Taffer]

I'm willing to help with stuff. Are you making a bunch of creature graphics for your tileset?

Thank you kindly for the answers and for the offer. I'm not making any new creature graphics: all of my graphics consist of:

 • A standard/default creature tile
 • A military tile
 • A monarch/ruler tile
 • A skull/dead body tile (which only shows up on zombies of course, as I don't rely on TWBT)

These are just for dwarves, humans, elves, goblins, and kobolds, which I perceive--perhaps wrongly-- to be the set of "intelligent races".

EDIT: I'm an idiot.

[Rydel]

I'm pretty sure that if there's not a match, it falls back to the default graphic.

Races like Goblins don't have a full sheet yet since I'm working on another, unrelated project at the moment.  Once that's finished, I plan to expand them to a full sheet.

[Taffer]

I'm pretty sure that if there's not a match, it falls back to the default graphic.

Races like Goblins don't have a full sheet yet since I'm working on another, unrelated project at the moment.  Once that's finished, I plan to expand them to a full sheet.

Apologies: I wasn't asking why art wasn't available, I was operating under a faulty premise that undefined creatures don't get graphics. Really, I shouldn't have posted at all.

I'm almost done finishing my graphics files at present, as soon as I fix some issues. A few things I've noticed while syncing my files to (portions) of Rally-Ho's files:

The first isn't in the game anymore, and the rest are either typos or don't appear in wiki.

   [DUNGEONMASTER:TAF_D:1:0:ADD_COLOR:DEFAULT]
   [DUNGEON_MASTER:TAF_D:1:0:ADD_COLOR:DEFAULT]
   [DUNGEON_KEEPER:TAF_D:1:0:ADD_COLOR:DEFAULT]
   [DUNGEON_LORD:TAF_D:1:0:ADD_COLOR:DEFAULT]
   [DUNGEON_NASTER:TAF_D:1:0:ADD_COLOR:DEFAULT]

EDIT: I'm an idiot.

[Taffer]

Sorry for the noise and confusion. I blame stress and lack of coffee. I just committed an update, bringing it in-line with Taffer 31.

[Rydel]

Don't worry, I too am suffering from stress and lack of coffee.

Since I used Phoebus when designing the sprite sheets, there were some defunct jobs on there.  I put them in since they didn't take much time, and it will be useful if those jobs are brought back later or used in mods.  I'm not sure why the different naming schemes are there for them.

TLDR: Those are there because Phoebus had them.

[jecowa]

I'm not sure why your Goblin tile kind isn't working, Taffer. I was comparing your Goblin definitions file with the one CLA posted. Here's somethings from Quiet-Sun's graphics standard that you may want to add:

Monarchs & High Priests:
  MONARCH_CONSORT   (You have King_Consort define, so you might want this defined too just in case.)

Officers:
  HAMMERER   (You have executioner defined, so this one might be good to have too.)
  CAPTAIN_OF_THE_LAW_ENFORCE
  RANGER_CAPTAIN

I'm not sure if you need to declare law_enforcement and tax_collector variants of the military, but I guess it doesn't hurt just to be sure.

[jecowa]

I was going to make GemSet usable without TWBT. The current issue with it is that most of the standard alphabetical characters are being used for something other than letters (corpses, I believe). My plan is to reassign anything assigned to those characters to a single pile of bones tile using tile 255 (as recommended here).

I think it might be best to add a new tilesheet to the art folder and make an "objects (non-TWBT)" folder that can be swapped out for anyone wanting to use GemSet without TWBT. I'll put comments next to any lines changed for non-TWBT compatibility to make it easier to keep the two objects folders in-sync with each other.

Or would it be better to have the non-TWBT version of GemSet in its own branch or fork or something?

Edit: Is there any reason that all the GemSet corpses aren't in their own overrides tilesheet? If it's possible to put corpses in an overrides tilesheet, that seems like it would be the ideal way to make GemSet work both with and without TWBT.

[jecowa]

Maybe use 4 corpse tiles for a non-TWBT version. There's a few unused tiles in GemSet.

From left-to-right: dead dwarf, dead other humanoid, dead other creature, dead titan/forgotten beast.

Spoiler: corpses (click to show/hide)

Maybe that's too many tiles to spend on corpses, though.

[Dirst]

Maybe use 4 corpse tiles for a non-TWBT version. There's a few unused tiles in GemSet.

From left-to-right: dead dwarf, dead other humanoid, dead other creature, dead titan/forgotten beast.

Spoiler: corpses (click to show/hide)

Maybe that's too many tiles to spend on corpses, though.

I think just a single Jolly Roger would suffice, though a special one for dwarves with a beard might be nice.  This probably isn't the thread to discuss it, though.

[Taffer]

Please continue using TWBT as much as possible, even if things lag behind. I'm happy to keep my DFGraphics repository in line with the current version that DFHack supports, rather than the current version. I know that increased community reliance on DFHack and TWBT is an odd request coming from somebody who never uses them, but there's just far too many problems with the default graphics engine and by his own admittance Toady has no interest in fixing them, nor does he know how. (Also, almost every graphics bug that I've seen in the bug tracker is flagged "Minor", and barely considered worth fixing).

This approach will turn every creature into a corpse whenever they're out of sight (yet still onscreen) in Adventure mode and also whenever they're engraved anywhere. Probably other places that I'm forgetting. It's not going to be fun playing adventure mode and never being certain what anything is, because everything looks like a corpse until you get close to it. This is besides all of the art DragonDePlatino added that requires TWBT.

TWBT is the best thing that's happened to the graphics packs in a long time, and I would truly hate to see things regress to not using it. Any feature or bug fix added by a version newer than DFHack supports isn't worth the ugliness and problems introduced by removing TWBT (for the sets that rely on it). I know you're not planning on removing the TWBT version, only adding a non-TWBT variant, but in my opinion you're taking away too much to make the branch worth it.

In my personal opinion, the only graphics sets that don't need to rely on TWBT are the almost-ASCII variants like mine, where turning off the graphics doesn't affect the aesthetic and creature graphics aren't used much. (And perhaps CLA, who specifically drew creature graphics knowing these limitations, but that's up to CLA).

[jecowa]

Please continue using TWBT as much as possible, even if things lag behind. I'm happy to keep my DFGraphics repository in line with the current version that DFHack supports, rather than the current version.

PeridexisErrant said it would be better to update for the current version of Dwarf Fortress and use releases to support older versions. By keeping the graphics packs up with the latest version, it should getting a version that supports TWBT faster once it gets updated for the latest Dwarf Fortress. Do you remove old profession tokens from your pack? I don't think there's a problem with leaving them all in if you want your pack to work with every version of Dwarf Fortress.

I know that increased community reliance on DFHack and TWBT is an odd request coming from somebody who never uses them, but there's just far too many problems with the default graphics engine and by his own admittance Toady has no interest in fixing them, nor does he know how. (Also, almost every graphics bug that I've seen in the bug tracker is flagged "Minor", and barely considered worth fixing).

Yeah, I get the feeling that he's not too fond of graphics packs.

This approach will turn every creature into a corpse whenever they're out of sight (yet still onscreen) in Adventure mode and also whenever they're engraved anywhere. Probably other places that I'm forgetting. It's not going to be fun playing adventure mode and never being certain what anything is, because everything looks like a corpse until you get close to it. This is besides all of the art DragonDePlatino added that requires TWBT.

Thanks for the explanation. I had heard about this bug before. Someone said he heard that the bug with creatures turning into their letters when out-of-sight might have been the inspiration for the design of CLA's graphics pack – by drawing the creatures as letters, they still look about the same when they transform into letters. (I was googling trying to find that thread, but couldn't come up with anything.) That's clever how DragonDePlatino dealt with the issue of corpses turning into letter. It seems like CLA's solution was designed to work without TWBT, though, making it great for adventurers who wish to run the latest version.

I didn't realize that corpse tiles were used in unobscured engravings; that explains why GemSet's corpse tiles look like they do.

TWBT is the best thing that's happened to the graphics packs in a long time, and I would truly hate to see things regress to not using it. Any feature or bug fix added by a version newer than DFHack supports isn't worth the ugliness and problems introduced by removing TWBT (for the sets that rely on it). I know you're not planning on removing the TWBT version, only adding a non-TWBT variant, but in my opinion you're taking away too much to make the branch worth it.

I don't think a non-TWBT GemSet would have to look ugly. I think it'd be best to start with gemset_text.png for the main tilesheet and use CLA, Grim Fortress, Tergel, and the tileset wiki page as guides on where graphics should be placed. I think Tergel does a good job of drawing things that look like they could represent more than one thing. CLA and Grim Fortress both place graphics in the main tilesheet conservatively, and they all make few to no edits to the objects files.

GemSet is the second highest-resolution graphical tileset after DawnFortress 32x32. I think it'd be nice to have GemSet as an option for users who want a graphics pack but who don't want to use TWBT / DFHack.

In my personal opinion, the only graphics sets that don't need to rely on TWBT are the almost-ASCII variants like mine, where turning off the graphics doesn't affect the aesthetic and creature graphics aren't used much. (And perhaps CLA, who specifically drew creature graphics knowing these limitations, but that's up to CLA).

I think it's just fine to have lots of creature graphics without using TWBT. Most players (maybe about 61%) don't use TWBT. Of those players, about 45% use a graphics pack that contains lots of creature graphics. Most graphics packs work well enough without TWBT; it looks like DungeonSet and GemSet are the only ones that really require it at the moment.

I think it's best if new players start playing without DFHack, but ASCII can be intimidating for many users. Even for someone coming from Dungeon Crawl Stone Soup, the large variety of ASCII in Dwarf Fortress is kind of overwhelming at first. Graphics packs make getting into Dwarf Fortress easier for new players. And by not starting out new players out on DFHack and TWBT, they won't become reliant on them from the start and will make a future transition into vanilla easier for them, if they ever decide they'd like to try it.

[jecowa]

The trick GemSet is using for corpses looks pretty good. I imagine it would be good to use it in the other graphical packs too. Until TWBT offers a way to include both TWBT and vanilla versions of object files and possibly init files in the same pack, what would be the best way to maintain TWBT and non-TWBT versions of a graphics pack? I'm guessing using branches would be the appropriate option for this.

[Thundercraft]

I'm happy to keep my DFGraphics repository in line with the current version that DFHack supports, rather than the current version.

I think it's best if new players start playing without DFHack...

Why suggest that newbies try to get into DF without DFHack? As long as the installation is hassle-free, it can just sit in the background, right? It comes with Stonesense and I think that, alone, can be a big help getting into DF.

I think some players do not appreciate how much certain Utilities and Mods rely on either DFHack or the memory offsets that team finds, or at least underestimate how many players use DFHack in some way. For instance, some players can't imagine playing DF without Dwarf Therapist.

Anyway, all the Starter Packs still come with DFHack. Those are still recommended to newbies, aren't they?

...there's just far too many problems with the default graphics engine and by his own admittance Toady has no interest in fixing them, nor does he know how. (Also, almost every graphics bug that I've seen in the bug tracker is flagged "Minor", and barely considered worth fixing).

Good points.

PeridexisErrant said it would be better to update for the current version of Dwarf Fortress and use releases to support older versions. By keeping the graphics packs up with the latest version, it should getting a version that supports TWBT faster once it gets updated for the latest Dwarf Fortress.

That makes sense, as long as maintainers try not to skip over an older version that DFHack is currently still limited to (or erase/overwrite their older versions).

Please continue using TWBT as much as possible, even if things lag behind.

I think it's just fine to have lots of creature graphics without using TWBT. Most players (maybe about 61%) don't use TWBT. Of those players, about 45% use a graphics pack that contains lots of creature graphics.

I've been away from DF for a while and I only recently heard about TWBT. So I haven't tried it, yet. And, actually, while it looks and sounds great, I'm a bit hesitant...

...And by not starting out new players out on DFHack and TWBT, they won't become reliant on them from the start and will make a future transition into vanilla easier for them, if they ever decide they'd like to try it.

Never! ASCII is not for me. Graphics packs and sprites all the way!

That said, I can see how TWBT might not be well-suited for newbies. At least, I would think it would make things a bit more confusing, esp. when trying to follow the wiki or follow along with a video tutorial. (Multi-tile sprites come to mind...)

...but ASCII can be intimidating for many users. Even for someone coming from Dungeon Crawl Stone Soup, the large variety of ASCII in Dwarf Fortress is kind of overwhelming at first.

ASCII is a huge turnoff for many. This was true years ago when DF was really starting to catch on. But this is even truer today, since gamers more-or-less expect flashy graphics, if not 3D. Gamers who have some experience with ASCII roguelikes are much more likely to give DF a try. But I suspect many of that crowd have already tried DF.

ASCII roguelikes don't seem as popular as they used to be. Some of them have been abandoned. And some of the most popular roguelikes are often played with graphical or isometric front-ends these days. I've read comments on Dwarf Fortress reviews and threads on reddit where a lot of gamers are saying the same things: The graphics is too primitive and its too indimidating to get into.

In contrast, I think a lot of the same gamers are willing to give Gnomoria and similar clones a try because they look a lot less intimidating and a lot more modern.
 
Indeed, I've played ASCII roguelikes before and I thoroughly enjoyed them - even without graphic front-ends. Even so, I never would have given DF a try had I not seen videos with Stonesense and graphics packs.

[jecowa]

Why suggest that newbies try to get into DF without DFHack? As long as the installation is hassle-free, it can just sit in the background, right? It comes with Stonesense and I think that, alone, can be a big help getting into DF.

I think some players do not appreciate how much certain Utilities and Mods rely on either DFHack or the memory offsets that team finds, or at least underestimate how many players use DFHack in some way. For instance, some players can't imagine playing DF without Dwarf Therapist.

Anyway, all the Starter Packs still come with DFHack. Those are still recommended to newbies, aren't they?

I would recommend that new players try out vanilla a bit before turning on DFHack. It's nice to know what features are vanilla and what features are added by mods. This will make it easier for them to know where to look up information when they have trouble with something.

Most starter packs come with DFHack, but I think it should be turned off by default. Some players may want to be able to play the latest version after they've played with a Lazy Newb Pack for a bit, but it will probably be harder for them to adjust if they have become accustomed to all the features and graphics of modded Dwarf Fortress.

Stonesense seems like a more advanced feature. It looks like you have to pull up a terminal window and type in some commands to enable it. That doesn't seem like something intended for beginners. I've never used it before, though.

That makes sense, as long as maintainers try not to skip over an older version that DFHack is currently still limited to (or erase/overwrite their older versions).

My favorite thing about GitHub is how well it organizes older versions. Any older version of a project on GitHub can be downloaded. PeridexiErrant mentioned that GitHub even allows for particular versions of a project to be flagged as a release, which will allow us to mark an old version as being the recommended version to use for a particular version of Dwarf Fortress.

I wish more projects were on GitHub.

I've been away from DF for a while and I only recently heard about TWBT. So I haven't tried it, yet. And, actually, while it looks and sounds great, I'm a bit hesitant...

If you decide to use TWBT, you might consider turning off multilevel view. It allows you to see more Z-levels at once, but some users have reported that Dwarf Fortress seems to crash more often with it turned on. Note that most packs have it enabled by default against the recommendations of its author. It seems to be tricky to disable. There's going to be one to three init files that have to be edited to disable it; you have to delete the line that says something like "multilevel 5" or "multilevel 6". The names of the files are called something like "onLoad.init", "DFHack.init", "onWorldLoad.init". They can be found in the Dwarf Fortress folder, the "raw" and "objects" folders, and even in graphics packs (The GemSet graphics pack, for example, includes one).

It's nice to be able to see more than one Z-level at once, but it can make it kind of confusing to determine which level the cursor is on.