NB: forest ---> world

[Maris]

AddPrefabPostInit("forest",function(inst)    --now this is unreachable codeend)AddPrefabPostInit("world",function(inst)    --move here all your stuff from old forest initializationend)

​

 

Most of my mods are broken or distorted. Very bad to do so, Klei.  

 

Okay, I will replace my init code in all my mods with this:

local is_forestlocal function ForestInit(inst)	if is_forest then		return	end	is_forest=true	-----> Initialization code here.	-----> This code will be compatible with all branches (including caves beta).endAddPrefabPostInit("forest",ForestInit)AddPrefabPostInit("world",ForestInit)

​Guess it will work fine in any case.

Edited October 5, 2015 by Maris

[DarkXero]

The risk of bleeding edge technology.

[Ipsquiggle]

Hey, sorry. We were cleaning this up and left that out. We will make it so that "forest" still works as you expect for the next update.

 

_However..._

 

I do strongly recommend that in the future you use "world", and check for tags instead if you need behaviour specific to a particular kind of world (we've added a "forest" and "cave" tag to the prefabs).

 

This way your mod will load correctly regardless of the particular prefab name which was used to spawn the world.

[Maris]

No problems. It's good idea to add tags to the world prefab.

Btw I think it's not a big deal. It's easy to add support directly in AddPrefabPostInit:

	env.AddPrefabPostInit = function(prefab, fn)		if PREFAB_SYNONYMS[prefab] then			prefab = PREFAB_SYNONYMS[prefab] -- <<<<<<<<<<< Here 		end		initprint("AddPrefabPostInit", prefab)		if env.postinitfns.PrefabPostInit[prefab] == nil then			env.postinitfns.PrefabPostInit[prefab] = {}		end		table.insert(env.postinitfns.PrefabPostInit[prefab], fn)	end

​Up to you anyway.