Print

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

[PatrikLundell]

The cause of Nagidal's (and other sufferers') problem is not a DFHack issue, but a possible fix could be...
I don't understand how reading the DF memory could screw up the data structure (while not saying it's impossible just because of my limited imagination), but making use of it (as in changing character data, such as nick names, job allocations, etc.) might. Also, I would advice against doing DT changes while DF isn't paused.
If DT can cause the issue, it would probably be good to have a save where you an provoke it with some degree of reliability to investigate what's happening.
I would be careful with saving in the middle of a migrant/caravan/siege arrival, though, as I believe that has been thought to trigger the issues.

With the merchants I looked for units that were merchants and some other criteria. With migrants I'd start to look at the end of the unit list and also the unit ids following the next visible ones. However, poking around in a bugged save is probably the only way to figure out how to identify the bugged ones (except, of course, understanding what causing the problem and address that, but we seem to be far away from that, struggling with trying to address the symptoms). In fact, I had intended to look at Nagidal's problem about now if a save had been provided.

[Nagidal]

Thank you for your input. I had provided the link to the save in the initial post about this.

Because this problem has cost me one fort already where both migrants and caravans simply stopped arriving, and may cost me this one too, I had figured I should take the same precautions PatrikLundell and feelotraveller have suggested:

• Do not save when groups (migrants, traders, sieges) are entering or leaving the map
• Do not use DT when groups (migrants, traders, sieges) are entering or leaving the map
• Only use DT when the game is paused

It looks like you guys don't need to take any further action now. When my liason finally left the map, the missing/stuck migrant dwarf either sneakily came. I can see him in the unit list now. I don't want to distract you anymore with this off-topic issue. Thanks for your assistance. I'll be using the tool carefully now.

[PatrikLundell]

Sorry for missing the first link.
I've started to look into the issue (before Nagial updated the previous post). As far as I can see Bomrek Mirrorbridges is marked as dead and incoming. He appears as the last migration wave according to DT, but is actually above the second last wave dwarf in the internal DF unit list (by a few units). Toggling the <unit>.flags1.dead flag causes him to move into the fortress, but NOT appear on the any of the DF unit tabs. I've seen a similar issue with "revived" merchants before, i.e. they are there, but not "detected".

Edit:
And yes, allowing DF to do its own thing without hacking causes the migrant to arrive without the "dead" flag set, so apparently we should be careful with interpreting the "dead" flag as meaning "not alive", as well as resetting it without doing whatever unknown things DF does in addition to that to get the unit into play.

[Bumber]

Again, any way to eat things from the ground?

Nope, but you can e.g. haul the item before trying to eat.

I meant a script. Dragons don't have hands, you know.

I don't think you need hands to haul. See if you can get the item there through hackery.

[KittyTac]

Again, any way to eat things from the ground?

Nope, but you can e.g. haul the item before trying to eat.

I meant a script. Dragons don't have hands, you know.

I don't think you need hands to haul. See if you can get the item there through hackery.

Uh, I'm a Dabbling Coder. I will probably royally mess something up.

[Fleeting Frames]

Well, you can make a backup, and have a learning experience.

[KittyTac]

Well, you can make a backup, and have a learning experience.

By that I mean, I can't code for crap and I probably won't be able to do this even if I wouldn't mess something up.

[feelotraveller]

I don't understand how reading the DF memory could screw up the data structure (while not saying it's impossible just because of my limited imagination), but making use of it (as in changing character data, such as nick names, job allocations, etc.) might.

You are quite correct.  My mistake.

If DT can cause the issue, it would probably be good to have a save where you an provoke it with some degree of reliability to investigate what's happening.
I would be careful with saving in the middle of a migrant/caravan/siege arrival, though, as I believe that has been thought to trigger the issues.

Unfortunately the issue arises in middle of a migrant wave arrival.  These are somewhat randomised making it difficult to get a save just before a migrant wave starts, and even then, in my limited experience, you get a different makeup of the migrant wave.  And once it has started saving can cause problems without DT playing a part. 

If I get another one I'll definitely post it (but I prefer touching wood, casting salt over my shoulder, not stepping on cracks...).  In my experience the likelihood of a problem is in the region of 10% so if you are determined you can probably generate your own example.

[PatrikLundell]

I think stuck migrant investigations need to start with looking at cases where migrants are definitely stuck to figure out what they look like. From there I'd try to provoke it with DT while using a stuck detection script (resulting from the first step of the investigation) before and after invoking DT to verify DT is actually responsible.
Personally I delay processing of migrants until all of them are on the map. At that time I assign the animals to pastures and assign jobs to new arrivals. There isn't any benefit in hurrying the job assignment, since migrants will first head to a meeting area and be marked as "new arrival" for quite some time. This is not saying DT shouldn't be made safe if possible, only that a safer usage won't hurt your fortress' efficiency.

[feelotraveller]

Yep, all good. 

Just to note that the issue has arisen for me when changing the labours of dwarfs who are already fortess inhabitants when migrants are incoming.  (Tempts me to speculate that DT overwrites all labours... but that's pure speculation...)  And for some of us ('micromanagers') not changing labours for that long can be excruciating. 

(Btw I think you need to search and replace your last post "I'd" -> "I'll"  )

[PatrikLundell]

I'm fairly micro managery as well, but I've been able to temper it with the realization that delaying the management a bit doesn't change the outcome at all. Interesting data point that changing something unrelated might still cause issues. Would -> will would depend on whether I get my hands on a suitable "seed" save that's bugged and whether someone else does it before me.

[Thundercraft]

Does there already exist a DFhack script to allow the remains of tame or trained animals to be butchered? I searched the DFhack documentation, but I couldn't find anything.

If not, how would I go about flipping the dead_dwarf flag on a specific corpse back to false? I don't want to bring it back to life. But I do want to stop the usual pet-burial behavior in order to butcher it, instead. (See this post in relation to issue 1275.)

[FantasticDorf]

Does there already exist a DFhack script to allow the remains of tame or trained animals to be butchered? I searched the DFhack documentation, but I couldn't find anything.

If not, how would I go about flipping the dead_dwarf flag on a specific corpse back to false? I don't want to bring it back to life. But I do want to stop the usual pet-burial behavior in order to butcher it, instead. (See this post in relation to issue 1275.)

Read a little bit further into the thread and there's a script that automatically turns items to false  by Altree.

I recommend that you persist reading the thread in entirety.

[Fleeting Frames]

There is also DFHack Script: Unbutcherable Sentient Workaround for fortress mode to persistently do it whenever something dies.

[Rumrusher]

well been working on a revised invoke script for adding a new dialog option
and got up to the game adding a new dialog choice

Spoiler (click to show/hide)

Code: [Select]

local dlg=require("gui.dialogs")
local testdia=df.global.ui_advmode.conversation
testdia.choices:insert("#",num)
for nu,choi in pairs(df.global.ui_advmode.conversation.choices) do
if choi==nil then
testdia.choices[nu] = testdia.choices[0]
testdia.choices[nu].choice.type=163
testdia.choices[nu].title[0].value=("Invoke obediance By using The True Name")
testdia.choices[nu].keywords[0].value=("Bond")
end
for nod,mof in pairs(df.global.ui_advmode.conversation.page_bottom_choices) do
if nod == 1 and 0 then
break
elseif nod == 1 then
testdia.page_bottom_choices[nod]=nu
elseif nod == 0 then
testdia.page_bottom_choices[nod]=nu
end
end
end


the issue is I ended up copying the first choice over the new one and the changes effect both... so now I need to figure out how to make a blank choice option to insert any dialog choice... also write a change the only bottom number in a vector for the page bottom choices.