Discussion on explosion behavior change (2/2): Fix block bounds off by one

[EZForever]

This is the alternative PR about changing explosion behavior. See my last PR, #925, for context.

Rather than a logic refactor like in the last PR, this PR fixes a bug in current logic and partially restores correct explosion handling.

As mentioned in the last PR, there are multiple causes contributing to the block bounds being larger than intended; the bug this PR fixes is one of them.

To enumerate all the blocks inside the mapped, sublevel-local block area (essentially a rotated cube), the current logic takes the area's min and max coords, floor()s them, and treats them as coords of a grid-aligned bounding box. This alone creates other problems, but let's leave it alone for now.

sable/common/src/main/java/dev/ryanhcode/sable/mixin/explosion/ExplosionMixin.java

Lines 109 to 116 in c5e4737

	final BoundingBox3i blockBounds = new BoundingBox3i(
	Mth.floor(localBounds.minX()),
	Mth.floor(localBounds.minY()),
	Mth.floor(localBounds.minZ()),
	Mth.floor(localBounds.maxX()),
	Mth.floor(localBounds.maxY()),
	Mth.floor(localBounds.maxZ())
	);

This bounding box's min and max coords is then immediately gets extracted and iterated over.

sable/common/src/main/java/dev/ryanhcode/sable/mixin/explosion/ExplosionMixin.java

Lines 120 to 122 in c5e4737

	for (int x = blockBounds.minX(); x <= blockBounds.maxX(); x++) {
	for (int z = blockBounds.minZ(); z <= blockBounds.maxZ(); z++) {
	for (int y = blockBounds.minY(); y <= blockBounds.maxY(); y++) {

The problem is the bounding box's max coords is assumed to be exclusive by the calculation logic, but is then used in the loop as inclusive. (For example, floor()ing range -0.2~0.8 gives -1~0, which is correct in this context, but the loop will then count over both -1 and 0.) As a result, there is always one more block along each axis gets involved in the following logic, thus the effective minimal block bounds becomes 2x2x2 instead of 1x1x1.

Doing the same test as in the last PR shows that fixing this bug partially fixes explosion handling; the crater (on the right) is larger than without the fix, but still smaller than it should be (on the left).

IMO this PR comes with less risk of breaking stuff than the last one (can't say for sure though), but it does not resolve the fundamental problem the current logic has.