Jump to content

local variables eg. in evergreens.lua


Serpens
  • Pending

Not urgent, but nice to have:
Analog to this solved request:

I would like to ask if you could also improve other code, to not use local variables that are saving TUNING values.
For example in the evergreens.lua (and maybe other scripts with growable stages), you define "builds" and "growth_stages" outside of any function, which makes it very hard to change anything about grow stages by changing the TUNING values.

This is not only helpful for mods, but also for your "new" system of "Worldsettings" that can be changed anytime. In applyoverrides_pre from worldsettings_overrides.lua you are changing TUNING values. So if you one day want to add a setting to multiply the grow time of evergreens, your current system with local variables won't work.

 


Steps to Reproduce

Apply the same changes you applied to eyeofterror.lua (putting the local variables into functions) to evergreens.lua, so changing eg. TUNING.EVERGREEN_GROW_TIME values does have an affect midgame.




User Feedback


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 by Serpens

Share this comment


Link to comment
Share on other sites

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

Share this comment


Link to comment
Share on other sites

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.

Share this comment


Link to comment
Share on other sites

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.

Share this comment


Link to comment
Share on other sites

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 

  • Like 1

Share this comment


Link to comment
Share on other sites

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.

Share this comment


Link to comment
Share on other sites



Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...