Add feature flag for lpVec3 entity velocity

[GenerelSchwerz]

Summary

Adds entityVelocityIsLpVec3 for Java Edition 1.21.9 and newer. These versions changed entity velocity packet fields from fixed-point vec3i16 values to lpVec3 values expressed in blocks per tick.

Mineflayer needs this boundary to avoid applying the legacy 1/8000 conversion to already-decoded lpVec3 values.

Validation

• npm test in tools/js

[extremeheat]

avoid applying the legacy 1/8000 conversion to already-decoded lpVec3 values.

This doesn't make sense. The underlying data is a vec3. The serialization logic should be in the special data type, not in mineflayer. Mineflayer only reads the end float

[GenerelSchwerz]

Mineflayer currently does the notchian conversion (1/8000). I am saying to skip that for versions past 1.21.9.

That isn't something I wrote. My flag here is meant to simply skip that step.

[extremeheat]

Per claude

The 1/8000 conversion is in Mineflayer, not NMP. Specifically in lib/plugins/entities.js, Mineflayer always calls conv.fromNotchVelocity(notchVel) which multiplies the raw velocity integers by 1/8000 to convert to blocks/tick — the old "Notchian" encoding where velocity is sent as shorts in units of 1/8000 of a block/tick.

In 1.21.9+, Minecraft changed the entity velocity packet to use the new lpVec3 wire format. NMP's lpVec3.js decodes this into a real floating-point {x, y, z} in actual blocks/tick — no 1/8000 factor involved.

The problem: Mineflayer still blindly applies fromNotchVelocity() (×1/8000) even for these new versions, which would massively under-scale the velocity.

What the commenter means: The minecraft-data PR adds a feature flag (e.g. lpVec3EntityVelocity) so Mineflayer can check: "is this version using the new lpVec3 velocity format?" If yes → skip the ×1/8000 step. The commenter is clarifying that they didn't write the 1/8000 logic — that's pre-existing Mineflayer code — and their flag is purely a signal for Mineflayer to bypass it for newer versions.