Some information

Operating system: Win 11
Java version: build 1.8.0_341-b10
Minecraft version: 1.12.2
Baritone version: 1.2.15 standalone-forge
Other mods (if used): Using a modpack "Lapito's Galacticraft"

Exception, error or logs

Attached - Latest.log

How to reproduce

Using the #mine command.

Modified settings

[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] > modified
[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] All modified settings:
[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] --
[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] --
[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] --
[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] --
[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] --
[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] --
[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] --
[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] --
[13:44:44] [Client thread/INFO]: [CHAT] [Baritone] << | >> 1/1

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.

Oh yea you're right.

According to your log, this is actually a problem with your mod pack. Looks like the server for a tool that your mods uses to run, MCPBot, is currently down. This is not an issue related to Baritone.

no @Clausable that error's unrelated

You used Baritone v1.2.14, not v1.2.15 like stated in the issue title (this is really important when trying to read the obfuscated stacktrace. Comparing the trace against the wrong jar results in nonsensical results).

The cause seems to be in WorldScanner.repack(IPlayerContext, int) (which shows up only once in the trace because it was inlined into WorldScanner.repack(IPlayerContext)), so it's any of these being null:

• ctx -> not null (it's an enum constant assigned to a final field via a getter method)
• ctx.world() -> directly refers to mc.world, not null while in a world. If it were null the game would probably crash instantly
• ctx.world().getChunkProvider() -> not null, otherwise the game would have crashed before (e.g. when getting the player position)
• ctx.worldData() -> shouldn't be null, but caused problems before
• ctx.worldData().getCachedWorld() -> returns a nonnull final field
• ctx.playerFeet() -> returns only values known to not be null

So this seems to be another variation of WorldProvider.worldData not being set, which is indicated by "Baritone world data dir: " not showing up in the log.
Since you used v1.2.14 this means WorldProvider.initWorld wasn't called at all (on newer versions there's a special case for replaymod that also causes null worldData), meaning GameEventHandler.onWorldEvent wasn't called post world load, meaning some of your mods injects an additional return into Minecraft.loadWorld(WorldClient, String) after Mixin application.
I'm not going to try and figure out which of the mods is the culprit.

The above wall of text is the reason why you should use an unoptimized build of Baritone (which sadly doesn't exist for Forge on 1.12.2) and as few mods as possible when reporting bugs.
Being able to look at the log and to see that the exception was thrown in line 122 of WorldScanner.repack and then being able to look at the (source code of) the only other involved mod to see that it injects code into Minecraft.loadWorld would have been much faster and I would even have a chance to fix the problem because I would know exactly what the other mod is doing to break it.

Actually @wagyourtail couldn't we use your hackpatch for 1.19.3 here as well?
Probably should put in a sanity check to make sure we don't mix up worlds in case the unload hook is equally broken but apart from that this seems to be a reasonable solution here as well.

o right that one.
if you want, just pr that for master