Print

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

[Toady One]

Download (Click refresh on your browser if it doesn't show up)

And the linux freeze fix process broke projectiles.  So that's hopefully all working all around now.

Major bug fixes
   (*) Made projectiles and weapon traps work again

Other bug fixes/tweaks
   (*) Changed w.g. population calculation for conflicts

[Shonai_Dweller]

So I seem to have a repeatable worldgen crash. Similar to ones others have reported on the tracker, large region, gets to around 400 years before crashing.

The only issue is that this is in my modded world. There's a lot of raw changes with new races and such. While I'm pretty sure the modding itself isn't to blame (it works almost all of the time and this seems similar to reports on the tracker), would it be a waste of time posting the seed, settings and my raws?  Can anything useful be deduced from them?

[Toady One]

Probably?  If it doesn't reproduce, it won't take too long, especially if I set it running when I'm doing other things, and if it does reproduce a crash (modding or not), then that'll be very useful.

edit: the "probably" meant something useful could be deduced, not that it would probably be a waste of time

[GM-X]

Probably?  If it doesn't reproduce, it won't take too long, especially if I set it running when I'm doing other things, and if it does reproduce a crash (modding or not), then that'll be very useful.

So I seem to have a repeatable worldgen crash. Similar to ones others have reported on the tracker, large region, gets to around 400 years before crashing.
The only issue is that this is in my modded world. There's a lot of raw changes with new races and such. While I'm pretty sure the modding itself isn't to blame (it works almost all of the time and this seems similar to reports on the tracker), would it be a waste of time posting the seed, settings and my raws?  Can anything useful be deduced from them?

I've found that medium and large Dark Ages worlds often crash well before the year 1000 with no error messages. Either that, or come to a crawl during world generation around year 300. Pocket worlds on the other hand virtually never crash if they survive past 100-years or so. DA worlds never leave the Age of Myth, so I've assumed that (megabeast percentage) and or hyper active civs had something to do with it.

[Shonai_Dweller]

OK, here's my worldgen crash. It's my whole DF folder (some raw modding, new races and stuff, tileset, one extra speech file - think that's all)
http://dffd.bay12games.com/file.php?id=13640

Advanced Worldgen > "Beastly Region - Crash Test"

Tested 4 times, 4 crashes at around 170 or so years in. Playing in Windows 10 64 bit.
It runs through 243 rejections before starting and actual worldgen is kind of slow because I just love my hist-fig filled worlds. Sorry about that.

Can usually run worlds up to 450 years with the same settings. Get a crash once every 10-20 generations I guess.

[PatrikLundell]

I've got a reproducible Nemesis Unit Id Load crash save appended to #0009985. The crash originally happened in 0.44.05, but also happens when the save is loaded into 0.44.08 and 0.44.09.

Repeating the bug report info I posted (to save looking up the report):
I've got a save that crashes in 0.44.08 vanilla (2 times out of 2 attempts). https://www.dropbox.com/s/0tz7syg6sd770as/region6%20-%20Nemesis%20Load%20Id.zip?dl=0 [^] as the save has bloated to a far larger size than DFFD accepts (the saves of this fortress once were small enough to fit).
After half a minutes or so a message that no more quires can be produced appears. Seconds later the nemesis load id fatal error box pops up (I don't expect the events to be related, but it gives an indication of when to expect the crash).

This world was generated with 0.44.X (don't remember the version, but that info is in the data anyway). It's been migrated between LNPs to 0.44.04 r03. Thus, DFHack and the Phoebus tile set was used. Raws were changed to lower attack triggers for (semi)megabeasts and all siege triggers were set to 1. Goblins were changed to start on glaciers exclusively.
The world is a PSV world where DFHacking added all legal plants/animals to all surface biomes, and all glaciers were made evil. During world gen dwarven civs that ought to be dead were slabbed, and during embark dead dwarven civs were added to the list of ones you can embark as. One of those was chosen. Later Orkel's alcohol syndrome work around was applied (the game was actually PLAYED in 0.44.05, with the save copied to 0.44.08 after the detection of the crash), and banana trees were modified to yield logs, and without it they never show up (separate bug report). The bug was repeated with the 0.44.05 save before I copied it to the 0.44.08 folder (and since it crashed, the save is actually still the same 0.44.05 save).
Before this even I've experience the crash twice, but they weren't repeatable. About two months before the crash a 0010681 Smash & Grab report cave-in into an adamantine pillar was made, but without actually breaching the pillar. This save can actually be used with that report by channeling out the NE corner of the spire that has obsidian fused into its top (the SE spire).
It can be mentioned that this fortress has not engaged in any raiding, so it shouldn't be related to those issues (and the fortress is the only one played in this world).

Edit: Missing info: Windows 10.1, 64 bit DF version.

[Warlord255]

Lovely work as always, Toady! However, I've got an issue that you might need to look at.

http://www.bay12games.com/dwarves/mantisbt/view.php?id=10677

Dwarves who die on raids apparently cease to exist. I don't have a before-and-after of my current save, but it's glaringly obvious - one of my starting seven died on a raid, and now he's no longer listed as a friend to any of the rest. Likewise, no slabs can be made. It's a real buzzkill for the raiding release.

[Orkel]

   (*) Changed w.g. population calculation for conflicts

Does this make it harder or more deadly to send raids against high pop sites? What is the gameplay effect of this bugfix?

[PatrikLundell]

   (*) Changed w.g. population calculation for conflicts

Does this make it harder or more deadly to send raids against high pop sites? What is the gameplay effect of this bugfix?

If taken literally, it does not have any game play effect at all, as it is a world gen change, presumably leading to more reasonable outcomes in battles where the defender has a large number of non hist figs and slave/animal/undead warriors. Thus, it seems to be a case of carrying raiding introduced accounting for these back to world gen. The underlying raiding change would then be the one that should account for undead when raiding a necro tower, for instance, which should already be implemented.

[Toady One]

Tested 4 times, 4 crashes at around 170 or so years in. Playing in Windows 10 64 bit.
It runs through 243 rejections before starting and actual worldgen is kind of slow because I just love my hist-fig filled worlds. Sorry about that.

Ran this through in legacy and it ended successfully at year 177 (megabeast percentage?)  In the SDL version, it crashed at year 156.  My SDL version debugger appears to...  not be working.  MSVC is throwing some error about the exe not loading.

Trying to stick the pdb file in the folder with the exe as a workaround...  and poof, crashes when religion tries to store a holy relic but apparently doesn't have a temple.  Huh, interesting.  I can crash-proof that and then figure out what the situation is (modding related or otherwise.)

I've got a reproducible Nemesis Unit Id Load crash save appended to #0009985. The crash originally happened in 0.44.05, but also happens when the save is loaded into 0.44.08 and 0.44.09.

My guess is that it's just loading an already-corrupt unit file at that time, so it probably won't be diagnosable, as is the norm with that error.  I can take a look at it though to see if we're lucky this time.

   (*) Changed w.g. population calculation for conflicts

Does this make it harder or more deadly to send raids against high pop sites? What is the gameplay effect of this bugfix?

This was just an AI calculation about whether they should attack in world gen (as part of trying to figure out why AI dwarves never attack.)  It doesn't change the results of battles at all.

[Shonai_Dweller]

Trying to stick the pdb file in the folder with the exe as a workaround...  and poof, crashes when religion tries to store a holy relic but apparently doesn't have a temple.  Huh, interesting.  I can crash-proof that and then figure out what the situation is (modding related or otherwise.)

Oh, very interesting. Might be caused by the minotaur entity having a combination of no religion with [variable_positions:all]?

[Toady One]

It was a real ENTITY_RELIGION trying to do the storing, so unless the minotaurs make religions in your experience, it could just be something not modding related.  If a temple being destroyed is adequate, I'd expect to see it more often, but maybe it's just some flavor of that.  Since I know the year it happens, hopefully I can catch it in action and get some more information.

[PatrikLundell]

:

I've got a reproducible Nemesis Unit Id Load crash save appended to #0009985. The crash originally happened in 0.44.05, but also happens when the save is loaded into 0.44.08 and 0.44.09.

My guess is that it's just loading an already-corrupt unit file at that time, so it probably won't be diagnosable, as is the norm with that error.  I can take a look at it though to see if we're lucky this time.
:

Thanks Toady. Even if it doesn't save my fortress, it's useful to know it's typically a matter of pre-corrupted data whose symptoms appear at that time.

[Toady One]

Hmm, well, since the message has been basically useless for debugging for a decade, and the historical figure stores most of the important bits (skills, artifacts, relationships, etc), I'm going to try a new approach and have the game recreate the unit, and use your save as a test case.  This might fail spectacularly, so no promises!  Affected units would lose their non-artifact items, and perhaps certain crucial information about pets, and many of their wounds and all of their thoughts and possibly rooms and property and so forth (to the extent that wasn't broken already), but presumably that's better than destroying the entire world.  However, it might also break the game in unexpected ways; I'll maintain an error log with the exact unit file that failed and see if that helps.

Noting again that this enterprise might be doomed and I just end up reverting at the end of today, but if it works, as long as the error log is there, hopefully this won't create a bunch of tricky-to-diagnose false positive bug reports.

Not that I'll be able to help your world for much longer...  5 GB of mem used almost blew out my computer, he he he.

edit: looks like it was a goblin bard from unit-165.dat...  which wasn't there.  So it doesn't seem to be a corrupt file, but rather a missing file (or the hf had a file assigned incorrectly.)  I can use that as a data point, anyway.  In any case, the next version creates a new body/items for the bard and they show up properly...  can't say there won't be some sort of catastrophic collapse, but the save should be usable in the next version.

[PatrikLundell]

Thanks again, Toady!

The save of this fortress has bloated over time. It used to be possible to upload saves from it to DFFD, but the file size limit doesn't allow that anymore. Given that the fortress isn't huge, I assume it's the world that generates large amounts of data (there are lots of units out there). The next world will definitely need to have fewer units and sites in it...

Getting rid of crash bug reports that can't be analyzed can't be anything but a good thing.

If there is a catastrophic collapse I'll let you know, so the changes can be reverted...