Game messages reach their owners through one registration each - #113
Conversation
docs/SYSTEMS.md, section 6. - Companion: a project's owners take the game's messages themselves (pack stack, datapacks, playing, change and reload answers, and relay failures of changes and reloads), registered on the connection when the project becomes the current one and removed when it stops being it. CompanionApplication no longer relays each of them to the current project. CompanionSession offers the routes (MessageRoutes). - Mod: one method, on(type, handler), replaces a setter per request. Every request type is checked in one place to come after the handshake; RetryRuntimeInventoryMessage, which had no such check, now fails a session that sends it too early like every other request. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Took 3 minutes
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 78e7fec158
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| this.currentMessages.run(); | ||
| this.currentMessages = () -> { }; | ||
| current = scope; | ||
| if (scope != null && session != null) this.currentMessages = scope.listen(session); |
There was a problem hiding this comment.
Register restored projects after constructing the session
When Companion starts with a project already selected, restoreProfile() calls activateProfile() before session is assigned, so this condition skips scope.listen(session) and no later initialization step registers those routes. Consequently, after every normal restart the restored project silently misses pack-stack, datapack, playing, change/reload-result, and relay-failure messages until the user switches projects; construct the session first or explicitly attach the restored scope afterward.
AGENTS.md reference: AGENTS.md:L19-L19
Useful? React with 👍 / 👎.
Companion reopens the last project before it creates its session, so that project got no routes and dropped the game's packs, playing and answers until the player switched projects. Once the session exists, the current project is registered. ApplicationNavigationTest connects a game to a Companion that reopened its project and sees the packs it names arrive. KeyAssignmentsTest retries its replace of options.txt for a moment, since Windows refuses it while the watch reads the file. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Took 3 minutes
SCNet hands a message to the routes it copied before a route was removed, so a project that stopped being the current one while a message was on its way could still take it. A removed route now drops what reaches it late. CompanionSessionRoutesTest removes a route while an earlier one holds the message. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Second PR of
docs/SYSTEMS.md(section 6): each game message reaches the owner that handles it through its own registration, instead of a relay per message.Finish line
ProjectScopeMessagesTest: the packs the game named reach the project's packsCompanionAutomaticConnectionTest.aRequestBeforeTheHandshakeFailsItsSessionWhateverItsType, withRetryRuntimeInventoryMessage, which had no check before, and a changeCompanionAutomaticConnectionTest.anAnswerGoesOnlyToTheConnectionThatAskedWhat changes
ProjectScope.listen(routes)registers the project's owners for pack stack, datapacks, playing, change and reload answers, and relay failures of changes and reloads.CompanionApplicationregisters the current project when it becomes current and removes it when it stops being current, in one place (makeCurrent). Its relay of each of these messages to the current project goes, and so do their methods onCompanionSession.Listener.CompanionSessionoffers the routes (MessageRoutes).CompanionAppClient.on(type, handler)replaces the setters for scripts, stop-script, changes, reloads and messages to the server. Every request type passes one check that its connection finished the handshake.Production code: +141 −147.
Left as it is
The application's own messages (connection, focus, inspection, prepared files, server scripts, debug target) stay on
CompanionSession.Listener; letting a category register its messages, pages and Modpack rows is A4.:mod:test(222) and:companion:test(1615) pass.🤖 Generated with Claude Code