Hex Casting

Hex Casting

Mods
7M Downloads

`CastingEnvironment#assertPosInRange` should check the center of the block instead of the corner

Closed this issue ยท 0 comments

commented

This is the current implementation of assertPosInRange and assertPosInRangeForEditing:

HexMod/Common/src/main/java/at/petrak/hexcasting/api/casting/eval/CastingEnvironment.java

Lines 332 to 340 in 871f938

public final void assertPosInRange(BlockPos vec) throws MishapBadLocation {
this.assertVecInRange(new Vec3(vec.getX(), vec.getY(), vec.getZ()));
}
public final void assertPosInRangeForEditing(BlockPos vec) throws MishapBadLocation {
this.assertVecInRange(new Vec3(vec.getX(), vec.getY(), vec.getZ()));
if (!this.canEditBlockAt(vec))
throw new MishapBadLocation(Vec3.atCenterOf(vec), "forbidden");
}

vec.getX(), vec.getY(), vec.getZ() returns the lower-north-west corner of the block. This is arguably very confusing behaviour. Raycasts return the center of the block, so the most intuitive way to check if a pattern will have ambit (subtracting from your position) may fail in some edge cases.

Additionally, this has a nasty interaction with canEditBlockAt, because that method checks the center of the block:

HexMod/Common/src/main/java/at/petrak/hexcasting/api/casting/eval/CastingEnvironment.java

Lines 342 to 344 in 871f938

public final boolean canEditBlockAt(BlockPos vec) {
return this.isVecInRange(Vec3.atCenterOf(vec)) && this.hasEditPermissionsAt(vec);
}

This means that when using assertPosInRangeForEditing for certain positions on the very edge of your ambit, the assertVecInRange check succeeds but the canEditBlockAt check fails, resulting in the "forbidden to you" mishap being incorrectly thrown instead of the "out of range" mishap.

To fix this, we should just make assertPosInRange and assertPosInRangeForEditing check if Vec3.atCenterOf(vec) is in range, like canEditBlockAt already does.