baritone icon indicating copy to clipboard operation
baritone copied to clipboard

Make every Vec3i use BetterBlockPos hash

Open babbaj opened this issue 1 year ago • 10 comments

BetterBlockPos returning a different hashCode than the superclasses is a massively stupid correctness problem and is currently causing my game to crash. In theory this might also improve performance a bit if it allows the jvm to devirtualize calls to hashCode.

babbaj avatar Sep 16 '24 06:09 babbaj

This is a crazy big change, it could have tons of unintended side effects 😭

leijurv avatar Sep 17 '24 03:09 leijurv

Better stop passing BetterBlockPos as if it were a BlockPos, ideally removing the subclassing (but that causes hundreds of compile errors).

Alternatively if no BetterBlockPos is ever equal to any non-BetterBlockPos (as is normal for most classes) this won't be a problem at all. Just very annoying and error prone to work with. (And it would require a mixin into BlockPos.equals)

ZacSharp avatar Sep 18 '24 22:09 ZacSharp

I think the only other solution is to just not override the hashcode at all and figure out a different way to use the better hash function when using hashmaps but I don't think this could cause any problems anyways

babbaj avatar Sep 19 '24 02:09 babbaj

That different way of using the better hash would be a class equivalent to BetterBlockPos but without extending from BlockPos. That could be either BetterBlockPos itself (lots of breakage) or a reimplementation (unknown effort, probably easier). In either case we'd probably want to migrate Baritone to use either our own position class or BlockPos exclusively (I vote for using our own) and convert explicitly were needed.

ZacSharp avatar Sep 21 '24 23:09 ZacSharp

The different way could just be fastutil's OpenCustomHashMaps or a simple class that just extends BetterBlockPos and is explicitly only to be used as keys to a hashmap. Creating a completely separate class would be unnecessarily annoying and would inevitably create a ton of unnecessary conversions that would make performance worse.

babbaj avatar Sep 21 '24 23:09 babbaj

Please not a class only meant to be used for hash maps. That's doomed to end where we are already.

ZacSharp avatar Sep 21 '24 23:09 ZacSharp

I don't think overriding the hashCode should cause any issues in practice, nothing should actually rely on the hashCode being the same between game launches...

anyway, the other way would be to extend HashMap/HashSet to overwrite what it querys for hashCode like babbaj said

wagyourtail avatar Sep 22 '24 00:09 wagyourtail

the map already grabs the hashcode manually: https://github.com/cabaletta/baritone/blob/1.19.4/src/main/java/baritone/pathing/calc/AbstractNodeCostSearch.java#L169

leijurv avatar Sep 30 '24 06:09 leijurv

Is there any other reason to overwrite the hash code? (Other than general Minecraft performance, which I'd leave to optimization mods and mojang)

ZacSharp avatar Oct 03 '24 21:10 ZacSharp

This issue has been known for long enough, so can we either gets this in or completely remove the override? If there are mixin/other conflicts we can still remove the mixin (can mixin priority handle the former per run?).

ZacSharp avatar Mar 23 '25 16:03 ZacSharp