Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010911Dwarf FortressMiscellaneous Crashespublic2018-09-29 09:492020-11-24 11:27
Assigned Tolethosor 
PlatformPCOSWindowsOS Version10.1
Product Version0.44.12 
Target VersionFixed in Version 
Summary0010911: The referenced save game crashes after just over 10 seconds
DescriptionThe save game was saved with DFHack's quicksave and crashed when I continued playing. After a few attempts with the same result (differing only in slight differences in reports at the bottom of the screen, such as lost training and masterworks production) I disabled DFHack and retried it a number of times, with the same result. I've also tried switching display mode from STANDARD to 2D with no change. Except for the first attempts, the only action I performed after loading the save was to unpause.
The crash is in the form of the DFHack window closing, not a popup-message.

The save has been uploaded as [^]
Additional InformationI've tried it on one computer only (easily used alternatives are not available).

The world is a PSV world where all surface biomes were DFHacked to support all legal plants and animals and glaciers made Evil during world gen. Raws have been changed to make Gremlins kobold sized to allow them being clothed before going bonkers, banana changed to provide wood to appear on the embark, all siege triggers set to one and all (semi)megabeast attack triggers lowered. Goblins were set to start on glaciers only, and the max number of dwarven civs reduced. The civ played should be dead but isn't and was made to be playable (as struggling) by adding it to the list of playable civs with a DFHack script (it was culled by DF), and the embark world tile was hacked by another script to ensure 9 biomes were present in the 3*3 embark area.
LNP r03 is used with the Phoebus tileset (and the world was created with this version), and DFHack Performance tweaks were enabled before the crash.

I've used DFHack as part of my game play, but probably not something related to the crash, as the only auto repeating scripts are the Performance Tweak ones. I've manually named visitors to recognize them when they petition again (and again...), use a script to enable/disable gathering zones and farm plots (once per year), a script to mark trees for cutting (sparing the booze fruit bearing ones), etc.

It can be mentioned that I've had a fair number of crashes of the same kind earlier with this fortress, but they haven't been repeatable: loading the latest save and continuing have not resulted in a new crash.
TagsNo tags attached.
Attached Files

- Relationships
duplicate of 0011014confirmedLoci Reproducible crash from corrupted military equipment lists 

-  Notes
PatrikLundell (reporter)
2018-10-24 06:59

I've lost my next fortress to the same or a similar bug [^]
This world was generated using the same set of changes as the previous one, although the civ played is one that isn't dead or even struggling (and thus not added to the list of playable civs). The max number of dwarven civs was set to 3. In addition to this, the embark was hacked pre embark to move an adamantine spire into the embark (for 4 spires) and extend the spires to reach the 1:st cavern.

As with the previous fortress, I've been plagued with frequent non repeatable crashes (sufficiently common to change my DFHack quicksave frequency from once per month to twice per month). This save has crashed within a week (probably 4 days) every time I've tried it, both with and without DFHack. The time it takes to crash varies slightly, though. I've tried some light fault finding with no results, such as disabling visitors, killing half the visitors with DFHack's exterminate, killing the elven caravan with DFHack, and not responding to the petition that appears after a couple of days, but nothing has resulted in any change. When run without DFHack, the game freezes for about half a second before DFHack disappears (without generating an application crash popup).
lethosor (manager)
2018-11-07 15:20
edited on: 2018-11-07 15:36

With the number and extent of permanent world modifications you've made with DFHack, I'm hesitant to confirm this as an issue with DF. Toady is probably the only one who can determine that. I can check whether it crashes on my end, at least.

Edit: yeah, crashes in 0.44.12, 64-bit OS X, without DFHack. Crash reports aren't super helpful, unfortunately. It does crash at 0x100000000 + 11173111 consistently in that build, at least.

lethosor (manager)
2020-11-24 11:27

Confirmed as a duplicate of 0011014 on 64-bit Linux 0.47.04 - see [^] (which you're already following) for details.

- Issue History
Date Modified Username Field Change
2018-09-29 09:49 PatrikLundell New Issue
2018-10-24 06:59 PatrikLundell Note Added: 0038894
2018-11-07 15:20 lethosor Note Added: 0038925
2018-11-07 15:36 lethosor Note Edited: 0038925 View Revisions
2019-02-24 12:04 Loci Relationship added child of 0011014
2020-11-24 11:27 lethosor Note Added: 0040801
2020-11-24 11:27 lethosor Relationship replaced duplicate of 0011014
2020-11-24 11:27 lethosor Status new => resolved
2020-11-24 11:27 lethosor Resolution open => duplicate
2020-11-24 11:27 lethosor Assigned To => lethosor

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker