- summary: Enters the game with a character as a replay rather than an ordinary selection.
- area: Game.Character.Management
- confidence: 0.92
Enters the game with a character as a replay rather than an ordinary selection.
- Kind request
- Area Game.Character.Management
- Named by beta, gamemapping
THE THIRD WAY INTO THE GAME. CharacterSelectionRequest enters with a
character you have played, CharacterFirstSelectionRequest with one you just
created, and this one with a character the client resolves to a replay instead.
WHEN TO SEND IT
FROM THE SAME SCREEN ACTION AS THE OTHER TWO. All three come out of one method in the real client, chosen by two flags the character-selection screen passes with the character id: no flags means the ordinary selection, one means first selection, the other means this. The replay path is raised from a closure inside the screen's own choose-a-character handler, so it is a decision the screen makes about the character you picked, not a separate menu.
IF YOU ARE SCRIPTING SELECTION, the safe default is
CharacterSelectionRequest. Reach for this one only when you are reproducing
a client that resolved the character to the replay path; there is no server-side
signal in this exchange telling you that you should have.
WHAT TO PUT IN IT
THE CHARACTER ID - AND ON SOME BUILDS THE REAL CLIENT SENDS NOTHING AT ALL. That is not a guess: on three of the seven dumped builds the client allocates this message, populates no member, and sends it. On the other four it writes the character id. The member is therefore recovered where the client proves it and left unnamed where it does not.
The practical reading: send the character id. It is what the message is for according to the reference build, and what the more recent clients do.
WHAT COMES BACK
The ordinary game-entry sequence - there is no dedicated reply. Uncorrelated, so the envelope uid is -1 and there is nothing to match against.
When you may send it
- Requires
authenticatedobserved - Raised by: a client-side state change: the character-selection screen resolving a chosen character to the replay path rather than an ordinary selection. A closure inside the same screen method that handles an ordinary choice raises an intent carrying only the character id inferred
Related messages
- Reply not yet recovered: the game-entry burst follows, the same as for an ordinary selection. Those messages are recovered but not documented yet.
Fields
| # | Field | Type | Meaning | You set it |
|---|---|---|---|---|
| 2 | character_id | int64 | The character to replay. | required |
Recovered with score 195, confidence 0.92, margin 195 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 1 of 3.
Aucun avis à afficher.