crash on custom goal request

[Redhawk18]

case ShulkerSearchPathing: {
    if (baritone.getCustomGoalProcess().isActive()) {
        Helper.HELPER.logDirect("custom goal to path to shulker");
        return; // Wait to get there
    }

    curCheckingShulker = getShulkerToCheck();
    Helper.HELPER.logDirect("found current shulker: " + curCheckingShulker.toString());
    if (curCheckingShulker == null) {
        ...
    }

    Optional<Rotation> shulkerReachable = RotationUtils.reachable(ctx.player(), curCheckingShulker,
            ctx.playerController().getBlockReachDistance());

    if (shulkerReachable.isPresent()) {
        ...
    } else {
        Helper.HELPER.logDirect("Going to shulker");
        // crash happens here vvv
        baritone.getCustomGoalProcess().setGoalAndPath(new GoalBlock(getPathingSpotByShulker(curCheckingShulker)));
    }
    break;
}

This leads to this error

[19:38:34] [Render thread/ERROR]: Unreported exception thrown!
java.lang.IllegalArgumentException: Multiple entries with same key: class_2338{x=-322, y=63, z=-61}=net.minecraft.class_2627@5c367bff and BetterBlockPos{x=-322,y=63,z=-61}=net.minecraft.class_2627@32300150

and crashes the rendering thread so crashing the game.

[ZacSharp]

Did you find the reason for the crash?

[Redhawk18]

Did you find the reason for the crash?

I haven't I'm going to circle back because I just found out how to turn off obfuscation for baritone

[Redhawk18]

Did you find the reason for the crash?

i just fixed it, the problem was that baritone would insert a BetterBlockPos into it the map of blockpos that minecraft uses cause them to collide. This is the code that fixed it, while it does get ride of a lot of the gains BetterBlockPos gives it's worth it to not have my game crash.

--- a/src/api/java/baritone/api/utils/BetterBlockPos.java
+++ b/src/api/java/baritone/api/utils/BetterBlockPos.java
@@ -80,7 +80,7 @@ public final class BetterBlockPos extends BlockPos {
 
     @Override
     public int hashCode() {
-        return (int) longHash(x, y, z);
+        return super.hashCode();
     }

While this works, a better solution for upstream should be implemented.

[ZacSharp]

What would such a fix look like?

• Not extending BlockPos. A very disruptive change for anyone using BetterBlockPos and making it far less convenient to use.
• Making BetterBlockPos compare not equal to any BlockPos. Confusing and annoying to work with.
• Fix the place inserting the BetterBlockPos and hope things work for another five years without breaking.

[Redhawk18]

What would such a fix look like?

* Not extending `BlockPos`. A very disruptive change for anyone using `BetterBlockPos` and making it far less convenient to use.

* Making `BetterBlockPos` compare not equal to any `BlockPos`. Confusing and annoying to work with.

* Fix the place inserting the `BetterBlockPos` and hope things work for another five years without breaking.

I have no idea, but correct is better than incorrect with any speed up.

[ZacSharp]

Can you maybe provide the place leaking the BetterBlockPos? Reproducing on your branch failed and I currently don't have the time to figure it out using just the error message.

[Redhawk18]

Can you maybe provide the place leaking the BetterBlockPos? Reproducing on your branch failed and I currently don't have the time to figure it out using just the error message.

This is what I was told by a friend who's one of the lead meteor maintainers.

this would only happen if you

• 1. call WorldChunk#addBlockEntity or WorldChunk#setBlockEntity with
• 2. a block entity where BlockEntity#getPos is a baritone BetterBlockPos

We likely have a problem with the 2nd one, it seems baritone doesn't often do this so this must have never got caught.