Refactor tree generation #335
Conversation
|
Could you take a look at #327 ? Does it interfere with your refactorings? Should I change anything? |
|
@wielandb looks fine! You didn't edit the tree.rs file. The only thing that will need to change is a slight modification to the |
src/element_processing/tree.rs
Outdated
| 2 => { | ||
| // Spruce tree | ||
| editor.fill_blocks(SPRUCE_LOG, x, y, z, x, y + 9, z, None, None); | ||
| editor.fill_blocks(BIRCH_LEAVES, x - 1, y + 3, z, x - 1, y + 10, z, None, None); | ||
| editor.fill_blocks(BIRCH_LEAVES, x + 1, y + 3, z, x + 1, y + 10, z, None, None); | ||
| editor.fill_blocks(BIRCH_LEAVES, x, y + 3, z - 1, x, y + 10, z - 1, None, None); | ||
| editor.fill_blocks(BIRCH_LEAVES, x, y + 3, z + 1, x, y + 10, z + 1, None, None); | ||
| let birch_leaves_fill = [ | ||
| ((-1, 3, 0), (-1, 10, 0)), | ||
| ((0, 3, -1), (0, 10, -1)), | ||
| ((1, 3, 0), (1, 10, 0)), | ||
| ((0, 3, -1), (0, 10, -1)), | ||
| ((0, 3, 1), (0, 10, 1)), | ||
| ]; | ||
| for ((i1, j1, k1), (i2, j2, k2)) in birch_leaves_fill { | ||
| editor.fill_blocks(BIRCH_LEAVES, x + i1, y + j1, z + k1, x + i2, y + j2, z + k2, None, None); | ||
| } |
There was a problem hiding this comment.
Why does the spruce tree get Birch leaves? Shouldn't it get spruce leaves? Is this intentional?
|
@wielandb Actuallllyyyyyy I might change it more XD But it still shouldn't be a problem because you only call |
|
It gives compilation error because of bad formatting, you should execute |
|
@wielandb the API has changed. See |
benjamin051000
force-pushed
the
refactor-tree
branch
from
8c81ef8 to
31da8cd
Compare
round takes a parameter which is a reference to an array of patterns. The patterns are defined at the top of the file as `[(i32, i32, i32)]`.
benjamin051000
force-pushed
the
refactor-tree
branch
from
31da8cd to
2035402
Compare
This commit is a little messy: - It reduces repitition of the block fill calls and the snow layer calls - It also replaces previous usage of `y + i` with `y + j` to keep the variable conventions the same.
x, y, z -> (x, y, z) Also some small variable renames
This decouples the data that each tree has with the block-placing procedure. Now, all the data about a tree is stored in `struct Tree`, and the `Tree::create()` function handles all paths accordingly.
benjamin051000
force-pushed
the
refactor-tree
branch
from
2035402 to
3ba9c58
Compare
Ah, okay! I will mark my PR as a draft until this is (hopefully) merged. |
I'm learning the code base by refactoring small files at a time. Tree generation was not so intimidating, so I started here. 😄
I intend on reducing repetition in this file, making it easier to comprehend and lessening the chance of making a mistake.
What do you think so far? I want to go even further by reducing each of the match arms, since they all kinda do the same thing. I'll get to it tomorrow.
I would probably recommend reviewing this commit-by-commit, since the overall diff will be large.