Recurrent Complex

Recurrent Complex

35M Downloads

Leaves decaying immediately

whichonespink44 opened this issue ยท 18 comments

commented

Leaves generated by some of RC's trees are decaying immediately.

At first, I thought this was just an issue in RTG worlds using the new 4.1.1.5 pre-release, but I tested some default worlds using just RC 1.2.2 & RC 1.2.3 (and FastLeafDecay), and it's happening in default worlds as well.

This happens even if the global toggle treeLeavesDecay is set to false.

From what I can see, it seems to be related to some of the trees not having supporting log blocks, but that might not be the case for every tree.

commented

Yes, try reporting it to Fast Leaf Decay's author. treeLeavesDecay generates the leaf block with the decayable property set to false, which Fast Leaf Decay should honor.
Also make sure that the leaves are actually spawning with the property set to false (by removing the fast leaf decay mod and generating some trees). Some people have reported the treeLeavesDecay option is ignored, though I cannot reproduce it currently.

commented

Recurrent Complex may generate trees with leaves far enough away from the nearest log block that Fast Leaf Decay seems them as "floating." It could also be because RC generates trees with leaf blocks that are diagonal to other leaf blocks but not directly touching.

I don't have time to test this, but it's possible that Fast Leaf Decay does it's task differently than vanilla code. If it manually checks when leaves are floating rather than simply increasing the speed of random ticks on leaves (which is how vanilla Minecraft does it) it may not count leaf blocks that are diagonal to other leaf blocks, and may require blocks to be closer to a log than vanilla does.

If I'm correct, this is an issue with Fast Leaf Decay and not with Recurrent Complex.

commented

Since 1.2.3.4 there's /#eval (which I may or may not have added for exactly this issue).
Try /#eval global:treeLeavesDecay ingame and see if it outputs False.
If False, do /#edit GenericTree, click Transformers, edit '1 Transformer' and see if at the bottom it states global:treeLeavesDecay as the Condition. Theoretically, one of these things should not be the case.

commented

Just been doing more testing using only Forge 2099, RecurrentComplex 1.2.3, and IvToolkit 1.2.8.5 (no other mods), and I can confirm that leaves are still decaying immediately, regardless of whether treeLeavesDecay is true or false.

Looking at the trees that were decaying immediately, it's definitely happening due to there not being enough supporting log blocks:

rc

The first screenshot was taken just after the world first loaded, and the second screenshot was taken about 10 minutes later.

I don't know how many trees are missing supporting log blocks, but I'd say it's pretty significant. When I was testing with WorldEdit before this last batch of tests, I ran the /remove items 1000 command, and it removed hundreds of items (saplings).

Since it's probably a massive job to re-design the trees to have supporting log blocks, it might be best to figure out why the treeLeavesDecay global toggle isn't working.

If there's anything I can do to help, just let me know. I know a lot of RTG's users also love running RC, and currently this is what's happening for them in RTG worlds:

rtg_rc

commented

That sounds correct, then. Systems are in place and working. I''m pretty sure the config should do its thing then.
Do the tree leaves spawn with decayable set to false? Because if that's the case, they should not despawn.

commented

Yes, they're despawning with treeLeavesDecay=false

commented

When treeLeavesDecay=true in the configs, /#eval global:treeLeavesDecay outputs 'true' and the first transformer 1 condition is 'gen.type=sapling'

When treeLeavesDecay=false in the configs, /#eval global:treeLeavesDecay outputs 'false' and the first transformer 1 condition is 'gen.type=sapling'

commented

Correction, there are two '1 Transformer' sections in the GUI...

When treeLeavesDecay=true in the configs, /#eval global:treeLeavesDecay outputs 'true' and the second transformer 1 condition is 'global:treeLeavesDecay'

When treeLeavesDecay=false in the configs, /#eval global:treeLeavesDecay outputs 'false' and the second transformer 1 condition is 'global:treeLeavesDecay'

commented

Oh, i got the problem.
Every tree version other than GenericTree (eg. GenericTreeHuge, GenericTree1) does not check for global:treeLeavesDecay.

commented

I'm not sure what the issue is, because it always worked for me - the other trees also check for global:treeLeavesDecay no problem.
Try the latest nightly build though. I have moved some stuff around and added some more logging that might be helpful.

commented

No they do not check for it.
Just type /#edit GenericTree1 and look at the last transformer.
Either i am completely stupid or at least the version on GitHub does not check for global:treeLeavesDecay.
You can also just open the json in eg. GenericTree1.rcst .
You won't find even a mention of treeLeavesDecay. Because they do not check for it.
If you open GenericTree.rcst you will find a mention of treeLeavesDecay in the json. Because it checks for it.
I added this check to all tree files and added an template for DeadTree. If you want to use it you can download it here.
Caution: I used the templates without pressing [Customize: * ] afterwards. This is different than it was before. I can change this if you want me to.

commented

The trees use the tree transformer preset (as marked under "dataPreset"). The data (in "data") is there only as backup to approximate what the preset might have been in case it's missing. During the game it will load and use the most current version of the preset instead, so the file might not always be accurate.
That is, of course, if you do not customise the preset. From then on the data from the file will be used instead.

Like I said, I checked the trees and on my end it looks perfectly fine for all trees. Is it different for you on the latest nightly? Does the log say anything about being unable to load from preset? (Log output I've added in the most recent nightly builds for this purpose).

commented

then there is some problem in the code for using the preset.
Because it works with my files but does not work with yours.
I replaced them in the mod .jar file and everything worked as expected.
just for confirmation:
i replaced the tree transformator preset with one that replaces every block with wool blocks and it did not replace all the trees with woll blocks in a new world. :)

commented

Can you do /#write transformer_preset tree ACTIVE and send me the file that's written into structures/active?
Also, the logs. If there is something wrong with the code it should log the issue somewhere.

commented

"/#write transformer_preset tree ACTIVE" always gives me the file that is currently in the jar under "/assets/reccomplex/structures/active/presets/transformer/tree.rcmt"
here is the log. it logs some warns at startup.

commented

Well, there we go: [22:32:02] [Client thread/WARN] [reccomplex]: Failed to find transformer preset preset: tree

I think I get the issue now. Working on a fix.

commented

If the issue is not fixed let me know, but making it lazy should do the trick. If it doesn't I'll need to revamp more of the loading system.

commented

Can confirm it is fixed.
Does work perfectly with the newest nightly.