Difference between revisions of "Launcher Protocol"

From OdaWiki
(Specifications)
Line 295: Line 295:
 
* If CTF is enabled, Teamplay will be enabled and deathmatch (2.0?).
 
* If CTF is enabled, Teamplay will be enabled and deathmatch (2.0?).
 
* If Teamplay is enabled, then deathmatch (2.0?) will be too.
 
* If Teamplay is enabled, then deathmatch (2.0?) will be too.
* scorelimit, team scores and player teams (excluding team 0) only appear if Teamplay/CTF is enabled.
+
* Scorelimit, team scores and player teams (excluding team 0) only appear if Teamplay/CTF is enabled.
 +
 
 +
== Possible Future Protocol Improvements ==
 +
 
 +
=== All ===
 +
 
 +
* Dedicated Odamex Query/Response values (rather than old csdoom ones)
 +
* Proper versioning, with possible subversion number.
 +
* Container (header based) protocol which would contain: Magic Tag, Size, Version (see above) and the data, this would allow features to be added in any order in 1 packet without breaking it, so if the launcher/server can't understand the magic value, it'll bypass it, via jumping past the entire size of the unknown header to the next one.
 +
* Packets will have a size, to indicate their boundary, including a null termination
 +
* Strings will have a size value, including the null termination.
 +
* Strings will be UTF-8 encoded. (Unicode)
  
 
==External Links==
 
==External Links==
  
 
* None at the moment.
 
* None at the moment.

Revision as of 01:43, 27 February 2008

Overview

This is the Odamex Launcher protocol, which will help developers develop custom launchers in other programming languages

Transport notes

  • This protocol uses UDP (User Datagram Protocol) as its transport medium.
  • All packets are uncompressed.
  • All data is little endian.

Types used

These are the types used in this specification

Type name Range Size
Signed Integers
char -128 to 127 8-bit
short -32768 to 32767 16-bit
int -2147483648 to 2147483647 32-bit
Unsigned integers
byte 0 to 255 8-bit
word 0 to 65535 16-bit
long 0 to 4294967295 32-bit
Strings
string ASCIIZ null terminated
Other
bool byte (1 or 0) boolean

Keywords:

> = Sent to

+ = Array of information (amount here)

X = Any value

Specifications

Master server list request

Type Data Description
Launcher > Master
int 777123 Request
Master > Launcher
int 777123 Response
short X Server count
byte X +Server IP 1 (Server count)
byte X +Server IP 2
byte X +Server IP 3
byte X +Server IP 4
short X +Server Port


Server Information Request

Type Data Description
Launcher > Server
int 777123 Request
Server > Launcher
int 5560020 Response
int X Token
string X Server Name
byte X Players in server
byte X Maximum players
string X Current map
byte X PWAD count
string X +PWAD name (PWAD count)
byte X Game type
byte X Skill level
byte (boolean) X Teamplay?
byte (boolean) X CTF mode?
string X +Player name (numplayers)
short X +Player frags
int X +Player ping
byte X +Player team
string X +PWAD MD5 hashes (numpwads)
string X Server Website address
int X Teamplay/CTF score limit
byte (boolean) X Blue team?
int X Blue score (if team enabled)
byte (boolean) X Red team?
int X Red score (if team enabled)
byte (boolean) X Gold team?
int X Gold score (if team enabled)
short X Protocol version (e.g. 63)

Additional Notes

  • Token is unnecessary for a launcher I think.
  • First PWAD is always the IWAD
  • Game types are: 0 = COOP, 1 = Deathmatch, 2 = Deathmatch 2.0
  • Skill levels are: 0 = ITYTD, 1 = HNTR, 2 = HMP, 3 = UV, 4 = NM (Acronyms).
  • Player teams are: 0 = None, 1 = Blue, 2 = Red, 3 = Gold
  • If CTF is enabled, Teamplay will be enabled and deathmatch (2.0?).
  • If Teamplay is enabled, then deathmatch (2.0?) will be too.
  • Scorelimit, team scores and player teams (excluding team 0) only appear if Teamplay/CTF is enabled.

Possible Future Protocol Improvements

All

  • Dedicated Odamex Query/Response values (rather than old csdoom ones)
  • Proper versioning, with possible subversion number.
  • Container (header based) protocol which would contain: Magic Tag, Size, Version (see above) and the data, this would allow features to be added in any order in 1 packet without breaking it, so if the launcher/server can't understand the magic value, it'll bypass it, via jumping past the entire size of the unknown header to the next one.
  • Packets will have a size, to indicate their boundary, including a null termination
  • Strings will have a size value, including the null termination.
  • Strings will be UTF-8 encoded. (Unicode)

External Links

  • None at the moment.