The latest Twilight Forest jar seems to stop #mine from working on 1.21.1
ipaqmaster opened this issue ยท 7 comments
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.
- Drop baritone into the mods folder
- Launch and start a new world
#mine someBlock
- 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
- 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.
I can confirm that Baritone is still capable of responding with daniel
when Damn
is said in the chat despite this issue
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.
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.
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 #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
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.