Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011458Dwarf FortressWorld Generation -- Generalpublic2020-03-12 17:372021-02-18 21:40
Assigned To 
PlatformOSWindowsOS Version10
Product Version0.47.04 
Target VersionFixed in Version 
Summary0011458: [NO_EAT] tags on some modded races causes worldgen crashes
DescriptionVarious modders have reported that removing [NO_EAT] and [NO_DRINK] from their mods has cleared up worldgen crashes since 47.x launched.

[NO_EAT] doesn't crash in all mods, but the crash can be replicated easily enough (see steps below).
Steps To ReproduceAdd the tag [NO_EAT] to vanilla dwarves in creature_standard.txt

Try to generate a world.
Crashes occur either right at the start of history generation (when placing civs reaches 0) or sometime between 5-100 years in (generally quicker).
Additional InformationThis doesn't seem to be a simple case of [NO_EAT]+Cave_Detailed civ = crash, as some mods have been seen to work. While others report crashes on Tree_City entities.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
Shonai_Dweller (reporter)
2020-03-12 17:41
edited on: 2020-03-12 17:43

Some more points:

1) Crash does not occur in 44.12 following steps above.

2) Seems to be the cause of this modded world crash: 0011440

TomiTapio2 (reporter)
2020-03-13 04:19

Note: OldGenesis mod WG-crashes madly in 47.04, and doesn't WG-crash when removed all NO_EAT NO_DRINK tags from the civs. Usual WG-crash years were 12,31,32,120.
brudda55 (reporter)
2020-03-16 04:47

Probably has to do with the entity they are in making food, I removed the food making jobs and reactions from one of my modded NO_EAT and NO_DRINK creature civs and stopped getting crashes.
Shonai_Dweller (reporter)
2020-03-16 05:03

Possibly, but why would it crash now and never before? What changed about food production between 44.12 and 47.01?
brudda55 (reporter)
2020-03-16 05:26

I don't know, but I just managed to narrow it down to the fish cleaner job. Remove that, and the crashes wills top on a dwarf entity with NO_EAT dwarves.
Shonai_Dweller (reporter)
2020-03-16 14:27
edited on: 2020-03-16 14:34

Yep, that works for humans too. Great.
But, goblins have fish_cleaner and they've never crashes. Maybe they have no access to overground fish?

Also seems to fix 0011440

TrueWolves (reporter)
2020-03-19 04:27

I ran in to this bug when modding the raws to give all the civs VARIABLE_VALUE instead of just a set VALUE. So it may be an interaction with NO_EAT, Food-gathering jobs, and values. I didn't change any of the values to have a range greater than 30 more/less than the original value, so it may not need much of a change.
Shonai_Dweller (reporter)
2020-03-19 20:02

Oh, do your variable values work if you remove no_eat (or fish_cleaner) from goblins?
Shonai_Dweller (reporter)
2020-03-21 20:13
edited on: 2020-03-21 21:09

So, while elves, humans and dwarves given a combination of No_eat and permitted_job:fish_cleaner will crash worldgen, goblins have both of these values and yet don't crash.

The culprit is, as TrueWolves noticed, the leisure_time value. Given a positive value, goblins will crash worldgen until you remove fish_cleaner from them.

Having said that, elves have the same value for leisure_time as goblins (0) but will crash given No_Eat and Fish_cleaner, so that's not everything.

It does seem to be values related though, as giving elves an exact copy of goblin values, plus no_eat and fish_cleaner and they don't crash worldgen. Just gotta test them one at a time I guess.

Ok, another is MERRIMENT. With a positive value, goblins crash worldgen unless you remove permitted_job:fish_cleaner.

Adding no_eat to the creature and permitted_job:fish_cleaner to an entity with positive merriment (such as elves) crashes worldgen.

Nekkowe (reporter)
2021-02-18 21:40

Yup, I'm also still getting this problem in 47.05.

My modded entity with [NO_EAT] crashed in world gen almost every single time (I
m assuming that in the rare cases it didn't, they died out before a crash could occur)

Removing [PERMITTED_JOB:FISH_CLEANER] did function as a workaround.

- Issue History
Date Modified Username Field Change
2020-03-12 17:37 Shonai_Dweller New Issue
2020-03-12 17:41 Shonai_Dweller Note Added: 0040363
2020-03-12 17:43 Shonai_Dweller Note Edited: 0040363 View Revisions
2020-03-13 04:19 TomiTapio2 Note Added: 0040365
2020-03-16 04:47 brudda55 Note Added: 0040374
2020-03-16 05:03 Shonai_Dweller Note Added: 0040375
2020-03-16 05:26 brudda55 Note Added: 0040376
2020-03-16 14:27 Shonai_Dweller Note Added: 0040377
2020-03-16 14:34 Shonai_Dweller Note Edited: 0040377 View Revisions
2020-03-19 04:27 TrueWolves Note Added: 0040388
2020-03-19 20:02 Shonai_Dweller Note Added: 0040390
2020-03-21 20:13 Shonai_Dweller Note Added: 0040400
2020-03-21 20:17 Shonai_Dweller Note Edited: 0040400 View Revisions
2020-03-21 20:29 Shonai_Dweller Note Edited: 0040400 View Revisions
2020-03-21 20:43 Shonai_Dweller Note Edited: 0040400 View Revisions
2020-03-21 21:07 Shonai_Dweller Note Edited: 0040400 View Revisions
2020-03-21 21:09 Shonai_Dweller Note Edited: 0040400 View Revisions
2021-02-18 21:40 Nekkowe Note Added: 0040929
2021-02-20 16:23 Nekkowe Issue Monitored: Nekkowe

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker