Joining a match

What passes between a client and a server from connection until play begins, in order.

Starting a client

A client learns where to connect from its command line. It takes three arguments it needs nothing in, which can be empty, and then a fourth holding four words separated by single spaces: the server’s IPv4 address, its UDP port, the key (see Transport), and the player id the client registers as. The client connects to that address and port, registers as that player, and enciphers its proof under that key.

In 1.0.0.25–1.0.0.96

A client finds each argument between a pair of double quotes, and reads nothing outside them.

Any whitespace separates the words of the fourth argument. A client whose command line holds no double quote takes the command line it saved on an earlier run instead, and one holding .rep anywhere plays a replay rather than connecting.

Registering

A client’s first payload is Register, on the registration channel. The note on Registered says what a server answers with: one answer for every seat.

A client knows the answer meant for it by the player id it registered as, not by the client id, and takes the client id that answer carries as its own. Every other answer tells it which client id stands for which player.

A client waits 30 seconds for the answer naming its own player id. Then it offers its player to wait another 30 seconds or to give up, and leaves on giving up.

In 1.0.0.58–1.0.0.129

Every answer for its own player id, the first included, has a client send ReconnectedInMatch, saying whether play has yet begun.

Asking whether a server is ready

A client then sends QueryStatus over and over. A server MUST answer each one with QueryStatusAnswer, at least until it has answered that it is ready. While the answers say the server is not ready, a client stays on a black screen and keeps asking. A server that needs time before a match can begin answers that it is not ready until it is.

A client stops asking once an answer says the server is ready, and a query it sends after that answer needs none.

Stating a build

Once an answer says the server is ready, a client sends ClientVersion once. A server answers with VersionSync, and a client loads only where its agreement says the builds agree.

VersionSync names the map to load and everyone at the match.

Taking a seat

Straight after VersionSync, a client sends JoinSide on the roster channel. A server answers with one Roster, then a SeatName and a SeatChampion for each seat a player holds.

Loading

A client reports how far loading has got with LoadingProgress, repeatedly through loading. A server answers each report with SeatLoadProgress on the transient channel, carrying the report’s figures under the seat that reported. A client goes on reporting after its progress reaches 100, until play begins.

A client waits on no other seat. SpawnStart, SpawnEnd and StartGame are what move a client on, and StartGame alone ends its loading. A server that means its players to begin together sends StartGame to none of them until every client has sent ClientReady.

In 1.0.0.25–1.0.0.126

A client writes zero where its player id goes in LoadingProgress.

In 1.0.0.58–1.0.0.60

The loading screen picks the card a SeatLoadProgress updates by the client id it carries, not by its player id.

In 1.0.0.96–1.0.0.129

A server MUST put the seat’s player id in SeatLoadProgress: the loading screen shows a seat’s card from the VersionSync seat with that id.

In 1.0.0.96–1.0.0.129

The loading screen

What a client draws while it loads comes from what it has been sent by then (see the spawn run below for what it takes before CharacterSelected).

A player’s card is built from several messages. Its place on the screen is that seat’s place in the Roster, and its name is that player’s SeatName. The registration answers (Registered) pair each player with a client id, and the latest SeatLoadProgress for that client gives the card its progress and, on the client’s own card only, its ping. The first SeatLoadProgress after the player’s SeatChampion sets the card up: its portrait and the champion’s name, from that SeatChampion’s champion and skin, then everything else from the VersionSync seat whose player id the SeatLoadProgress names. A card with no SeatChampion yet shows a black portrait, and one with no registration or no SeatLoadProgress yet says it is not connected. A later SeatChampion does not change a card already set up.

The spawn run

Once a character is settled, a client sends CharacterSelected, once.

In 1.0.0.25–1.0.0.60

A client drops nothing for arriving before CharacterSelected.

In 1.0.0.96

Before CharacterSelected, a client drops only what Units says it drops, and a GameEnded that arrives while it loads has it show an error and end.

In 1.0.0.126

A client drops nothing for arriving before CharacterSelected.

A server answers with SpawnStart, states everything on the field as play opens, and closes the run with SpawnEnd. A run carries:

for each seat, CreateChampion followed by Loadout;
for each turret, a CreateTurret and a Replication batch of its values;
for each inhibitor and nexus, an EnterSight, and a Replication batch on a map whose buildings replicate (see Replication);
a RegionAdded for each region, and a MapProp for each prop;
at a server’s choice, an EnterLocalSight for any of those units.

A client takes these in any order within the run.

A run MUST carry at least SpawnStart, the CreateChampion carrying the client’s own client id, and SpawnEnd. Given only those, a client still enters play, showing its champion’s portrait, health, resource and spells. It draws the champion on the map only once an EnterSight places it there, with its name and health bar over it.

In 1.0.0.58–1.0.0.60

A client’s shop does not wait for Loadout.

A client answers each Replication batch with a TransientAck naming that batch’s syncId. It sends one answer for each batch, in the order the batches came, including a batch that repeats the syncId of the batch before it.

A client answers a batch as soon as it arrives, within the run or not, and never answers one naming a unit it does not hold.

Starting play

A client sends ClientReady after SpawnEnd and after its answers to the run’s batches, while it is still reporting its loading. A server MUST answer with StartGame, and later sends MatchStarted, with other messages free to come between them; MatchStarted carries 0 (see Time).

A client sends ClientReady as soon as SpawnEnd arrives, and StartGame alone moves it into play.

A client whose connection drops before play begins ends rather than connecting again.

Messages

Each message of this system in this book, with each layout it has across the book’s patches and every note its definition carries. A layout is the message’s body, after the header its channel’s family puts in front (see Messages).

`Register`

What a client sends first. It arrives before the connection has a cipher state, so the payload travels in the clear apart from the proof.

Field	Type	What it is
leading	bytes, 3	Arbitrary; it carries no meaning.
clientId	u32	A client writes zero here.
playerId	i64	Who the sender claims to be. The proof is what settles the claim.
proof	i64	The player id enciphered with the 16-byte key; a plain copy where the client has no key.

Builds	Command
1.0.0.25–1.0.0.109	3
1.0.0.110–1.0.0.129	23

Builds	Command
1.0.0.25–1.0.0.109	4
1.0.0.110	133
1.0.0.111–1.0.0.116	134
1.0.0.117–1.0.0.118	135
1.0.0.119–1.0.0.123	136
1.0.0.124–1.0.0.125	140
1.0.0.126–1.0.0.127	141

Builds	Command
1.0.0.25–1.0.0.73	67
1.0.0.74–1.0.0.81	68
1.0.0.82–1.0.0.96	71
1.0.0.97–1.0.0.102	72
1.0.0.103–1.0.0.106	73
1.0.0.107–1.0.0.109	74
1.0.0.110	188
1.0.0.111–1.0.0.116	189
1.0.0.117–1.0.0.118	190
1.0.0.119–1.0.0.123	191
1.0.0.124	195
1.0.0.125	196
1.0.0.126–1.0.0.127	197

Keyboard shortcuts

Trueshot Season 1