Print

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

[Kainelawless]

Hi.  This is a follow up post from one i made yesterday.

Long story short, i need to alter or delete a unit that's crashing my game outside my fort.  Long story in the link provided.

Appreciate any advice


I don't even know if its possible so letting me know if it isn't is also welcome.


http://www.bay12forums.com/smf/index.php?topic=176834.new;topicseen#new

[PatrikLundell]

I tried to hack the unit pointed out in the bug report used as the "anchor" (The Real Deal) to set the death time in the hist fig entry to year 251, tick 1000, which allowed the save to run until summer (it crashes at 251-3-32 otherwise).

The hfid Quietust gave in the bug report for the OP's crash got the last digits swapped (it should be 78836). Hacking the hf record for this save to set the death date to 451/1000 allowed the save to continue, although a better approach is to set the death tick to a time close to the current time at the start of the save.

Unfortunately, pregnancy info doesn't seem to reside in the hist fig record (or it hasn't been mapped), so tracking down this issue in general seems to be tricky when the unit isn't loaded (i.e. most cases where the unit is offsite), and "abortion" isn't an option.

Note that hacking the hf to just die without any cause (especially if set to die before an event that has already occurred) may well cause issues in the save.

[Kainelawless]

Is this something i could do with df hack or did you use an alternative method?

[PatrikLundell]

Is this something i could do with df hack or did you use an alternative method?

I used the fairly straightforward method of using gui/gm-editor to modify the histfig record, so assuming you know (or can figure out) how to use gui/gm-editor you should be able to do it yourself, but the warning remains: I don't know what the side effects are.

Code: [Select]

gui/gm-editor df.global.world.history.figures[78836]
and change year to 451 (from -1) and year-tick to an appropriate value (1200 ticks per day, 28 days per month, so you'd need to check the date and perform a small amount of math to end up with a time that's close to the current time of the year).

[lethosor]

Referring to the title of the thread: deleting a historical figure outright will likely crash DF, since there are a lot of cross-references between historical figures (and other entities). Tracking those down and removing them is theoretically possible, but there's a good chance we would miss something and still cause a crash. Altering the histfig is a safer option, although the data relevant to the crash isn't loaded until immediately before the crash in this case (see below for details) so it would be tricky.

I tried to hack the unit pointed out in the bug report used as the "anchor" (The Real Deal) to set the death time in the hist fig entry to year 251, tick 1000, which allowed the save to run until summer (it crashes at 251-3-32 otherwise).

The hfid Quietust gave in the bug report for the OP's crash got the last digits swapped (it should be 78836). Hacking the hf record for this save to set the death date to 451/1000 allowed the save to continue, although a better approach is to set the death tick to a time close to the current time at the start of the save.

This is an interesting approach - I'm glad it helps! We could probably add a script to kill a specific off-site histfig to make this a bit easier.

Unfortunately, pregnancy info doesn't seem to reside in the hist fig record (or it hasn't been mapped), so tracking down this issue in general seems to be tricky when the unit isn't loaded (i.e. most cases where the unit is offsite), and "abortion" isn't an option.

Quietust tracked this down on IRC a bit - the unit is saved in one of the unit-N.dat files in the region folder, and is only loaded into memory immediately before the crash, so changing the unit's pregnancy info is difficult (it won't show up in world.units.all even if you scan for it every tick). For reference, historical_figure.nemesis_id points to a nemesis_record whose save_file_id and member_idx refer to the file and position in the file (respectively) where the unit is saved, but not much research has been done on this format (since modifying structures in-memory is typically easier).

[Kainelawless]

I changed the death age and she died before the crash.

The game is about 3 months later and appears stable.

[Atomic Chicken]

I appear to have found another solution to this issue.

Upon loading the save, the game date is as follows:

Code: [Select]

df.global.cur_year = 451
df.global.cur_year_tick = 279374

The crash consistently occurs at:

Code: [Select]

df.global.cur_year = 451
df.global.cur_year_tick = 280010

Note that werebeast syndromes have an active phase spanning from moon phases 27 to 0. The moon phase upon loading is 0, and (if the crash is prevented) switches to 1 at tick 280250.

Looking at the relevant historical figure data (local hf = df.historical_figure.find(78836)), I noticed the following:

Code: [Select]

hf.info.wounds.anon_1 = 451
hf.info.wounds.anon_2 = 279810

See the resemblance? Those anon fields evidently correspond to year and tick respectively, presumably detailing the date of a scheduled event. The similarity between this and the crash date led me to believe that what we have here is the date of delivery.

Loading a different fortress mode save, I found a pregnant dwarf, noted that she too had these fields filled in, and confirmed that they matched the year and tick at which she eventually gave birth. The values persisted after this.

Results:

1) Setting both anon_1 and anon_2 to -1 prevented the crash from occurring (supposedly having removed reference to the upcoming birth).

2) Setting anon_2 to any value from 279600 to 280799 resulted in a crash at tick 280010, as above.

3) Setting anon_2 to values below or above this range prevented the crash from occurring.

[PatrikLundell]

Nice find, Atomic Chicken!

The next question, then is whether these fields can be used, together with the detection of a were curse, to identify problematic weres. Even if the fields are used for other purposes as well, it seems they might be used to identify suspects, at least. It also remains to determine what the best remedy would be. In my view the were curse should terminate pregnancy on the first turning ("healing" the changes caused by pregnancy when turning back), but does the setting of the fields to -1 result in any side effects?

Edit: Exploring the "anon" fields in my fortress, I see they're set for all the fortress members that have given birth, with the year matching the latest birth (or the next one, for the ones who are pregnant). Apart from that, I've got a bunch of female yaks that apparently became hist figs during a siege somewhere, my adopting female cat (rewarded for adoption with a garbage compactor treatment), plus the visitor who gave birth in my fortress and then left without the baby. However, the year is completely off in that case. A possible explanation for that would be that she'd pop out the kid only when back in the fortress during the correct part of the year (after a 12 year pregnancy...), apparently unlike weres. The kid doesn't have any siblings, so it can't be a previous birth.
Unlike the cat, the yaks have no recorded births, but given that the offspring would not be hist figs, it isn't really surprising.

Both the OP's save and "The Real Deal" have these fields set on the were, and in the case of "The Real Deal" there's one other cursed creature with it set as well.

As far as I can see, this seems to be a pregnancy indicator (rather than some kind of general "stuff" one), although it would definitely be useful with a check against more saves.

[Atomic Chicken]

2) Setting anon_2 to any value from 279600 to 280799 resulted in a crash at tick 280010, as above.

3) Setting anon_2 to values below or above this range prevented the crash from occurring.

Thinking about this, ticks 279600 to 280799 correspond to the start and end of the following day (a day is 1200 ticks in length). Perhaps off-site births scheduled to occur on a particular day are all processed at a particular time irrespective of the specific scheduled time of birth? In that case, setting the due date below the specified 1200 tick range does nothing possibly because the current day's births have already been handled, even though the day isn't over yet.  Whereas setting it to any time in the following day might result in the birth being processed at a tick where the werebeast transformation is still active, even if the birth is scheduled to occur after the expected reversion of the curse (tick 280250). Above this range, giving birth is safe as the transformation is inactive all throughout the subsequent day.

The next question, then is whether these fields can be used, together with the detection of a were curse, to identify problematic weres. Even if the fields are used for other purposes as well, it seems they might be used to identify suspects, at least. It also remains to determine what the best remedy would be. In my view the were curse should terminate pregnancy on the first turning ("healing" the changes caused by pregnancy when turning back), but does the setting of the fields to -1 result in any side effects?

I think it would be fairly straightforward to identify problematic weres by scanning the histfig list every so often, detecting figures with a werebeast curse, checking for pregnancy as above, and calculating the moon phase at the due date to check whether there will be an active transformation on that day. Then either remove it or delay it by a couple of days. I didn't notice any adverse effects, but I didn't test thoroughly enough to say for certain.