Mirror upstream PR #9: deterministic prediction + ack replay

[web3dev1337]

This PR mirrors upstream PR hytopiagg#9 onto this fork’s master so we can review/test it here.

• Upstream PR: Improve movement/camera smoothness with deterministic prediction, ack-aware replay, and tick-aligned input application hytopiagg/hytopia-source#9
• Branch: review/mirror-upstream-pr-9

No additional changes beyond cherry-picking the upstream commits.

[web3dev1337]

Review notes (mirrored from upstream PR #9)

Overall: direction looks solid — deterministic movement parity + ack-aware replay + tick-aligned server input application should noticeably reduce “tug” and jitter.

🚨 Potential correctness issue (camera yaw/pitch can get dropped)

On the server, sequenced movement packets are queued, but applyQueuedInputForSimulation() collapses the queue to the last command and only applies cp/cy if they exist on that last command:

• server/src/players/Player.ts (applyQueuedInputForSimulation())

Because the client only includes cp/cy when they change (client/src/input/InputManager.ts), it’s possible for:

1. cp/cy to be present in an earlier queued command,
2. not present in the last command,
3. and then never applied after the batch collapses.

That can leave the server’s camera orientation stale (movement direction resolution becomes wrong) under jitter / packet bunching.

Suggested fix: when consuming a batch, scan the queued commands (from the end) for the most recent defined cp and cy, and apply those even if the last command omits them (similar to how jump intent is preserved via sawJumpPressed).

Compatibility / “old games” risk areas

• Movement inputs now go unreliable + sequenced. WASD/shift/jump/crouch/joystick are now sent as snapshots with sq and usually unreliable; correctness depends on the resend/continuous-snapshot logic in client/src/input/InputManager.ts. This should be fine, but it’s a behavior change vs reliable edge-triggered packets.
• Protocol field aq + strict schema. If a newer server sends aq to an older client whose schema doesn’t include it (and additionalProperties: false), validation could reject entity packets. This PR gates on server-side protocol support, not per-client feature negotiation. Safe if client/server/protocol deploy together; risky under mixed versions.
• Cutscene-style input disabling: server/src/worlds/entities/PlayerEntity.ts calls player.applyQueuedInputForSimulation() even when tickWithPlayerInput is disabled. That may still update player.input + player.camera orientation during “controls disabled” flows.

Performance notes

• Client prediction cost: per-frame substepping is capped (6 substeps). The heavier path is replay: up to 96 buffered commands × up to 12 substeps each (worst-case spike after stalls). Might be worth capping total replay work per frame or amortizing across frames if spikes show up.
• Camera collision: switching raycasts from every-frame to interval/threshold-based sampling is a win for CPU, especially on mobile.
• Network bandwidth: movement snapshots at 60 Hz (desktop) / 30 Hz (mobile) are still small, but higher steady-state than only sending changes.

Suggested manual test matrix

• High jitter + packet loss: confirm no “stale yaw” movement, no stuck movement on key-up.
• Mobile third-person: confirm camera collision doesn’t clip through walls during fast turns/teleports.
• Example games (sdk-examples/): confirm any custom controllers / cutscene input disabling behaves the same.