fix: stop sending movement input when the window is unfocused - #5335
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughSummary by CodeRabbit
Walkthrough
ChangesLocal player input
Estimated code review effort: 1 (Trivial) | ~3 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@engine/src/main/java/org/terasology/engine/logic/players/LocalPlayerSystem.java`:
- Around line 145-148: Update processInput() so that when display.hasFocus() is
false, relativeMovement, lookPitchDelta, lookYawDelta, and jump are reset or
invalidated before returning; ensure these input values cannot persist and be
reused when focus is restored without new input.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: a07093b4-31ee-40b1-bea0-c9ec5ccb74e2
📒 Files selected for processing (1)
engine/src/main/java/org/terasology/engine/logic/players/LocalPlayerSystem.java
df2f7b7 to
4a7d17c
Compare
|
I tested this, admittedly on Windows, and while movement stops when I press Not sure how much of that was already an issue before this PR, but I wonder if we should cover it as well / test fully on different OSes? |
|
looked again at it. with josariassurvival, when switching away with tab, it gives endless: with core gameplay not. applying this pr stops the output for JSS. |
Addresses BenjaminAmos/CodeRabbit review on #5335.
processInput sent a CharacterMoveInputEvent every frame regardless of focus, even with zero keys held. Under a normal frame rate the resulting client/server clock skew is small enough to pass the server's overflow check. When macOS throttles a backgrounded window's render loop, the skew grows past the check every frame, spamming ServerCharacterPredictionSystem's dropped-input warning the whole time the window is unfocused. Gate processInput on DisplayDevice.hasFocus, the same check InputSystem.isCapturingMouse already uses for raw device polling. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Addresses BenjaminAmos/CodeRabbit review on #5335.
f188544 to
60b3c32
Compare
|
tested on linux, unfocussed error with terasologylauncher downloaded game. |
Summary
LocalPlayerSystem.processInput()sent aCharacterMoveInputEventevery frame unconditionally, even with zero keys held and no window focus - a per-frame heartbeat, not edge-triggered on actual input.ServerCharacterPredictionSystem's overflow check. When macOS throttles a backgrounded window's render loop to a much lower rate (e.g. after Cmd+Tab), the network-queue delivery granularity no longer scales with it, so a small residual skew leaks past the check every single frame - spamming the "dropping input" warning continuously for as long as the window stays unfocused.processInput()onDisplayDevice.hasFocus(), the same checkInputSystem.isCapturingMouse()already uses for raw device polling - no movement input gets generated at all while unfocused.Test plan
gradle :engine:compileJavasucceeds🤖 Generated with Claude Code