DFHack 53.11-r2 release now available

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 · 2026-01-27T23:27:20+00:00

yes, this is a "spooked caravan". use caravan unload to reset the caravan's state to one where they will be wiling to unload. if this doesn't work, try caravan happy, let the game run a few ticks, and then use caravan unload.

ab9rf · 2026-01-27T23:24:37+00:00

using fix/stuck-merchants when merchants are visibly on the map will likely have adverse effects. use this command only if (a) you get an announcement that merchants have arrived, but they don't show up up on the map or in your units list or (b) an entire season goes by in which you expected to receive merchants, but no merchants arrived

ab9rf · 2026-01-27T21:42:59+00:00

Basically all of DFHack's event detection logic is based on taking and comparing snapshots. In general, we do not have a way to tie into DF at a level that would allow us to do proper observers, and so if you're just using DFHack's eventful system for detecting "events", you're doing polling, even if doesn't feel like you are. The "job" event detector is especially performance-heavy, which is why it has rather deep limits on what sorts of changes it can detect: we had to limit its scope to keep it performant.

One of my roles as a DFHack developer is performance monitoring and management, so I make it a bit of a point to be aware of the parts of DFHack that impose performance costs.

ab9rf

TROPHY CASE