-
Notifications
You must be signed in to change notification settings - Fork 580
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
register_leafdecay allow param2 value specification as table of values #2877
Comments
You could always add the side leaves to the {attached_node=1} group so they drop when the trunk beside them is dug. |
Sorry I didn't realise the leaf decay was a function inside MTG, Im going to go have a dig for the code. Thanks @tenplus1 I'm definitly trying that :) |
So I checked the code for leafdecay and if Im reading it correctly any leaf that is not equal to 1 will decay
I did my orginal checking using a leaf with a param of 1, so it looks like sign like will decay. I guess what I need then is an override to allow leaves with param2 ==1 to decay. Understand this is in enhancement territory and MTG is in LTS/Sleep phase. However I'll have a go at adding a new parameter to the def something simple like o_param so code would be something like
Anyways I'll see if I can get a full fix going, might be off intrest to someone else as well |
Just adding a question, can I ask why node.param2 was selected as the place to store leaf_decay. I don't mean this question to sound like a criticism I am honestly curious why param2 was selected? Is there an engine advantage ie speed etc? config advantage? I can see a config advantage as if someone sets up a new leaf_node and copies existing leaf_node they all end up with param2 =0 so will just out of the box decay. On top of this the param2 value is returned with the light get_node call - {name="ignore", param1=0, param2=0} and lastly no need to retrieve values from node meta - may have answered my own question or one for @paramat ? Mainly I'm just curious if the option to add some sort of meta flag to a user placed leaf node was explored and discarded as too cumbersome or engine intense due to all the calls to check each nodes meta before decaying? or if it was more around code simplicity ie leaves with param2=1 are very rare and I can setting and retrieving meta is a few more lines of code and checking. Understand none of this will make base game but Im still working on it for my own use :) Untested - but my thoughts example:
|
Problem
register_leafdecay(leafdecaydef) only targets and runs on leaves when param2 == 0.
It would be useful for some leaf types to be able to specify that leafdecay should run when param2 is equal to range of values this would then allow leaf decay to run on special case or unique leaves.
For example this would allow leafdecay to run on flat leaves placed vertical around a trunk - signlike, which have a param2 of 2 through 5. A recent case I ran over designing a Joshua Tree, however I have a similar problem with some directional leaves were param2 == 1. See attached image of Joshua tree red boxed area
Solutions
propose making the param2 an optional table setting so if not specified defaults to 0 but if specified checks leaf values against table supplied.
Additional context
Understand this may cause issues for current workaround of user placed leaves not decaying but as this is a game designer settable field and optional for certain leave types I can't see it causing major issues.
I'm hoping this maybe a minor change as the code already checks for param2 value == 0.
The text was updated successfully, but these errors were encountered: