fix: decouple first-person camera from bot aims #103

Merged

gecko merged 1 commit from t3/decouple-camera-bot-movement into main

2026-11-03 18:40:53 +00:00

gecko commented

2026-11-03 18:34:27 +00:00

Owner

Summary

Keep the first-person camera under player control while a job runs. Baritone now stays in its server-look mode (free look on, block free look on, anti-cheat compatibility on), so pathing and harvest aims are applied to the outgoing movement packet and Baritone restores the local camera before rendering.
Add a tick-scoped camera shield that captures the player's view at tick start and restores it after the tick. This also covers same-tick chest opens and placements that use a temporary local aim.
Queue placement aims (aimForServer) and apply them from SendMovementPacketsEvent.Pre after Baritone's own look. The server sees the exact validated interaction face without an extra standalone rotation packet, and the camera never moves for it.
Clear the queued aim on combat/job transitions and restore the user's Baritone look settings on stop/deactivation.
Document the first-person camera behavior in the README.

Why

Previously the view lease forced Baritone into client look mode (freeLook=false), so Baritone left the entity rotated toward the path or crop every tick and the camera snapped. Server-side interactions still need the server to observe the exact harvest/placement rotation, so simply enabling free look was not enough.

The new lease uses Baritone's SERVER look mode. Baritone applies the aim before sendChanges, the aim rides the normal movement packet, and Baritone's POST phase restores the camera. The local shield covers the remaining same-tick aims that Baritone does not own.

Anti-cheat considerations

Travel sends the path-facing rotation, and harvest/placement sends the exact interaction aim; the player's free camera rotation is not used for server-side actions.
Queued aims ride the existing movement packet instead of adding a separate rotation packet.
No reflection, mixins, or Baritone implementation packages were added; only public Meteor events and Baritone settings/API.

Harvest throughput

The change does not add ticks to harvesting or placement. Normal farming still uses Baritone's one interaction per tick; toolmode still aims through the movement look and confirms each footprint before the next swing.

Local validation

./gradlew ... compileJava lint test — BUILD SUCCESSFUL
./gradlew ... build — BUILD SUCCESSFUL
./scripts/ci-preflight.sh — passed
./scripts/check-release-jar.sh — passed

Tested commit: ca371e7.

Forgejo CI: https://git.glitched.systems/gecko/mcbot/actions/runs/876 (passed).

## Summary - Keep the first-person camera under player control while a job runs. Baritone now stays in its server-look mode (free look on, block free look on, anti-cheat compatibility on), so pathing and harvest aims are applied to the outgoing movement packet and Baritone restores the local camera before rendering. - Add a tick-scoped camera shield that captures the player's view at tick start and restores it after the tick. This also covers same-tick chest opens and placements that use a temporary local aim. - Queue placement aims (`aimForServer`) and apply them from `SendMovementPacketsEvent.Pre` after Baritone's own look. The server sees the exact validated interaction face without an extra standalone rotation packet, and the camera never moves for it. - Clear the queued aim on combat/job transitions and restore the user's Baritone look settings on stop/deactivation. - Document the first-person camera behavior in the README. ## Why Previously the view lease forced Baritone into client look mode (`freeLook=false`), so Baritone left the entity rotated toward the path or crop every tick and the camera snapped. Server-side interactions still need the server to observe the exact harvest/placement rotation, so simply enabling free look was not enough. The new lease uses Baritone's SERVER look mode. Baritone applies the aim before `sendChanges`, the aim rides the normal movement packet, and Baritone's POST phase restores the camera. The local shield covers the remaining same-tick aims that Baritone does not own. ## Anti-cheat considerations - Travel sends the path-facing rotation, and harvest/placement sends the exact interaction aim; the player's free camera rotation is not used for server-side actions. - Queued aims ride the existing movement packet instead of adding a separate rotation packet. - No reflection, mixins, or Baritone implementation packages were added; only public Meteor events and Baritone settings/API. ## Harvest throughput The change does not add ticks to harvesting or placement. Normal farming still uses Baritone's one interaction per tick; toolmode still aims through the movement look and confirms each footprint before the next swing. ## Local validation - `./gradlew ... compileJava lint test` — BUILD SUCCESSFUL - `./gradlew ... build` — BUILD SUCCESSFUL - `./scripts/ci-preflight.sh` — passed - `./scripts/check-release-jar.sh` — passed Tested commit: `ca371e7`. Forgejo CI: https://git.glitched.systems/gecko/mcbot/actions/runs/876 (passed).

gecko added 1 commit

2026-11-03 18:34:27 +00:00

fix: decouple first-person camera from bot aims

build / Java 25 build (pull_request) Successful in 3m24s

Details

ca371e71e7

Baritone's client look mode made the player entity follow every pathing and harvest aim, so the first-person view snapped while a job ran. Lease Baritone's server look mode instead: aims ride the normal movement packets while Baritone restores the camera, and a tick-scoped camera shield covers same-tick interactions. Queued placement aims now apply after Baritone's own look so the server still observes the exact interaction face without moving the local view.

gecko merged commit 9bcbdb3486 into main

2026-11-03 18:40:53 +00:00

gecko referenced this pull request from a commit

2026-11-03 18:40:54 +00:00

Merge pull request 'fix: decouple first-person camera from bot aims' (#103) from t3/decouple-camera-bot-movement into main