Skip to content

Obey the flight the server grants in the abilities packet - #142

Open
u9g wants to merge 1 commit into
PrismarineJS:masterfrom
u9g:fix/creative-flight
Open

Obey the flight the server grants in the abilities packet#142
u9g wants to merge 1 commit into
PrismarineJS:masterfrom
u9g:fix/creative-flight

Conversation

@u9g

@u9g u9g commented Sep 7, 2026

Copy link
Copy Markdown
Member

simulatePlayer applies gravity to a player the server has put in flight, so the bot sinks where a vanilla client hovers. PrismarineJS/mineflayer#3274 has a side-by-side capture of it: after an abilities packet with the flying bit, the vanilla client floats and mineflayer drops, and the server's anti-bot check kicks it for that. Issue #7 here asks for the same thing.

Matching Player in 26.1:

  • travel wraps the move and restores the vertical velocity the tick started with, damped by 0.6, in place of gravity and air drag.
  • getFlyingSpeed accelerates at the abilities' flying speed, doubled while sprinting, rather than the 0.02 / 0.026 of a falling player.
  • onClimbable returns false while flying, so ladders do not grab a flying player.

PlayerState reads entity.flying and entity.flyingSpeed as inputs; both are the server's to set, so nothing writes them back. A caller that never sets them (every current one) keeps today's behaviour — flying defaults to false.

Five tests in test/flying.test.js cover the hover, the 0.6 damping, the speed against a falling player (2.5x, i.e. 0.05 against 0.02) and the sprint doubling; four of them fail on master.

The mineflayer side — parsing the packet into bot.entity.flying — is separate; nothing sets these fields yet.

A player the server has put in flight hovers in vanilla; simulatePlayer applied
gravity regardless, so the bot sank out of the air. Player.travel wraps the move
and restores the vertical velocity the tick started with, damped by 0.6, and
Player.getFlyingSpeed accelerates at the abilities' flying speed (doubled while
sprinting) instead of the 0.02 of a falling player. Ladders do not apply while
flying, matching Player.onClimbable.

PlayerState reads entity.flying and entity.flyingSpeed, both owned by the server.

@rom1504 rom1504 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Astra agent review — AI-generated, not manually written by the maintainer.

Reviewed at the maintainer's request. I inspected the current simulator and PlayerState changes, including the existing jump/sneak input paths. I executed the five added test bodies against the current-head physics code in a small Node runner with an assertion adapter (all passed), then reused their fixture to reproduce no vertical movement for jump or sneak held over 40 flying ticks. I did not run the full repository suite or a live server.

Comment thread index.js
// Apply friction and gravity
if (entity.levitation > 0) {
vel.y += (0.05 * entity.levitation - vel.y) * 0.2
if (entity.flying) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Astra agent review — AI-generated, not manually written by the maintainer.

The new flying mode preserves hover but never applies vertical flight input. simulatePlayer only adds upward velocity for water/lava or an on-ground jump, and sneak only scales horizontal input. Using this PR's fakePlayer/world fixture with flying: true and initial vy = 0, holding either jump or sneak for 40 ticks leaves y = 80 and vy = 0 throughout. Once the abilities fields are wired up, the bot can therefore neither ascend nor descend from a hover through its normal controls. Please apply the flying jump/sneak input before movement and damping, using the granted flying speed, and add ascent/descent cases alongside the idle-hover tests.

@rom1504 rom1504 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Astra agent review — AI-generated, not manually written by the maintainer.

I found a separate fluid-path gap in the flight handling. All five added test bodies passed in a small assertion-adapter runner; an idle flying player still sank in water and lava using real 1.13.2 and 1.20.4 block data and this head's simulator. I also checked the vanilla Player/LivingEntity fluid gate and travel wrapper in the 1.20.3-pre1 source. No live vanilla server or full suite was run.

Skills used: prismarine-behavior-test-review helped compare idle hover across actual block environments; prismarine-architecture-review helped trace the flight mode through the shared movement branches; prismarine-review helped avoid repeating the existing jump/sneak finding.

Comment thread index.js
// Apply friction and gravity
if (entity.levitation > 0) {
vel.y += (0.05 * entity.levitation - vel.y) * 0.2
if (entity.flying) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Astra agent review — AI-generated, not manually written by the maintainer.

The flight handling here is reached only by the normal-movement branch; a flying player in water or lava still takes the earlier fluid branch, including fluid acceleration and gravity. With this head's PlayerState/Physics, real 1.13.2 and 1.20.4 source-water/source-lava blocks, flying: true, zero initial velocity and no controls, 40 ticks changed Y from 80 to 79.125 in water and 78.48 in lava (air stayed at 80). This is separate from the existing jump/sneak issue: an idle hover already fails. The vanilla 1.20.3-pre1 source's Player.isAffectedByFluids returns false while flying, and LivingEntity uses that gate for both fluid branches. Please route flying players through the appropriate flight movement in fluids too, and add water/lava hover cases.

Skills used: prismarine-behavior-test-review helped verify the environmental branch with real blocks; prismarine-architecture-review helped trace the flight flag across shared movement paths.

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