Network multiplayer optimization (UI improvements)#9671
Network multiplayer optimization (UI improvements)#9671MostCromulent wants to merge 6 commits intoCard-Forge:masterfrom
Conversation
Improves user experience during network games: - Waiting timer shows player name and elapsed time (CMatchUI, InputLockUI) - Connection errors display detailed messages instead of generic failure - Adds CONN_ERROR_PREFIX constant for structured error handling - New localization strings for waiting and error messages UI-only changes, no game logic or delta sync functionality. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Use GameView data only in findWaitingForPlayerName() to work on both host and client (fixes null Game on network clients) - Add findPriorityPlayer() using PlayerView.getHasPriority() - Use localized string prefixes in isWaitingMessage() instead of hardcoded English strings - Add volatile to timer fields for thread safety Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
| if (ixCall != iCall.get() || !isActive()) { | ||
| return; | ||
| } | ||
| FThreads.invokeInEdtLater(showMessageFromEdt); |
There was a problem hiding this comment.
when is this relevant in netplay? somehow I never reached a breakpoint here... 🤔
I don't understand why there should be two timer systems:
If one input isn't enough, then why isn't it only handled in AbstractGuiGame instead so it works for mobile too?
There was a problem hiding this comment.
Ignore most recent commit, I'll rework this.
There was a problem hiding this comment.
Actually, can I confirm:
I understand ordinarily display wouldn't be in AbstractGuiGame, however Claude AI's initial approach in 9cfa358 was to consolidate both timing and display in AbstractGuiGame on the basis waiting for opponent prompt is already dealt with in line 479-480 (albeit briefly).
From your perspective is that the preferable approach, or should it be attempting to keep the timing in AbstractGuiGame and move the rest elsewhere? E.g. Have AbstractGuiGame deal with the timer then CMatchUI and MatchController can each format their own platform-specific waiting messages.
My assumption is better to split them out given current waiting prompt is ~1-2 lines in AbstractGuiGame and therefore trivial, while Claude's consolidated approach would take up a lot more space.
Sorry for ignorance or if this is a stupid question, I just want to figure out the correct principle to apply here and for future reference.
There was a problem hiding this comment.
what's the argument for "platform-specific waiting messages"?
it looked like a step in the right direction before revert
Addresses review feedback from tool4ever: consolidate timer logic into the existing awaitNextInput() mechanism in AbstractGuiGame instead of adding separate timer systems in InputLockUI and CMatchUI. Changes: - Revert InputLockUI.java to master (remove ~100 lines of timer code) - Revert CMatchUI.java to master (remove ~185 lines of timer/prompt code) - Enhance AbstractGuiGame.updatePromptForAwait() with: - Player name lookup (shows "Waiting for [Player]..." in network games) - Elapsed time display (shows "(5s)" or "(1:23)" suffix) - 1-second reschedule loop for network games only - Remove unused lblYieldingWaitingForPlayer from en-US.properties Benefits: - 1 timer system instead of 3 (reuses existing awaitNextInputTimer) - Platform-neutral: works on mobile automatically - No duplicate code: single findWaitingForPlayerName() implementation - Smaller diff: 155 lines total vs 369 before refactor Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This reverts commit 9cfa358.
…8-UP5xm Revert "Refactor waiting timer to AbstractGuiGame (PR 9671 feedback)"
4 participants
THIS PR HAS BEEN SPLIT FROM #9642.
Dependency
This branch is has been refactored to be fully independent from other features in #9642.
Features
Waiting timer and connection error improvements for network games:
timeout, no route to host)
Files Changed
CMatchUI.javaInputLockUI.javaNetConnectUtil.javaCSubmenuOnlineLobby.javaCONN_ERROR_PREFIXfor detailed error displayOnlineLobbyScreen.javaCONN_ERROR_PREFIXfor detailed error displayForgeConstants.javaCONN_ERROR_PREFIXconstanten-US.properties