local variables eg. in evergreens.lua

I just saw that you added "worldsettingsutil.lua" which does handle various timers. For example you already made a "WorldSettings_Pickable_RegenTime", although right now only the lightflier_flower is using it.
But I assume that you will expand this to all pickables and then add worldsettings to change the regrow speed from pickables.
-
And therefore I assume that you will expand this even further also to growable component , so also to evergreens.
So if you plan is to do this anyway in the future, then it is no hurry for me, do it when you implement this worldsettings timer for growable.

In case this is not planned, please kindly let me know, then I will make a mod which adds worldsettings for those.

Edited July 20, 2022 by Serpens

Both applyoverrides_pre functions and modmain run before TheWorld even exists, and before prefabs/evergreens.lua is loaded. This means any TUNING values changed when either of these are run will take effect.

The only issues would be when a mod wants to dynamically change these values while the world is running for future trees that spawn. But I mean I guess it's worth moving the `builds` and `growth_stages` creation to the prefab constructors

12 hours ago, Friendly Grass said:

Both applyoverrides_pre functions and modmain run before TheWorld even exists, and before prefabs/evergreens.lua is loaded. This means any TUNING values changed when either of these are run will take effect.

Testing is always difficult and error prone, but I'm quite sure that it does NOT have an effect (based on testing results).
The evergreens.lua script is also executed long before the world exists, and therefore the old TUNING values are saved within the local variables. Then Pre is running and changing the TUNING values, but it has no effect on the local variables.
-
I copy pasted the evergreens.lua into my mod and added a print directly above the local variable "builds" and it proved that the evergreens.lua script is executed BEFORE applyoverrides_pre functions.
-
So in the end, moving these locals in this and at best also all other prefabs to the constructor must be done at some point. And if the devs plan to add worldsettings for the GROW_TIME too, this will be done anyways.

Furthermore, I am seeing that ALL of the tuning variables stored in `builds` are actually tables. Meaning mods modifying these tables in TUNING would also be applied here.

28 minutes ago, Friendly Grass said:

Furthermore, I am seeing that ALL of the tuning variables stored in `builds` are actually tables. Meaning mods modifying these tables in TUNING would also be applied here.

Referential objects moment 

4 hours ago, Friendly Grass said:

Furthermore, I am seeing that ALL of the tuning variables stored in `builds` are actually tables. Meaning mods modifying these tables in TUNING would also be applied here.

that one is true, yes, thanks for the idea.
I build my code like the one in worldsettings_overrides.lua, which is replacing the old TUNING entries/tables, so with the same style the devs are using (with OverrideTuningVariables function) this does not work. But if I write the code a bit differently to not replace the whole table, it should work in this specific case.