View Issue Details

IDProjectCategoryView StatusLast Update
0004927Dwarf FortressWorld Generation -- Generalpublic2014-07-25 14:39
Reporteruser1294Assigned ToToady One  
PrioritylowSeveritycrashReproducibilitysometimes
Status resolvedResolutionfixed 
Product Version0.31.25 
Fixed in Version0.40.01 
Summary0004927: Many added plants crash world gen
DescriptionWhen you have many added plants (such as through Sphalerite's random plant script here http://dffd.wimbli.com/file.php?id=3752 ), world gen crashes often, depending on world size: Pocket worlds pretty much never crash, Smaller and Small worlds almost certainly crash around 100-200 years regardless of seed, and larger worlds than that can crash when left running long enough, but later.
Steps To ReproducePlace the raw file at http://dffd.wimbli.com/file.php?id=5068 in your raw/objects folder, and generate worlds of various sizes to 1050 years.
Additional InformationThe circumstances of the crash lead me to believe that the crash may be related to the abstraction of plants mentioned at http://www.bay12games.com/dwarves/dev_2010.html#2010-11-21 and the redistribution of plants mentioned in the following devlog.
 - Presumably, the game tries to place each plant. If it can't spread the plants out, by necessity, they will be close together.
 - In Pocket worlds, you may easily not get most plant-bearing biomes. In larger worlds, you usually do.
 - In Smaller worlds, the distances to each biome (which then carry most applicable plants) are quite small. In larger worlds, the distances are larger, and plant diversity of each region is higher. Thus, the crash happens later, if at all - usually past the time most people generate.

Renaming the file so that it isn't parsed by DF prevents the crash - worlds then generate up to 1050 years without problem.
TagsNo tags attached.

Activities

user1294

2011-10-15 15:06

  ~0018845

An addendum - it seems that, for the crash to reliably occur, you have to increase the number of civilizations above 5. That can then also crash pocket worlds. As such, it may be that having two of the same civilization is involved in the crash - perhaps through trading, when one side attempts to sell abstracted plants to another side that hasn't abstracted those plants. Why it would only trigger between the same civs, I am not certain. Maybe it relies on the site type in some fashion.

ellindsey

2011-10-15 18:55

reporter   ~0018846

I have noticed this myself. It happens more frequently if you increase world size or world history length.

I believe this is happening due to DF being unable to address memory over 4Gb due to being 32bit, and the extra plants somehow increasing the memory size until the game crashes during world gen. Might be the plant abstraction thing too, however. I'm not sure how to test this.

user1294

2011-10-16 03:39

  ~0018848

Memory usage doesn't get close to the critical mark with the crash, so that isn't it.

Further testing shows that it seems to be related to something that humans do, presumably farming. Restricting worlds to one human civ prevents the crash. Simply giving other civs towns for sites causes no crash. Dwarves with towns usually died off too quickly to develop actual towns, usually being restricted to hamlets. This is contrary to their apparent behavior with mountain homes, where they usually survive and even thrive (even though starvation still occurs) with the added plants.

user1294

2014-07-25 14:39

  ~0027544

DF 0.40.01 introduced more plants than the sample file I provided in this report, and world gen doesn't seem to crash from this. As such, I assume that this problem has been resolved in 0.40.01. If you have evidence to the contrary, please contact one of us managers on the forums to reopen this report.

Issue History

Date Modified Username Field Change
2011-10-15 10:59 user1294 New Issue
2011-10-15 15:06 user1294 Note Added: 0018845
2011-10-15 18:55 ellindsey Note Added: 0018846
2011-10-16 03:39 user1294 Note Added: 0018848
2014-07-25 14:39 user1294 Note Added: 0027544
2014-07-25 14:39 user1294 Status new => resolved
2014-07-25 14:39 user1294 Fixed in Version => 0.40.01
2014-07-25 14:39 user1294 Resolution open => fixed
2014-07-25 14:39 user1294 Assigned To => Toady One