This page describes the communication protocol employed by launcher.exe, Tl.exe, and TERA.exe.
C/C++-like primitive types and structs will be used.
Integers (uint8_t, int8_t, uint16_t, int16_t, etc) are little endian.
Characters (i.e. char8_t and char16_t) are UTF-8 and UTF-16 respectively, and little endian.
Strings (i.e. u8string and u16string) are a series of valid char8_t and char16_t characters respectively, followed by a NUL character.
Fields are laid out in the declared order with no implied padding anywhere.
Note that strings are not always NUL-terminated. For this reason, the document will explicitly call out whether a NUL terminator is present.
The role of each program is as follows:
launcher.exe: The publisher-specific game launcher which performs authentication and server list URL resolution. Serves requests from Tl.exe and receives game events.
Tl.exe: The (mostly) publisher-agnostic game launcher which requests authentication data and the server list URL from launcher.exe. Serves requests and forwards game events from TERA.exe.
TERA.exe: The actual game client. Sends requests and game events to Tl.exe.
These programs all communicate via window messages, specifically WM_COPYDATA. The dwData field specifies the message ID, while lpData and cbData contain the payload pointer and length.
Tl.exe -> launcher.exe MessagesMessages sent between Tl.exe and launcher.exe consist of text encoded as UTF-8. A NUL terminator is present in most messages, but not all. Responses from launcher.exe should always use the same message ID that Tl.exe used in the corresponding request message. Notably, only the Hello Handshake and Game Event Notification messages have a static ID; the request messages use a message counter as the message ID, so the contents must be parsed to understand them.
0x0dbadb0a)The protocol starts off with a handshake sent from Tl.exe. This message contains the NUL-terminated string Hello!!.
launcher.exe should respond with a NUL-terminated Hello!! or Steam!! to indicate the method of authentication in use. The former uses classic authentication while the latter uses Steam. (Steam authentication will not be documented here.)
0x0)Tl.exe will occasionally notify launcher.exe of various game events sent by TERA.exe. The format of these messages can be described with the following regular expressions:
^csPopup\(\)$: Signals that launcher.exe should open the customer support website (e.g. in the default Web browser).
^gameEvent\((\d+)\)$: Indicates some kind of notable action taken by the user in the game. The value in parentheses is a code specifying the type of event; the possible values are documented in the section on TERA.exe messages.
^endPopup\((\d+)\)$: Indicates that the client has exited. The value in parentheses is an exit reason code (not the same as the process exit code); the possible values are documented in the section on TERA.exe messages.
^promoPopup\(\d+\)$: The exact purpose of this notification is currently unknown.
launcher.exe should not respond to these messages.
Tl.exe will request the server list URL from launcher.exe. This message does not have a static message ID. The message contains the NUL-terminated string slsurl.
launcher.exe should respond with the NUL-terminated server list URL.
The Web server at the URL should be prepared to receive an HTTP GET request, potentially with a query string (which can be ignored). The response should use the application/xml media type. Note that Tl.exe does not support chunked transfer encoding.
The response received from the server list URL should be in XML format. It can be described with the following XSD schema:
Tl.exe will request JSON-encoded authentication data from launcher.exe. This message does not have a static message ID. The message contains one of several NUL-terminated strings.
gamestr is only sent when the game is initially launched. This request asks for the full authentication data.
ticket, last_svr, and char_cnt are only sent when returning to the server list from an arbiter server.
ticket: Requests the authentication ticket. This can be the same ticket as before, but launcher.exe may also choose to authenticate anew and retrieve a fresh ticket.
last_svr: Requests the ID of the last server the the account connected to.
char_cnt: Requests character counts for each server in the server list.
launcher.exe should respond with the NUL-terminated JSON payload.
The authentication JSON response can be described with the following JSON Schema definition: