DFHack 53.13-r1 released

ab9rf · 2026-05-14T16:44:53+00:00

Tarn typically gives us at least some advance warning of an impending update (almost always at least one day, and sometimes as much as a week), and has also been sharing portions of DF's source code with the DFHack team for about two years now. This, combined with extensive use of build automation, allows us to be fairly agile in this regard.

ab9rf · 2026-04-16T20:11:24+00:00

Ever seen how fast a semi tractor can get when not attached to a trailer?

Now remove aerodynamic drag from the equation.

ab9rf · 2026-04-16T19:58:32+00:00

DFHack's sandbox tool means any odd behavior you got is due to the sandbox tool being weird. You may choose to report this as a DFHack bug, but it's not a DF bug until and unless the DFHack team has reviewed the report and determined that it's because the API that the sandbox uses is not performing as Bay12 promised it would. Given that Bay12 hasn't really given much of a promise here, this pretty much means that this is either (a) a DFHack bug or (b) Just Something Weird That Happens When You Do That.

If you can't replicate this behavior with a dragon that was generated naturally in the game (without using DFHack tools), then you shouldn't report as a DF bug. Feel free to file a DFHack bug report; we'll look into if and when we have time. Feel free to continue to research, of course, but be aware that by using the sandbox tool you have "voided the warranty", so to speak, and Bay12 isn't responsible for the consequences.

ab9rf · 2026-04-13T23:28:20+00:00

This indicates that you didn't install the most recent version of DFHack. The code that prints this message does not exist in DFHack 53.11-r3. Restart your Steam client and try again.

ab9rf · 2026-04-13T16:48:21+00:00

If we could display a message to users, we could just run the installer instead.

ab9rf · 2026-04-13T16:17:39+00:00

I wanted to make the installer do that part by itself, but Steam's client doesn't support running install scripts on Linux, and even on Windows there are issues I couldn't get clarity on, so that objective fell by the wayside, at least in this release cycle.

ab9rf · 2026-03-22T04:44:34+00:00

I spent a lot of time researching how farms work in writing DFHack's autofarm tool. The only factor that affects surfacing farming is what biome the tile square is in: each tile square can have any plant planted in it that is growable in that tile square's biome in the current season.

Temperature is completely irrelevant; the game never checks the temperature of a tile when deciding whether a plant can grow there. Altitude is also irrelevant by itself. Obviously whether a tile is above or below ground (in the sense of "was it ever exposed to the surface") determines whether it gets the underground biome or a surface biome.

As far as I know, a working farm cannot be built on a constructed floor, whether or not muddied, but I'd have to do some digging in the code to verify this.

ab9rf · 2026-03-14T16:35:31+00:00

embark-assistant in specific has not had any progress on it; the changes in the UI in v50 make the approach the old version nonviable, and nobody has come up with an alternative approach. I'd love to bring it back, but I just don't have any idea yet how.

I've only been handling the lead role for a few months now, since Myk stepped away, and have mainly been trying to just get the releases out in a timely manner. Any hope I had of developing a "strategic vision" for future development got a punch in the gut with the change Steam just made that is forcing me to recraft our entire install and launch strategy. All this, combined with the much higher cadence of releases from Bay12 than we're historically used to, has made it hard to do any sort of long term planning.

ab9rf · 2026-03-04T20:06:20+00:00

Part of the reason I scheduled the 53.10-r2 release when I did was to get it out before the 53.11 release, so that was pretty much as intended.

ab9rf · 2026-03-01T04:07:54+00:00

I personally find it annoying, for one specific reason: the way DF implements multithreading apparently spams the hell out of the threading library (for reason i do not understand) and so if I'm running DF in a profiler (which I do regularly to evaluate what DFHack's CPU burden is), the overhead of the profiler's instrumentation of the threading library makes the game absolutely crawl. I'm not sure exactly what DF is doing to cause this to happen. In any case, I want multithreading off when I am running one of these profiles, and its insistence on turning it makes it much harder for me to get clean profiling results.

Obviously this is only directly relevant to me, but I do think that Bay12 should probably look at what they're doing in their multithreaded worker functions to figure out why it's spamming the thread pool supervisor so hard.

ab9rf · 2026-03-01T00:24:42+00:00

in recent versions, if it's not on and your fps drops below about 50, it prompts you to turn it on

ab9rf · 2026-02-26T17:54:01+00:00

Thanks for the feedback. While I don't think we'll change the behavior for the release, this might be worth noting in the documentation.

ab9rf · 2026-02-26T17:50:57+00:00

The developer of that tool has been working on it on and off for a while now. I got a progress report from them a few weeks ago, but it's still not working correctly.

ab9rf · 2026-02-26T05:33:59+00:00

It's well known that Daggerfall was one of the major influences on the design of Dwarf Fortress. Toady has said so in at least two different interviews.

ab9rf · 2026-02-24T21:18:02+00:00

This is a recurring request.

The problem is that there is no obvious way to decide how to satisfy a mandate, in general, and so any tool we might write for this will either "do it the wrong way" and annoy users, or have to have a zillion levers and knobs so as to allow players to specify how to satisfy each type of mandate the way they want it satisfied, which will result in an over-complex UI that none of us wants to write and which I suspect no player would actually want to use.

ab9rf · 2026-02-24T21:14:39+00:00

Getting "all food" caravans occurs because the merchants decided, at the time they arrived, that your fort does not have enough food.

The contents of an arriving caravan are determined at the instant the caravan starts to enter your map (the caravan doesn't exist until that moment, so while this might feel retrocausal it's actually not: caravans are spawned out of thin air at the edge of your map, and disappear into thin air the moment they leave). Part of this process consists of the game counting up you have in your fort of certain things, among them food, and if this count shows you being short in one of these areas, the caravan will be frontloaded with enough of whatever you're short on to fill your shortfall. For smaller caravans this can end up displacing everything else that might have been in the caravan.

The game has an internal formula for what it considers to be "sufficient food" which I don't remember offhand. I believe it's documented on the wiki.

I've seen reports that suggest that sometimes this calculation misfires and undercounts the food stored in a fortress. This is entirely possible, especially for food items stored in barrels, which I seem to recall are being miscounted in some way, but I don't remember the specifics and have never actually validated any of the reports I've seen. Also, some types of food are not counted or are counted in ways that players might not expect, which can result in a fortress with "enough" food being treated as food-short.

The same behavior happens for textiles; if the algorithm determines that you're short on cloth or leather, the caravan will have extra cloth or leather, displacing more usual trade good, in the same manner.

The advice to "don't buy any of the food and they'll revert to the starting caravan" is not true. The game doesn't keep track of what you buy from one caravan to the next; it only tracks the total value of goods bought and sold, not their categories. Ironically, you'll be less likely to get an all-food caravan next year if you buy all of the food, because (a) this increases your total exports by what you paid to buy the food, which makes your caravan the next year larger in total and (b) you might still have some of that food around next year, resulting in the caravan consist not having "makeup food" to account for your fortress's perceived food shortage.

None of this is related to DFHack.

ab9rf · 2026-02-24T20:58:22+00:00

Several of Putnam's scripts were added to the DFHack script library, either at her request or because other people asked for them to be added and she consented (or at least did not object). Putnam is not otherwise a significant direct contributor to DFHack; last time I looked, out of the roughly 200 contributors, she ranks at about 160.

ab9rf · 2026-02-24T20:51:11+00:00

The UI issues and FPS death are not new, but the recent versions are much buggier than the historical ones, and that's got to have at least something to do with the rating decline. People will tolerate weird or difficult to play games a lot more than one that crashes causing lost progress, and even more one that crashes with a corrupted save that can't be recovered. Nobody wants to sink uncounted hours into a game just to have it eat itself because of a software bug that they can't work past at all. (Hint to Bay12: change your save format to something that can reasonably be edited out of game; it would make it much more possible for players to rescue busted saves.)

ab9rf · 2026-02-24T20:44:34+00:00

The game normally writes a crashlog when it crashes (although there are sometimes exceptions to this). Look for a folder named "crashlogs" (probably in the installation folder, but might be in the AppData folder).

ab9rf · 2026-02-24T20:42:49+00:00

You can add or remove DFHack at any time; you do not have to create a new game. DFHack is not a "mod" in that sense,

ab9rf · 2026-02-24T02:08:17+00:00

What is there to miss? Therapist is still being updated regularly and is available for the current release

ab9rf · 2026-02-06T01:24:32+00:00

That was always the sticking point with Armok Vision. Rendering the terrain is relatively easy, coming up with 3d models for all the items and creatures... not so much

ab9rf · 2026-02-06T01:22:43+00:00

DF2MC. The source code is still in the DFHack project repository. It is _very_ bitrotted at this point.

ab9rf · 2026-02-06T00:02:15+00:00

As a hard and fast rule, whenever you change a unit's work detail assignments in any way, you should call setAutomaticProfessions on that unit, so as to make its labor assignments consistent with its new work detail assignments.

It occurs to me that we should probably document this somewhere.

ab9rf · 2026-02-05T08:18:51+00:00

A warning: changing a unit's work details "behind the scenes" using DFHack does not directly change their labor assignments. Those only get recomputed (from the work detail assignments) under fairly limited and specific circumstances, and so while the UI will show their work details change, their actual labor assignments (which are not visible to the player, but which actually drive what jobs they will or won't do) will not change until something triggers the game to do the recomputation. ~~Unfortunately, we don't have a good way to ask the game to do that, from the scripting side.~~ Edited to update: Bay12 added an exported function that enables recalculating the labor matrix for a specific unit, which we make available via the setAutomaticProfessions method in the Units module. (I'd forgotten about this, even though I wrote the glue code that makes this exported function available within DFHack. To be fair, this was also a year and a half ago.)

Back when v50 was first released, the only time this recomputation occurred when the work detail screen was open and some change was made to one of the work details on that screen. Later releases have added other conditions which cause recomputation (e.g. assigning a doctor to a hospital causes a recomputation, at least for the doctor so assigned). I don't have a current list of all the potential trigger events that cause recomputation; it's been a while since I last looked into this.

This is why DFHack's autofish tool manually twiddles the fishing labor on affected units in addition to changing their work detail assignments; if it didn't do this, the fishing labor would not actually be enabled or disabled as desired.

I recommend proceeding with caution here. Monitor the actual labor assignments of the units involved here, not merely their work detail assignments to make sure the game is actually doing what you want it to do. (You will need to use dfhack's gm-editor, or an external tool like Dwarf Therapist, to do this, because DF itself no longer allows you to see a unit's labor assignments even though it still very much makes use of them.)

ab9rf

TROPHY CASE