Terra Truncator cuts too much/too little
MissPotato opened this issue ยท 2 comments
Forge Version: 1558
Botania Version: 245
Baubles Version: 1.0.1.10
The Terra Truncator when cutting down large amounts of trees usually cuts down about a 32 block range, if all the trees are touching. However, occasionally, it'll cut down much more than that. Cutting down every tree within the server-side "render" distance. This usually continues to happen until the axe breaks, but if you drop the Terra Truncator, it keeps going. (I was hoping the cutting would stop.) This is also how I found out that the silktouch does in fact work quite well with the Terra Truncator.
While in other situations, it'll only break down 3/4s of a tree, stopping as it gets to the leaf level. This tends to happen at around 1/10 of a basic mana ring.
It also has a tendency to leave trees mostly cut, leaving behind 2 or 3 blocks behind on the ground level. I would blame it on tick-dropping, if it wasn't always the last two ground blocks.
Latest Log is too long to pastebin, I attached - but if you want me to clip it and pastebin, I can.
fml-client-latest.txt
This bug is really curious, but the fundamental reason why this is occurring is because the code is using an imperfect Breadth First Search to find wood to remove. Most of this probably isn't even related to the amount of mana you have, and is more due to the imperfect algorithm. Here's the important part:
if(steps == 0)
return;
for(int i = 0; i < 3; i++)
for(int j = 0; j < 3; j++)
for(int k = 0; k < 3; k++) {
int x = coords.posX + i - 1;
int y = coords.posY + j - 1;
int z = coords.posZ + k - 1;
String pstr = posStr(x, y, z);
if(posChecked.contains(pstr))
continue;
Block block = world.getBlock(x, y, z);
boolean log = block.isWood(world, x, y, z);
boolean leaf = block.isLeaves(world, x, y, z);
if(log || leaf) {
int steps = this.steps - 1;
steps = leaf ? leaves ? steps : 3 : steps;
addBlockSwapper(world, player, stack, origCoords, new ChunkCoordinates(x, y, z), steps, leaf, false, posChecked);
posChecked.add(pstr);
}
}
This appears to be a pretty straightforward breadth first search, where all of the available unvisited positions are found and new block swappers are created. The crux of the problem is that if a leaf is encountered, the number of steps is immediately reduced to 3, presumably to prevent other trees being destroyed because they have adjoined leaves. The problem with this is that when the next tick comes around, and the new block swappers do their thing, some of them only have 3 steps instead of 24 or whatever. So if one of the 3 step swappers ticks first, and spreads new swappers around it, then all of those new swappers now only have 2 steps - and none of the nearby 24 step swappers can change that, as a swapper is only created once for a given block position.
The straightforward way to fix this is to change the code into a true Breadth First search, where new block swappers have steps equal to the greatest of the previous set of swappers (minus one).
Pull request forthcoming.