View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010911 | Dwarf Fortress | Miscellaneous Crashes | public | 2018-09-29 09:49 | 2020-11-24 11:27 |
| Reporter | PatrikLundell | Assigned To | lethosor | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | duplicate | ||
| Platform | PC | OS | Windows | OS Version | 10.1 |
| Product Version | 0.44.12 | ||||
| Summary | 0010911: The referenced save game crashes after just over 10 seconds | ||||
| Description | The 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 http://dffd.bay12games.com/file.php?id=14043 | ||||
| Additional Information | I'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. | ||||
| Tags | No tags attached. | ||||
|
|
I've lost my next fortress to the same or a similar bug http://dffd.bay12games.com/file.php?id=14083. 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). |
|
|
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. |
|
|
Confirmed as a duplicate of 0011014 on 64-bit Linux 0.47.04 - see https://github.com/DFHack/dfhack/issues/1678 (which you're already following) for details. |
| 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 | |
| 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 |
