Improvements to TreeGrower - #957
Open
Borito185 wants to merge 1 commit into
Open
Conversation
Borito185
force-pushed
the
fix/big-tree-growth
branch
from
July 24, 2026 14:50
3f37fe7 to
036d2e0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
Restoration of 2x2 saplings on failed big growth attempt
Previously there was a TODO to restore the saplings after a failed big growth attempt. I created a reusable function
setSaplingsto set saplings to a given material. This is used both to set them to air prior to growth and to restore the original saplings afterward on fail. This will prevent saplings from disappearing.Added tree growth reattempt
Saw an old bug report (#198) that mentioned this fix. And thought I might as well implement this. It will try to grow the tree up to 10, before giving up. This ensures trees grow more consistently. 10 is somewhat arbitrary here. But from previous experience, most trees grow in that many attempts. Feel free to let me know whether to change or even keep this.
Updated .generateTree to non-deprecated version
world.generateTree(Location, TreeType)is deprecated since 1.21.6. I have replaced it withworld.generateTree(Location, Random, TreeType). This now requires aRandomobject. I have scoped this to the Grower object to prevent allocations & ensure randomness.Slightly improved performance by preventing array allocation
The previous implementation looped over a small array of relative blocks to check for both
adjacentSaplingCheckandfindNWSapling. I have changed this to a for loop instead. Although it's a bit harder to read, it should prevent a couple of array allocations, which improves performance.Fixed bug preventing 2x2 growth when not initiated from NW sapling
The previous implementation correctly verified whether this sapling is part of a 2x2 setup using
canGrowBig, but then checks the wrong direction forfindNWSapling. Making only the NW sapling able to grow a big tree. More on this at the end.Testing Steps
The old version would delete 3 saplings. In the new version, they will remain. In addition, after removing the block and right-clicking any sapling with a stick to force an update, the tree will grow.
Usage of LLM's
I used ChatGPT 5.5 to verify code and improve documentation a bit, but not to generate code.
Important Question
Imagine a 2x2 setup of saplings like:
1 2
3 4
The old version only grew a tree iff the sapling at 1 (northwest) is fully grown. But the way it was written makes me think this was not intended, and any of 1, 2, 3, or 4 should have been able to cause the tree to grow.
What is the intended behavior? The new version assumes any of 1, 2, 3, or 4 may initiate an attempt to grow the tree.