|Anonymous | Login | Signup for a new account||2020-03-30 13:12 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0010369||Dwarf Fortress||Dwarf Mode -- Military||public||2017-11-26 20:59||2018-07-01 12:39|
|Platform||PC||OS||Windows 10||OS Version||64-Bit|
|Target Version||Fixed in Version|
|Summary||0010369: Game crash (likely) when Dwarves return from mission|
|Description||When I send dwarves on a mission, I think mostly when it involves "exploring" places and where places are rumored to have artifacts, the Dwarf Fortress window closes randomly after all of the dwarves have left the map, after some amount of time. Presumably, the game is crashing when the dwarves are returning from the mission.|
|Steps To Reproduce||1. Go into the (as previously known) [C]ivilization menu.|
2. Choose a location to send a squad of dwarves, specifically where artifacts are rumored to be. (May also matter if they are "exploring" versus "raiding")
3. Wait until all dwarves have left.
4. Sometimes, they will return, sometimes, it will crash.
May need to test further to see if crash occurs after they return but as they are bringing back rescued hostages/people seeking sanctuary.
|Additional Information||Saves: |
http://dffd.bay12games.com/file.php?id=13236 [^] (0.44.02)
http://dffd.bay12games.com/file.php?id=13476 [^] (0.44.05)
http://dffd.bay12games.com/file.php?id=13371 [^] (0.44.03)
raid duplicate equipment saves:
0010411: http://dffd.bay12games.com/file.php?id=13271 [^] (papabrando)
0010710: http://dffd.bay12games.com/file.php?id=13683 [^] (behbehr)
0010711: http://dffd.bay12games.com/file.php?id=13684 [^] (Madrawn)
0010720: http://dffd.bay12games.com/file.php?id=13700 [^] (cooldudeshitlord)
0010733: http://dffd.bay12games.com/file.php?id=13713 [^] (Buttery_Mess)
0010735: http://dffd.bay12games.com/file.php?id=13716 [^] (randomoddguy)
0010738: http://dffd.bay12games.com/file.php?id=13718 [^] (mrmagolor)
|Tags||No tags attached.|
|5 dorfbucks says this is due to them trying to talk to an unknown entity.|
I have this happen when all of the attacking squads leaders die or get captured.
Check if your squads have "VACANT" at the first position some time after sending them.
edited on: 2017-12-01 10:33
My fort was imported from 43.05.(oops double edit)
I think i have this issue, i was raiding a site with no population so i think its definitely to do with exploring as opposed to raiding.
Raiding towers worked at least.
Still happens in 44.03. Sent two squads on the same raid of a goblin outpost,and now the game crashes everytime they come back.
Also when i look into my squads none of the positions are VACANT, so I dont think it has to do anything with dworfs dying, or it simply doesnt show up if someone is dead before they return.
edited on: 2018-01-02 06:17
Here is a save a few moments before the game crashes. The Squad is in the process of entering the map. The dwarves that come back even carrying the loot as the report says. One thing special is that the artifact battle axe is strapped to the back of one of the dwarves. 44.03
Edit: Sorry, it doesn´t happen anymore with this savefile. But I tried it a few times from the seasonal save (9 ingame days) and it always crashed. But the save at the moment of the return seems to work
Edit2: So I had the same situation again. And saving while the squad enters the map fixed the problem again
mischief from Freenode provided this save, which seems to be the same issue. It crashed the first 3 times I loaded it after around 5-10 seconds, but on the 4th attempt, a squad returned around the same time, so I think it's another instance of this bug.
|Still having this issue in 44.06. As much as I'd love to pillage and raid, the unpredictable crashes just ruin the experience.|
edited on: 2018-03-18 08:37
44.06 and 44.07 it crashes when (presumably) my squad returns. When I retire the fortress and reclaim it, my squad is back with all their kills in their kill list.
EDIT: Received a pop up with the crash that read "Nemesis unit load failed"
Iteb Abantulon, member of squad sent to explore a ruin, comes home in a migrant wave. The game crashes soon after that. Reproducible every time.
edited on: 2018-03-24 09:53
Squad of 4 comes back from a raid, as soon as they return the game immediatley crashes.
I was lucky to even see the message saying that they returned.
Every one in the squad is displayed as VACANT in the [m]ilitary view, but ONLY if viewing equipment.
When viewing the squad normally, it says they are just traveling.
Seems my squad was wiped out.
|For me raiding is fine in in the beginning of a fort but crashes after a year or two when raiding. Tested in a few worlds.|
edited on: 2018-05-01 09:45
I've had frequent (but not consistent) issues with a similar issue. After a raid finishes, sometimes saving will cause a crash RIGHT after saving seems almost finalized. Starting the game again will reveal the save loads as though nothing went wrong, with no problems apparent. However, on loading the save it will print errorlogs such as this:
NULL play item on load: id 0000560
NULL play item on load: id 0000947
Site Map: Extra Item Occupancy 72,99,131
(Edited by lethosor: thought pre tag would avoid linking to issues, but apparently not)
This save is in the middle of a raid. Wait a couple minutes, and it will crash after they return. The site had a rumored artifact and the mission was Raid and destroy site. I've tried running it several times and always get the crash.
Before this save I sent them on the same mission, and got the same crash, but didn't realize it was the raid until I saved in the middle of my second attempt.
edited on: 2018-04-15 20:32
I have this in 44.09 if I send a squad without a squad leader, when it tries to return it crashes. (Nevermind. Crashes upon return even if I send it out with all squads members and leaders full.)
I have this save from my own bug report which is a child of this one; from 0.44.09 (though using a save from an older version that was fairly recently ported to 0.44.09)
http://dffd.bay12games.com/file.php?id=13718 [^] [^]
Toady One (administrator)
In two of the saves, the members of the squad appear to be offloaded in the unit file wearing the same helmet, which it doesn't like when they both arrive and are loaded. I have no idea how this came to pass. My current hypothesis is that they switched hats between missions and somehow the files got out of sync, but that might not be it, and if that is it, I'm not sure when or how it happened.
I'll probably be able to patch the symptom, so that saves early in the corruption can go on and new corruption will not cause huge ongoing problems, but fixing the root of it will be harder.
Toady One (administrator)
edited on: 2018-05-02 21:56
Okay, of six saves tested, four responded to a patch (and will give an error log entry for duplicate inventory items so we know it is still going on.) For the other two saves, one didn't reproduce promptly, and one crashed but seems unrelated so far (to squads or anything else here.) So hopefully the next version will stop most of the squad crashes while we continue to search for the root cause of the inventory corruption.
|Not sure if this is the case, but I have an idea about what might be causing the duplicate inventory. I have noticed that when squads receive a change in orders, they sometimes do not fully finish the activity they were doing, so e.g. if they were reading a book in the library and I make them active, they will sometimes carry the book they were reading to duty. Maybe when the raid order was given, one of the squad was in the process of picking up a new helmet, and his current helmet was designated to the next lower down squad member, but the picking up new equipment activity was interrupted and they both ended up going off map with the same designated helmet?|
Toady One (administrator)
|The item was saved in both dwarves' physical possession, and that's the part that is getting out of sync. So somewhere, it does have to be a technical bug rather than something to do with designations, though the issue you are describing might be part of the lead up to how it happens. It is somehow using saved versions of two different offloaded inventories, though, which is going to be difficult to solve by observation, as that all happens using invisible timers off the screen.|
|Is there a workaround or something to prevent this from happening?|
|@marra1996: Don't send anyone on raids, that should prevent this type of crash :D|
|@marra1996: The current release (v0.44.10) prevents the majority of raid-related crashes previously reported; if you have a raid crash that occurs in v0.44.10 it should be logged as a separate report.|
|@Loci my crash in 0010369 is still happening with 0.44.10 :(|
|My crash, however, HAS been fixed, which is great! Unfortunately the emotions update is causing a tantrum spiral, but it happens.|
edited on: 2018-07-01 12:39
Still crashes for me in 44.11 (on a fort made in 44.11) but it's oddly not repeatable/100% on a save i did for it.
On a same gob site i sent 3 dwarves squads in a raze mission, first time i did it crashed once they came back as usual.
2nd time i reloaded the save it went smoothly and they returned without a problem but after i resent them to finish the site (as there were still gobs in it), the game crashed when they returned.
|2017-11-26 20:59||ANormalUsername||New Issue|
|2017-11-26 23:03||ArmokGoB||Note Added: 0037044|
|2017-11-27 07:45||Rafal99||Note Added: 0037051|
|2017-11-27 07:46||Rafal99||Issue Monitored: Rafal99|
|2017-11-29 13:01||Dwarfu||Assigned To||=> Dwarfu|
|2017-11-29 13:01||Dwarfu||Status||new => acknowledged|
|2017-12-01 10:27||Syndras||Note Added: 0037164|
|2017-12-01 10:28||Syndras||Note Edited: 0037164||View Revisions|
|2017-12-01 10:33||Syndras||Note Edited: 0037164||View Revisions|
|2017-12-03 07:50||Loci||Relationship added||related to 0010411|
|2017-12-27 02:03||Albino||Note Added: 0037407|
|2018-01-01 16:17||Melmarkian||Note Added: 0037462|
|2018-01-01 16:27||Melmarkian||Note Edited: 0037462||View Revisions|
|2018-01-02 06:17||Melmarkian||Note Edited: 0037462||View Revisions|
|2018-02-01 22:52||lethosor||Relationship replaced||parent of 0010411|
|2018-02-01 22:52||lethosor||Relationship added||parent of 0010499|
|2018-02-01 22:53||lethosor||Relationship added||parent of 0010541|
|2018-02-01 22:55||lethosor||Note Added: 0037733|
|2018-02-01 22:56||lethosor||Additional Information Updated||View Revisions|
|2018-03-11 08:01||EtherealPsyche||Note Added: 0037877|
|2018-03-16 12:50||chrissypee||Issue Monitored: chrissypee|
|2018-03-16 17:25||Abstker||Note Added: 0037950|
|2018-03-18 08:37||Abstker||Note Edited: 0037950||View Revisions|
|2018-03-24 09:39||ssk||Note Added: 0038011|
|2018-03-24 09:49||marra1996||Note Added: 0038012|
|2018-03-24 09:51||marra1996||Note Edited: 0038012||View Revisions|
|2018-03-24 09:51||marra1996||Issue Monitored: marra1996|
|2018-03-24 09:53||marra1996||Note Edited: 0038012||View Revisions|
|2018-03-25 20:24||lemtoad||Note Added: 0038030|
|2018-03-26 01:11||chaosvolt||Note Added: 0038031|
|2018-03-26 14:29||theLittleManInABigSuit||Note Added: 0038037|
|2018-04-15 20:28||wormxwood||Note Added: 0038168|
|2018-04-15 20:32||wormxwood||Note Edited: 0038168||View Revisions|
|2018-04-16 08:46||Huntthetroll||Issue Monitored: Huntthetroll|
|2018-04-17 15:59||Loci||Relationship added||related to 0010710|
|2018-05-01 07:43||Loci||Relationship added||parent of 0010738|
|2018-05-01 07:44||Loci||Relationship added||parent of 0010621|
|2018-05-01 07:45||Loci||Relationship added||parent of 0010735|
|2018-05-01 07:46||Loci||Relationship added||parent of 0010733|
|2018-05-01 07:46||Loci||Relationship added||parent of 0010720|
|2018-05-01 07:48||Loci||Relationship added||parent of 0010711|
|2018-05-01 07:49||Loci||Relationship added||parent of 0010691|
|2018-05-01 07:50||Loci||Relationship added||parent of 0010685|
|2018-05-01 07:53||Loci||Status||acknowledged => confirmed|
|2018-05-01 07:59||Loci||Sticky Issue||No => Yes|
|2018-05-01 09:43||lethosor||Note Edited: 0038031||View Revisions|
|2018-05-01 09:44||lethosor||Note Edited: 0038031||View Revisions|
|2018-05-01 09:44||lethosor||Note Edited: 0038031||View Revisions|
|2018-05-01 09:45||lethosor||Note Edited: 0038031||View Revisions|
|2018-05-01 14:02||mrmagolor||Note Added: 0038237|
|2018-05-02 12:31||Loci||Relationship added||parent of 0010742|
|2018-05-02 20:45||Toady One||Note Added: 0038244|
|2018-05-02 21:56||Toady One||Note Added: 0038246|
|2018-05-02 21:56||Toady One||Note Edited: 0038246||View Revisions|
|2018-05-03 05:45||sionlife||Note Added: 0038248|
|2018-05-03 12:11||Toady One||Note Added: 0038250|
|2018-05-06 07:32||marra1996||Note Added: 0038257|
|2018-05-06 10:05||Loci||Relationship added||has duplicate 0010748|
|2018-05-06 10:17||Loci||Relationship replaced||has duplicate 0010710|
|2018-05-06 10:18||Detros||Note Added: 0038260|
|2018-05-06 10:24||Loci||Relationship replaced||has duplicate 0010711|
|2018-05-06 10:38||Loci||Relationship replaced||has duplicate 0010735|
|2018-05-06 10:38||Loci||Issue Monitored: randomoddguy|
|2018-05-06 10:44||Loci||Relationship replaced||has duplicate 0010720|
|2018-05-06 13:05||Loci||Relationship replaced||has duplicate 0010733|
|2018-05-06 13:59||Loci||Relationship replaced||has duplicate 0010411|
|2018-05-06 14:05||Loci||Relationship replaced||has duplicate 0010738|
|2018-05-06 15:22||Loci||Note Added: 0038274|
|2018-05-06 15:22||Loci||Additional Information Updated||View Revisions|
|2018-05-08 00:44||ejtttje||Note Added: 0038288|
|2018-05-08 05:17||mrmagolor||Note Added: 0038289|
|2018-07-01 12:39||Robsoie||Note Added: 0038516|
|2018-07-01 12:39||Robsoie||Note Edited: 0038516||View Revisions|
|2018-08-23 08:11||lethosor||Relationship added||related to 0010875|
|2019-05-11 20:50||risusinf||Issue Monitored: risusinf|
|2020-01-06 16:35||BudTomazi||Issue Monitored: BudTomazi|
|Copyright © 2000 - 2010 MantisBT Group|