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.

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

In 0.8.13.26–0.9.22.13

A client whose command line holds no double quote ends.

In 0.9.25.24–1.0.0.24

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.

In 0.8.13.26–0.9.22.13

A client waits for the answer naming its own player id as long as it takes, and offers its player no choice.

In 0.9.25.24–1.0.0.24

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.

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.

In 0.8.13.26–0.9.22.13

VersionSync names neither the map nor anyone at the match: a client loads the map its own configuration names (see The client’s data).

In 0.9.25.24–1.0.0.24

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 0.9.25.24–1.0.0.24

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

In 0.9.25.24–0.9.25.35

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.

The spawn run

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

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.

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.

In 0.9.25.24–1.0.0.24

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.

In 0.9.25.24–1.0.0.24

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.

Builds	Command
0.8.13.26–0.9.22.13	71
0.9.22.14–1.0.0.24	67

Field	Type	What it is
clock	f32	The client’s own clock as it sends this, in seconds.
clientId	u32	The client id the sender holds: that of the client reporting.
text	text, 256 bytes	The build the client runs, as text ending at a zero byte; the bytes after that zero carry nothing.

Field	Type	What it is
agreement	u8	1 lets the client go on into the game. For 0 a client shows both versions and leaves; for any other value it leaves, showing nothing.
build	text, ended by a zero byte	The server’s version, ended by a zero byte; the two take at most 512 bytes, and a client fails on a longer one.

Field	Type	What it is
agreement	u8	Nonzero where the builds agree, letting the client go on into the game. For 0 a client shows both versions, reports a build mismatch and leaves.
map	i32	Which map to load. Space keys the path origins by the same maps.
seats	12 × Seat	Every place at the match, held or empty.
build	text, 256 bytes	Which build the server serves, shown and not checked. Written out in full and padded with zero bytes to the width above; a client reads it up to the first zero byte.

Keyboard shortcuts

Trueshot Beta