Replies: 1 comment
-
|
Have you checked the other iterator types that they use after you do the research? edits builder mode research |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Right now the algorithm goes from row to row, scanning all blocks from one side to another, and placing blocks when needed.
Imagine the builder building a 100x100 one block wide square, the builder would go to row 1, then blocks 1, 2, 3, 4... up to block 100, walking all the way to the right side on the process. Then he proceeds to row 2, and starts again at block 1, all the way back to the left side, he goes running and places the block, but the next block is at row 2, block 100, at 100 blocks of distance, he runs to the right side and places it, but the next goddamn block is at row 3, block 1, 100 blocks of distance again, he does this 98 times bouncing from side to side of the square finally reaching the last line at row 100, and that's when he realizes the square needs to be 100 blocks high. And also we're building a base over the ocean so he was swimming all this time.
It will take bob one hundred thousand working days to finish the building because his algorithm doesn't search the nearest block available, but does a linear scan instead.
The algorithm could stay the same, goes from each y level starting from the bottom, but instead of going through each x and z linearly, it could do a nearest neighbor search with the builder x and z coordinates and every block that hasn't been scanned yet. If there are too many blocks that would make calculations too expensive, use the current algorithm instead (or something crazy stuff like a k d tree).
Beta Was this translation helpful? Give feedback.
All reactions