From e475c36271088f4355680c503f59339ee944f076 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Charvet=20=E9=BB=91=E7=93=9C?= Date: Mon, 23 Sep 2024 10:32:58 +0100 Subject: [PATCH] Remove matchmaking/readyUpdate event (#36) It is redundant with foundUpdate, and the client should already have the expected number of player for each queues. --- docs/schema/matchmaking.md | 77 +---------------------- docs/schema/system.md | 12 ++-- docs/schema/user.md | 56 ++++++++--------- schema/compiled.json | 24 ------- schema/matchmaking/readyUpdate/event.json | 26 -------- src/schema/matchmaking/README.md | 2 +- src/schema/matchmaking/readyUpdate.ts | 15 ----- 7 files changed, 36 insertions(+), 176 deletions(-) delete mode 100644 schema/matchmaking/readyUpdate/event.json delete mode 100644 src/schema/matchmaking/readyUpdate.ts diff --git a/docs/schema/matchmaking.md b/docs/schema/matchmaking.md index 00100e7..1345347 100644 --- a/docs/schema/matchmaking.md +++ b/docs/schema/matchmaking.md @@ -8,7 +8,7 @@ The matchmaking cycle works as follows: 2. Clients should then queue for one or more of these queues by sending an array of the queue ids in a [queue](#queue) request. 3. The server can send periodic updates about the status of the search as a [queueUpdate](#queueupdate) event. 4. When a match is found, the server should send a [found](#found) event along with the id of the queue of the found match. -5. Clients can then ready up by sending a [ready](#ready) request. The number of readied players should be sent to clients via the [readyUpdate](#readyupdate) event. +5. Clients can then ready up by sending a [ready](#ready) request. The number of readied players should be sent to clients via the [foundUpdate](#foundupdate) event. 6. To cancel queueing, or to decline a found match, clients should send a [cancel](#cancel) request. After a successful `cancel` response, the server will also send a [cancelled](#cancelled) event. 7. If a client fails to ready up for a found match, the server should send a [lost](#lost) event, and the queueing phase should resume. 8. Once all players are ready, the server should send a [autohost/battleStart](#autohost/battleStart) request to a suitable autohost client. If the autohost doesn't respond quickly, or if it sends a failed response, the server should repeat this step. @@ -35,7 +35,6 @@ The server may send [matchmaking/cancelled](#cancelled) event at any point after - [queue](#queue) - [queueUpdate](#queueupdate) - [ready](#ready) -- [readyUpdate](#readyupdate) --- ## Cancel @@ -1008,77 +1007,3 @@ export interface MatchmakingReadyOkResponse { ``` Possible Failed Reasons: `no_match`, `internal_error`, `unauthorized`, `invalid_request`, `command_unimplemented` ---- - -## ReadyUpdate - -Sent when a client in a found match readies up. - -- Endpoint Type: **Event** -- Source: **Server** -- Target: **User** -- Required Scopes: `tachyon.lobby` - -### Event - -
-JSONSchema - -```json -{ - "title": "MatchmakingReadyUpdateEvent", - "tachyon": { - "source": "server", - "target": "user", - "scopes": ["tachyon.lobby"] - }, - "type": "object", - "properties": { - "type": { "const": "event" }, - "messageId": { "type": "string" }, - "commandId": { "const": "matchmaking/readyUpdate" }, - "data": { - "title": "MatchmakingReadyUpdateEventData", - "type": "object", - "properties": { - "readyMax": { "type": "integer" }, - "readyCurrent": { "type": "integer" } - }, - "required": ["readyMax", "readyCurrent"] - } - }, - "required": ["type", "messageId", "commandId", "data"] -} - -``` -
- -
-Example - -```json -{ - "type": "event", - "messageId": "Duis Lorem", - "commandId": "matchmaking/readyUpdate", - "data": { - "readyMax": -28000000, - "readyCurrent": -28000000 - } -} -``` -
- -#### TypeScript Definition -```ts -export interface MatchmakingReadyUpdateEvent { - type: "event"; - messageId: string; - commandId: "matchmaking/readyUpdate"; - data: MatchmakingReadyUpdateEventData; -} -export interface MatchmakingReadyUpdateEventData { - readyMax: number; - readyCurrent: number; -} -``` diff --git a/docs/schema/system.md b/docs/schema/system.md index 27b91bb..7f83a7f 100644 --- a/docs/schema/system.md +++ b/docs/schema/system.md @@ -52,10 +52,10 @@ Ask the server to terminate the connection. ```json { "type": "request", - "messageId": "consequat Lorem", + "messageId": "Duis Lorem", "commandId": "system/disconnect", "data": { - "reason": "consequat Lorem" + "reason": "Duis Lorem" } } ``` @@ -130,7 +130,7 @@ export interface SystemDisconnectRequestData { ```json { "type": "response", - "messageId": "commodo Lorem", + "messageId": "consequat Lorem", "commandId": "system/disconnect", "status": "success" } @@ -190,7 +190,7 @@ Get server stats such as user count. ```json { "type": "request", - "messageId": "ut Lorem", + "messageId": "commodo Lorem", "commandId": "system/serverStats" } ``` @@ -267,11 +267,11 @@ export interface SystemServerStatsRequest { ```json { "type": "response", - "messageId": "occaecat Lorem in", + "messageId": "ut Lorem", "commandId": "system/serverStats", "status": "success", "data": { - "userCount": -20000000 + "userCount": -22000000 } } ``` diff --git a/docs/schema/user.md b/docs/schema/user.md index fa9e6de..d4f005d 100644 --- a/docs/schema/user.md +++ b/docs/schema/user.md @@ -120,59 +120,59 @@ Sent by the server to inform the client when subscribed users get updated in som ```json { "type": "event", - "messageId": "pariatur Lorem reprehenderit", + "messageId": "occaecat Lorem in", "commandId": "user/updated", "data": { "users": [ { - "pariaturff": -17999999.999999955, + "occaecatff": -19999999.999999955, "userId": "f47a7e1e-4b2f-4d3d-3f3c-1f0f0e4b7e1e", - "username": "pariatur Lorem reprehenderit", + "username": "occaecat Lorem in", "scopes": [ - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit" + "occaecat Lorem in", + "occaecat Lorem in", + "occaecat Lorem in" ], - "countryCode": "pariatur Lorem reprehenderit", + "countryCode": "occaecat Lorem in", "status": "menu", "outgoingFriendRequestIds": [ - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit" + "occaecat Lorem in", + "occaecat Lorem in", + "occaecat Lorem in" ] }, { - "pariaturff": -17999999.999999955, + "occaecatff": -19999999.999999955, "userId": "f47a7e1e-4b2f-4d3d-3f3c-1f0f0e4b7e1e", - "username": "pariatur Lorem reprehenderit", + "username": "occaecat Lorem in", "scopes": [ - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit" + "occaecat Lorem in", + "occaecat Lorem in", + "occaecat Lorem in" ], - "countryCode": "pariatur Lorem reprehenderit", + "countryCode": "occaecat Lorem in", "status": "menu", "outgoingFriendRequestIds": [ - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit" + "occaecat Lorem in", + "occaecat Lorem in", + "occaecat Lorem in" ] }, { - "pariaturff": -17999999.999999955, + "occaecatff": -19999999.999999955, "userId": "f47a7e1e-4b2f-4d3d-3f3c-1f0f0e4b7e1e", - "username": "pariatur Lorem reprehenderit", + "username": "occaecat Lorem in", "scopes": [ - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit" + "occaecat Lorem in", + "occaecat Lorem in", + "occaecat Lorem in" ], - "countryCode": "pariatur Lorem reprehenderit", + "countryCode": "occaecat Lorem in", "status": "menu", "outgoingFriendRequestIds": [ - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit", - "pariatur Lorem reprehenderit" + "occaecat Lorem in", + "occaecat Lorem in", + "occaecat Lorem in" ] } ] diff --git a/schema/compiled.json b/schema/compiled.json index 817b5d4..ba2b1a8 100644 --- a/schema/compiled.json +++ b/schema/compiled.json @@ -1690,30 +1690,6 @@ } ] }, - { - "title": "MatchmakingReadyUpdateEvent", - "tachyon": { - "source": "server", - "target": "user", - "scopes": ["tachyon.lobby"] - }, - "type": "object", - "properties": { - "type": { "const": "event" }, - "messageId": { "type": "string" }, - "commandId": { "const": "matchmaking/readyUpdate" }, - "data": { - "title": "MatchmakingReadyUpdateEventData", - "type": "object", - "properties": { - "readyMax": { "type": "integer" }, - "readyCurrent": { "type": "integer" } - }, - "required": ["readyMax", "readyCurrent"] - } - }, - "required": ["type", "messageId", "commandId", "data"] - }, { "title": "SystemDisconnectRequest", "tachyon": { diff --git a/schema/matchmaking/readyUpdate/event.json b/schema/matchmaking/readyUpdate/event.json deleted file mode 100644 index 59bc658..0000000 --- a/schema/matchmaking/readyUpdate/event.json +++ /dev/null @@ -1,26 +0,0 @@ -{ - "$id": "https://schema.beyondallreason.dev/tachyon/matchmaking/readyUpdate/event.json", - "$schema": "http://json-schema.org/draft-07/schema#", - "title": "MatchmakingReadyUpdateEvent", - "tachyon": { - "source": "server", - "target": "user", - "scopes": ["tachyon.lobby"] - }, - "type": "object", - "properties": { - "type": { "const": "event" }, - "messageId": { "type": "string" }, - "commandId": { "const": "matchmaking/readyUpdate" }, - "data": { - "title": "MatchmakingReadyUpdateEventData", - "type": "object", - "properties": { - "readyMax": { "type": "integer" }, - "readyCurrent": { "type": "integer" } - }, - "required": ["readyMax", "readyCurrent"] - } - }, - "required": ["type", "messageId", "commandId", "data"] -} diff --git a/src/schema/matchmaking/README.md b/src/schema/matchmaking/README.md index c104542..bafaedf 100644 --- a/src/schema/matchmaking/README.md +++ b/src/schema/matchmaking/README.md @@ -4,7 +4,7 @@ The matchmaking cycle works as follows: 2. Clients should then queue for one or more of these queues by sending an array of the queue ids in a [queue](#queue) request. 3. The server can send periodic updates about the status of the search as a [queueUpdate](#queueupdate) event. 4. When a match is found, the server should send a [found](#found) event along with the id of the queue of the found match. -5. Clients can then ready up by sending a [ready](#ready) request. The number of readied players should be sent to clients via the [readyUpdate](#readyupdate) event. +5. Clients can then ready up by sending a [ready](#ready) request. The number of readied players should be sent to clients via the [foundUpdate](#foundupdate) event. 6. To cancel queueing, or to decline a found match, clients should send a [cancel](#cancel) request. After a successful `cancel` response, the server will also send a [cancelled](#cancelled) event. 7. If a client fails to ready up for a found match, the server should send a [lost](#lost) event, and the queueing phase should resume. 8. Once all players are ready, the server should send a [autohost/battleStart](#autohost/battleStart) request to a suitable autohost client. If the autohost doesn't respond quickly, or if it sends a failed response, the server should repeat this step. diff --git a/src/schema/matchmaking/readyUpdate.ts b/src/schema/matchmaking/readyUpdate.ts deleted file mode 100644 index a329975..0000000 --- a/src/schema/matchmaking/readyUpdate.ts +++ /dev/null @@ -1,15 +0,0 @@ -import { Type } from "@sinclair/typebox"; - -import { defineEndpoint } from "@/generator-helpers.js"; - -export default defineEndpoint({ - source: "server", - target: "user", - description: "Sent when a client in a found match readies up.", - event: { - data: Type.Object({ - readyMax: Type.Integer(), - readyCurrent: Type.Integer(), - }), - }, -});