MC 1.12.2 Forge Crash - BlockPos IllegalAccessError

[TheWoolsinator]

Some information

Operating system: Windows 10
Java version: 1.8.0_271
Minecraft version: 1.12.2
Baritone version: v1.2.* (tried many releases, api and standalone)
Other mods (if used): Tons. Using in a modpack. (I understand that this is unsupported).

I removed the RandomPatches mod which was causing a forge mixin crash and was able to load the instance successfully. I have a feeling something else is modifying/changing the interface to internal classes and causing the BlockPos->BetterBlockPos issues. Validated that -noverify is not being passed to java (as best as i can tell).

Also, Baritone does not show up in the mod list unless I manually add a mcmod.info file to it. Not sure whats up with that.. am I simply not loading the mod correctly or using an incompatible baritone version?

Crash occurs on server connection.

Any guidance would be much appreciated.

Exception, error or logs

See attached crash report.
crash-2023-01-29_19.17.21-client.txt

How to reproduce

1. Install Technic 1.12.2 Modpack via MultiMC
2. Remove 'RandomPatches' mod from the mods folder
3. Copy 1.12 compatible baritone forge artifact into mods folder
4. launch (wait forever for everything to init lol)
5. connect to a server
6. observe crash report

Modified settings

To get the modified settings run #modified in game

Final checklist

• I know how to properly use check boxes
• I have included the version of Minecraft I'm running, baritone's version and forge mods (if used).
• I have included logs, exceptions and / or steps to reproduce the issue.
• I have not used any OwO's or UwU's in this issue.

[ZacSharp]

I can confirm this bug happens, however so far I only had it happen in really nonstandard setups (srg mapped unoptimized 1.12.2 build of Baritone in the dev env of another mod) so I didn't care too much.

If I remember correctly it's some remapper choking on the shadowing relation between fields in BlockPos and BetterBlockPos so there's bytecode trying to access a private field of BlockPos instead of the public equivalent in BetterBlockPos even though the object is a BetterBlockPos and the original code was targeting the public field.

[TheWoolsinator]

@ZacSharp that makes a lot of sense and would definitely explain the behavior I've noted. Thank you for sharing the information it gives me a better idea of where to look.

It's been a while since I've debugged a metaprogramming issue and I haven't been in Java land for nearly 7 years so this will be interesting to say the least.

If I find any fix(es) I will include the information here or in a PR if appropriate. Though I doubt that any fix would apply to baritone itself, and imagine it would require a monkeypatch on whatever code is remapping things.

[TheWoolsinator]

Isolated the mod package responsible for introducing this behavior:
https://github.com/LoliKingdom/LoliASM

Conveniently there was a configuration boolean within 'loliasm.cfg' under the config folder which immediately fixed the issue, no code deep dive or patch necessary.

Set to false in the cfg file:
remapper { # Optimizing Forge's Remapper for not storing redundant entries - <default: true> B:optimizeFMLRemapper=true }

I still never resolved the forge loader mixin crash introduced by the RandomPatches package within this modpack but that is out of scope for this issue as named.

Thanks again @ZacSharp, hope this helps someone else in future!

[TheWoolsinator]

Resolved the mixin crash from RandomPatches.

Set the following to false in the 'randompatches.cfg' file within the config folder:
# Set this to false to disable the Minecraft class patches (the Toggle Narrator keybind and custom window title/icon). # Default: true B:patchMinecraftClass=true

[ZacSharp]

I did some searching (because #3855 (comment) got me worried about this again) and it seems like that LoliASM's optimization effectively disables the fix for MinecraftForge/MinecraftForge#3043. Not sure whether it is intentionally blocking the required mappings as "redundant" (they always map a name to itself) or whether that's an accident.

The problem I experienced myself on the other hand is probably md-5/SpecialSource#72 and actually not the same.
EDIT: nope, that issue seems to be yet another problem

[wagyourtail]

ahh. so would actually using srg mappings for forge builds in 1.12 fix it?

[ZacSharp]

First off to be clear: the problem this issue is about was fixed a long time ago and only reappeared due to an overly aggressive optimization mod.
EDIT: There's also a corner case with class loading order.

The other problem I'm talking about will not be fixed by using srg mappings. So far I only had it happen with srg mappings, though #3859 and #2865 suggest it can happen with notch mappings as well. (EDIT: Confirmed with standard notch mapped Baritone and a standard Forge install).
If we want to discuss this in more detail we should do so either in one of those issues or in a new one.