I had hoped that the rest of the weird errors cropping up in the log at later init stages were just a result of the first thing, but they persist when compiling and running on 1431. The specific thing we're seeing is runtimes of this sort:
[12:55:49] Runtime in food_mixtures.dm,6: Cannot execute .Copy(). proc name: New (/datum/crafting_recipe/food/New) src: Filet migrawr (/datum/crafting_recipe/food/bearsteak) call stack: Filet migrawr (/datum/crafting_recipe/food/bearsteak): New() init subtypes(/datum/crafting_recipe (/datum/crafting_recipe), /list (/list)) make datum references lists() world: New() [12:55:51] Runtime in __techweb_helpers.dm,142: Cannot execute .Cut(). proc name: calculate techweb nodes (/proc/calculate_techweb_nodes) src: null call stack: calculate techweb nodes() initialize all techweb nodes(0) Research (/datum/controller/subsystem/research): Initialize(717519) Master (/datum/controller/master): Initialize(10, 0)
which implies to me that these list variables are in some uninitialized state wherein they are not null (or the error would say "null.Cut()") but not lists either.
It should be reproducable on the same codebase you already have. The first error will look goofy in the log because our error handler tries to check the config which hasn't been initialized yet; the rest are formatted normally.
These two particular examples both involve "new"ing everything that "typesof" returns under a particular datum, relatively early on in world startup, that may have something to do with it?
The relevant code for the first error:
/datum/crafting_recipe ... var/parts[] = list() //type paths of items that will be placed in the result ... //a later file /datum/crafting_recipe/food var/real_parts /datum/crafting_recipe/food/New() real_parts = parts.Copy()