Obey the flight the server grants in the abilities packet - #142
Conversation
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
left a comment
There was a problem hiding this comment.
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.
| // Apply friction and gravity | ||
| if (entity.levitation > 0) { | ||
| vel.y += (0.05 * entity.levitation - vel.y) * 0.2 | ||
| if (entity.flying) { |
There was a problem hiding this comment.
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
left a comment
There was a problem hiding this comment.
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.
| // Apply friction and gravity | ||
| if (entity.levitation > 0) { | ||
| vel.y += (0.05 * entity.levitation - vel.y) * 0.2 | ||
| if (entity.flying) { |
There was a problem hiding this comment.
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.
simulatePlayerapplies 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 anabilitiespacket 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
Playerin 26.1:travelwraps the move and restores the vertical velocity the tick started with, damped by0.6, in place of gravity and air drag.getFlyingSpeedaccelerates at the abilities' flying speed, doubled while sprinting, rather than the0.02/0.026of a falling player.onClimbablereturns false while flying, so ladders do not grab a flying player.PlayerStatereadsentity.flyingandentity.flyingSpeedas 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 —flyingdefaults to false.Five tests in
test/flying.test.jscover the hover, the0.6damping, 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.