> Sorry for taking almost a complete week when I said "couple days" (I had 2 or max. 3 days in mind) though here's what I now think happens:

1. When Baritone is compiled, SpecialSource incorrectly but consistently remaps BetterBlockPos.x/y/z to whatever BlockPos.x/y/z is called in the target mappings (notch and srg in the cases I tested). For Baritone alone this is not a problem, other mods using it might break (e.g. my mod can't use BetterBlockPos.x because it's actually called BetterBlockPos.field_177962_a in my dev env).
2. At runtime FMLRemappingAdapter/FMLDeobfuscatingRemapper inconsistently remap BetterBlockPos.whateveritisnow either to the name of BlockPos.x in the current environment (srg and mcp in my tests) or not at all, depending on whether BetterBlockPos is loaded or not. This can break anything in seemingly random patterns.

For the first I have no idea what is causing it (because I have exactly zero knowledge how SpecialSource works) and also no longer think this is the same as a SpecialSource issue I mentioned earlier, because here the declaration itself is mistakenly remapped as well.

For the second point I'm quite sure this is a regression of MinecraftForge/MinecraftForge#3043, since the fix for that one relies on gathering field data when the declaring class is loaded and we get an IllegalAccessError (along with mismatched post-transformer bytecode) whenever the offending class is loaded before BetterBlockPos according to the remapper debug output. Putting a little baritone.api.utils.BetterBlockPos.class early in your mod initialization should "fix" this. Just make sure to not load it too early (i.e. before Minecraft itself is loaded) or you might end up in classloader and transformer hell.

make up asap was always my provoking alerts on ownself

Originally posted by @Shaquum in #3859 (comment)