The latest Twilight Forest jar seems to stop #mine from working on 1.21.1

[ipaqmaster]

Some information

Operating system: Linux 6.6.56-1-lts Java version: jdk21-openjdk 21.0.5.u11-1 Minecraft version: 1.21.1 (Direwolf20 1.21 - v1.3.0) Baritone version: Local build baritone-standalone-neoforge-1.10.2-8-g50291089.jar Other mods (if used): Direwolf20 1.21 v1.3.0 so ~250 other mods.

Exception, error or logs

Please find your latest.log or debug.log in this folder and attach it to the issue

To be attached

Linux: ~/.minecraft/logs/

Windows: %appdata%/.minecraft/logs/

Mac: /Library/Application\ Support/minecraft/logs/

How to reproduce

Add your steps to reproduce the issue/bug experienced here.

1. Drop baritone into the mods folder
2. Launch and start a new world
3. #mine someBlock
4. Baritone almost immediately throws an exception in the logs

Try again after removing twilightforest-1.21.1-4.6.2790-universal.jar and it is able to #mine again with a bit of a game freeze before mining starts.

Modified settings

To get the modified settings run #modified in game

This is with a fresh installation of the pack, no modified settings.

Final checklist

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

[ipaqmaster]

latest.log

[ipaqmaster]

I can confirm that Baritone is still capable of responding with daniel when Damn is said in the chat despite this issue

[NicoBeh]

If I interpret the stack trace correctly this is an issue with the JSON metadata files of the twilight forest blocks. And somewhere along the parsing of these files an error gets raised. That in itself is fine for the indiviual block but the error won't get caught because it's not an exception. Java is not my forte so that explanation might be wrong.

Anyway, this is a quick and dirty fix which seems to work.

--- a/src/api/java/baritone/api/utils/BlockOptionalMeta.java
+++ b/src/api/java/baritone/api/utils/BlockOptionalMeta.java
@@ -242,7 +242,7 @@ public final class BlockOptionalMeta {
                         .withParameter(LootContextParams.BLOCK_STATE, b.defaultBlockState())
                         .withParameter(LootContextParams.TOOL, new ItemStack(Items.NETHERITE_PICKAXE, 1));
                     getDrops(block, lv5).stream().map(ItemStack::getItem).forEach(items::add);
-                } catch (Exception e) {
+                } catch (Throwable e) {
                     e.printStackTrace();
                 }
                 return items;

Not sure if this is 'good enough' to be merged into the project.

[ipaqmaster]

I came to a similar conclusion but inspecting the culprit json extracted from twilight forest was fine. Perhaps there's still an error among one or more of the other json structures in that version.

[ipaqmaster]

I extracted twilightforest's jar and enumerated each of its JSON files finding no problems.

There were some JSON files from this mod which had //comment lines inside which upset jq during the parsing stage. But removing them and repacking the file did not fix Baritone.

[rfresh2]

the issue is not related to any json metadata files

its how baritone initializes server-side registries on the client-side. its (incorrectly) trying to load non-vanilla registry data.

resolved by https://github.com/cabaletta/baritone/pull/4553

this PR is for 1.20.5 but will be merged up to 1.21 eventually

if you want to test the changes on 1.21 before then you can grab the CI build from my fork: https://github.com/rfresh2/baritone/actions/runs/11754517133

[ipaqmaster]

Thanks

[ZacSharp]

#4553 was merged over two months ago and is ported to all supported branches.