View Issue Details

IDProjectCategoryView StatusLast Update
0011458Dwarf FortressWorld Generation -- Generalpublic2021-02-18 21:40
ReporterShonai_Dweller Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
OSWindowsOS Version10 
Product Version0.47.04 
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.

Activities

Shonai_Dweller

2020-03-12 17:41

reporter   ~0040363

Last edited: 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

2020-03-13 04:19

reporter   ~0040365

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

2020-03-16 04:47

reporter   ~0040374

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

2020-03-16 05:03

reporter   ~0040375

Possibly, but why would it crash now and never before? What changed about food production between 44.12 and 47.01?

brudda55

2020-03-16 05:26

reporter   ~0040376

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

2020-03-16 14:27

reporter   ~0040377

Last edited: 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

2020-03-19 04:27

reporter   ~0040388

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

2020-03-19 20:02

reporter   ~0040390

Oh, do your variable values work if you remove no_eat (or fish_cleaner) from goblins?

Shonai_Dweller

2020-03-21 20:13

reporter   ~0040400

Last edited: 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

2021-02-18 21:40

reporter   ~0040929

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.

Add Note

Note

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
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
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
2020-03-21 20:29 Shonai_Dweller Note Edited: 0040400
2020-03-21 20:43 Shonai_Dweller Note Edited: 0040400
2020-03-21 21:07 Shonai_Dweller Note Edited: 0040400
2020-03-21 21:09 Shonai_Dweller Note Edited: 0040400
2021-02-18 21:40 Nekkowe Note Added: 0040929