Print

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

[Malachi108]

My relatively long-running (35 years) fort encountered a problem - upon reaching a certain date (around Opal 7, could be one or two days off) the game repeatedly crashes 100% of the time. Among things I have tried are: disabling all current jobs and constructions, locking all dwarves in a burrow to stop even jobs like eating or drinking, sending every single dwarf away on missions so that the only dwarves present when that date arrives are children. None of those had any effect - save is located here.

I have already posted this as a bug in Mantis, but then noticed several other bugs describing a similar issue. In all cases, the crash seems to be related to a werebeast somewhere in the world giving birth while in a transformed state. The date of the crash - always following Opal 4 - seems to confirm that this is indeed the case for me as well.

Now the question is: are there any ways to deal with this problem? It appears that people with debugging tools can identity the specific werecreature causing the crash, but then it could still be anywhere in the world beyond my reach. Is there anything left that can be done here or is the entire world now cursed and the 35-old fort simply has to be abandoned?

[Bumber]

There's a fix for the issue somewhere on the forums, but I can't seem to find it at the moment. Pregnancies are stored in the historical figure's wounds data, so it's a matter of finding a werebeast histfig with that data and altering it with DFHack.
Edit:
Found the relevant script here: https://github.com/DFHack/dfhack/issues/1603

Code: [Select]

function x ()
  for i, hf in ipairs (df.global.world.history.figures) do
    if hf.info and
       hf.info.curse and
       hf.info.wounds and hf.info.wounds.anon_1 >= df.global.cur_year then
      hf.info.wounds.anon_1 = -1
      hf.info.wounds.anon_2 = -1
      dfhack.println ("Aborting pregnancy on cursed " .. dfhack.TranslateName (hf.name, true) .. "/" .. dfhack.TranslateName (hf.name, false))
    end
  end
end

x ()
You might need to replace anon_1 and anon_2 with childbirth_year and childbirth_tick, depending on DFHack version.

[Malachi108]

Thank you!

So the way to kill the creature exist, but how to determine which one? Do I need some specific tools for it? I doubt simple Legends mode would help.

[PatrikLundell]

The script Bumber provided terminates the pregnancies of all werebeasts in the world, listing them as they're processed.

You can modify the script to not terminate the pregnancy, but just print the hfid of each figure for manual manipulation, or set the fields for time of death instead of pregnancy termination.

Is there a specific reason you'd rather kill the were than terminate the pregnancy, or is it just that reading scripts isn't one of your strengths (not intended as any kind of accusation)? The script should remove the crash, and if the script fails, replace the two strings Bumber mentioned with their replacement and try again.

To use the script, create a "text" file called e.g. "fix_were_pregnancy.lua" in <DF>\hack\scripts and copy-paste the script posted into the file (saving it). Invoke the script by typing "fix_were_pregnancy" (without the quotes) into the DFHack terminal window (if you chose a different name for the file you'd use that name instead).

[Malachi108]

After installing the latest DFhack version, I have attempted to run the script exactly as listed above and received a series of errors. I then replaced anon_1 and anon_2 with parameters childbirth_year and childbirth_tick and running the script no longer returns an error.

Unfortunately, it seems to have produced no results either. No actions were printed in the console and the game still crashes as before. I am honestly unsure whether my problem is something else unrelated to werebeasts or I have simply messed up running the script somehow.

Could anyone actually familiar with lua and DFhack run the script on my save perhaps, just to make sure that the crash isn't werebeast-related?

[Bumber]

Looks like none of your werebeasts are pregnant. I tried the fix for raiding corruption bug:

Code: [Select]

function fix_equipment ()
  local categories =
    {{"FLASK", df.item_flaskst},
     {"WEAPON", df.item_weaponst},
     {"ARMOR", df.item_armorst},
     {"SHOES", df.item_shoesst},
     {"SHIELD", df.item_shieldst},
     {"HELM", df.item_helmst},
     {"GLOVES", df.item_glovesst},
     {"AMMO", df.item_ammost},
     {"PANTS", df.item_pantsst},
     {"BACKPACK", df.item_backpackst},
     {"QUIVER", df.item_quiverst}}
 
  for i, element in ipairs (categories) do
    for k = #df.global.ui.equipment.items_unassigned [element [1]] - 1, 0, -1 do
      if df.global.ui.equipment.items_unassigned [element [1]] [k]._type ~= element [2] then
        dfhack.printerr ("Corrupted unassigned " .. element [1] .. ", removing", k)
        df.global.ui.equipment.items_unassigned [element [1]]:erase (k)
      end
    end
  end
 
  for i, element in ipairs (categories) do
    for k = #df.global.ui.equipment.items_assigned [element [1]] - 1, 0, -1 do
      if df.global.ui.equipment.items_assigned [element [1]] [k]._type ~= element [2] then
        dfhack.printerr ("Corrupted assigned " .. element [1] .. ", removing", k)
        df.global.ui.equipment.items_assigned [element [1]]:erase (k)
      end
    end
  end
 
  for i, squad in ipairs (df.global.world.squads.all) do
    if squad.entity_id == df.global.ui.group_id then
      local squad_name = dfhack.TranslateName (squad.name, true)
      if squad.alias ~= "" then
        squad_name = squad.alias
      end
     
--      dfhack.println (squad_name, i)
     
      for k, position in ipairs (squad.positions) do
        for l, item_id in ipairs (position.assigned_items) do
          local legal_type_found = false
          local item = df.item.find (item_id)
         
          if not item then
            dfhack.printerr ("Nonexistent item assigned to squad member " .. tostring (k) .. " of squad " .. squad_name ..
                             ". Detection only. No action performed.")
           
          else
            for m, element in ipairs (categories) do
              if item._type == element [2] then
                legal_type_found = true
                break
              end
            end
           
            if not legal_type_found then
              dfhack.printerr ("Item " .. tostring (l) .. " assigned to squad member " .. tostring (k) .. " of squad " .. squad_name ..
                               " is of unexpected type " .. tostring (item._type) ..  ". Detection only. No action performed.")
            end
          end         
        end
      end
    end
  end
end

fix_equipment ()

Results:

Code: [Select]

Corrupted unassigned GLOVES, removing   860
Corrupted unassigned PANTS, removing    875
Corrupted assigned ARMOR, removing      60
Corrupted assigned SHIELD, removing     79
Corrupted assigned SHIELD, removing     61
Corrupted assigned SHIELD, removing     35
Corrupted assigned HELM, removing       98
Corrupted assigned HELM, removing       97
Corrupted assigned PANTS, removing      51
You've definitely got equipment list corruption, but it still crashes after the fix.

Edit: Looks like you have to run it again after a few days. Some more pants got corrupted, and then a second time. I'm on Opal 14 and no crash.

[delphonso]

DF: Crashes.

Community: Have you tried aborting every child in the game?
Community: Nah wait it was just some pants.

[PatrikLundell]

Hm, wait a minute. I think Toady should be notified about this save if it can reliably cause the lists to get corrupted again, as that ought to provide a way for him to find what causes (that particular) corruption.

[Eric Blank]

That's a great idea. A reliable crash with a reliable fix should help resolve the issue permanently.

[PatrikLundell]

That's a great idea. A reliable crash with a reliable fix should help resolve the issue permanently.

I'm fairly sure there is more than one cause. Toady's attempt to fix the bug probably fixed one or more cases. My fortress can't raid due to being from a dead civ, and yet I've had a corruption happening (I worked around it by restoring a backup half a year older, made for a completely different reason). My suspicion in that case are bugged performance troupe members that "return" as moronic "friendly" units after some portion of the troupe has been accepted as residents after a petition, but that's just a guess.

However, every cause taken care of is one cause less.

[Malachi108]

Looks like you have to run it again after a few days. Some more pants got corrupted, and then a second time. I'm on Opal 14 and no crash.

Thank you so much, running that script actually helped!

Just like you, I had the initial corruption fixed, then a few more after 5 days or so which the script also took care of. After that it has been running smoothly for 3 months now, with the script returning no further issues.

[Immortal-D]

Yet another example of 'not wearing pants' solving the world's problems.

[Garfunkel]

How do I run that script in DFHack? And can I run it whenever I want, to ensure that I'm not getting any crashes in the future?

[PatrikLundell]

How do I run that script in DFHack? And can I run it whenever I want, to ensure that I'm not getting any crashes in the future?

You run DFHack scripts by copy them into a file named <scriptname>.lua. The file should be located in <DF>\hack\scripts, and you run them by tying the script name into the DFHack console (without ".lua").

The script should do nothing if no corruption isn detected, but cases have been found where the corruption is bad enough that the script crashes (together with DF).