Skip to content

Fix: Baritone Pause - #6681

Merged
Wide-Cat merged 1 commit into
MeteorDevelopment:masterfrom
taro222:master
Sep 26, 2026
Merged

Wide-Cat merged 1 commit into
MeteorDevelopment:masterfrom
taro222:master

Conversation

@taro222

@taro222 taro222 commented Sep 26, 2026

Copy link
Copy Markdown
Contributor

Type of change

  • Bug fix
  • New feature

Description

Fix Baritone activity detection when the BuilderProcess is active.

Previously, BaritonePathManager.isPathing() only checked PathingBehavior.isPathing(). This caused Meteor to consider Baritone inactive while commands using the BuilderProcess, such as #sel cleararea, were running.

The check now also considers getBuilderProcess().isActive(), allowing modules that pause Baritone, such as AutoEat, to correctly detect and pause an active #sel cleararea operation.

Related issues

None.

How Has This Been Tested?

Tested in-game using Baritone's selection commands:

  1. Created a selection using #sel 1 and #sel 2.
  2. Started #sel cleararea.
  3. Triggered AutoEat while the clear-area operation was running.
  4. Verified that Baritone pauses while eating and resumes the clear-area operation afterwards.

Checklist:

  • My code follows the style guidelines of this project.
  • I have added comments to my code in more complex areas.
  • I have tested the code in both development and production environments.

@taro222 taro222 changed the title Pause fix Fix: Baritone Pause Sep 26, 2026
@Wide-Cat
Wide-Cat merged commit e15ab32 into MeteorDevelopment:master Sep 26, 2026
oxodx referenced this pull request in oxodx/nekoclient Sep 27, 2026
Brings in 4 upstream commits; two of them (5f274f5 Notebot, 77125da
damage-protection) were already present in this fork under different hashes and
were skipped, leaving two genuinely new changes:

  c3d6cbb fix(mixin): conditionally apply Baritone mixins
  e15ab32 Fix baritone not considered active when building (#6681)

BaritonePathManager.isPathing() now also reports active while a builder process
is running, so building a path counts as pathing.

MixinPlugin picks up the Baritone gate. Upstream detects it with
FabricLoader.getInstance().isModLoaded(...); here it goes through
LoaderDetection.isModLoaded(...) instead, because MixinPlugin lives in common and
must not reference a loader API directly -- LoaderDetection resolves the active
loader reflectively, which is also what lets the gate work on NeoForge.

Conflict: upstream edits src/main/java/.../MixinPlugin.java, which this fork
moved to common/src/main/java during the multi-module split, so git saw a
modify/delete rather than a modify/rename. Took our deletion of the old path and
re-applied the Baritone change to the relocated file, preserving the
fabricOnlyMixins/neoforgeOnlyMixins platform gating.

Verified after the merge: NeoForge boots and initialises with no crashes and no
mixin apply errors, Fabric likewise, and gradle build -x test passes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
SergZorgRoot pushed a commit to SergZorgRoot/meteor-client that referenced this pull request Sep 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants