This is unoffical documentation of the network and file protocols used by Artemis Spaceship Bridge Simulator. No official documentation exists, so the information in this document has been obtained through community reverse-engineering efforts. There will be parts of the protocols that are not completely documented because their purpose has not been determined, and some parts may not be accurate. Contributions to this documentation are welcome.
The Artemis protocols use the following data types:
These types can be combined in structs or arrays.
All multi-byte data types are represented in
little-endian
order (least-significant byte first). Numeric literals in this documentation, in order
to follow the existing convention for many programming languages, are prefixed with
0x
and are written in big-endian order. For example, the four bytes that
begin every Artemis packet are ef be ad de
; represented as an int, this
is 0xdeadbeef
.
Integral types (byte, short, int) use two's complement representation in binary. Floats use IEEE 754 binary32 format.
A bit field is one or more bytes that encodes a series of on/off switches. Each bit in the binary representation of each byte in the field represents a single switch. In this documentation, an individual bit in a bit field is represented with the notation “bit {byte}.{bit}”, where the byte and bit values are one-based, and the bits are counted in little-endian order (least-significant bits first).
The most common use for a bit field is to declare which properties are defined
in a struct. Each bit represents a property, with 1
indicating that the
property is defined, and 0
meaning it is undefined. When sending updates
to clients, the Artemis server typically omits properties which are unchanged since
the last update; these properties will be undefined when the updated struct is
transmitted.
A single-byte bit field with the value 0x42
is represented in
little-endian binary as 01000010
. Bits 1.2 and 1.7 are on, the rest are
off.
Boolean values are simply expressed as an integer value 0 (false) or 1 (true). This value may be transmitted as a byte, short or int. In this documentation, a field is considered to be a boolean if all the following conditions are met:
Strings are represented by an int giving the length of the string in characters,
followed by the string itself encoded in
UTF-16LE.
Because UTF-16 encodes each character in two bytes, the number of bytes to read after
the length value is the number of characters times two. Strings are null-terminated
(0x0000
), and the length value includes the null. Under normal
circumstances, the null character would be the last two bytes read for the string; if
the null character occurs earlier, the remaining bytes are meaningless and should be
discarded. Zero-length strings are not allowed. For brevity's sake, all values denoted
as strings in this documentation are presumed to follow this format, and the string
length value will not be documented separately.
To interpret the byte sequence 04 00 00 00 48 00 69 00 21 00 00 00
as a
string, you would first read an int (4 bytes) to learn the string's length:
04 00 00 00
, which is four characters. In UTF-16, this is eight bytes, so
you'd then read eight bytes from the stream: 48 00 69 00 21 00 00 00
.
Decoded, this is H
, i
, !
and null
,
which terminates the string. Thus, the byte sequence represents the string "Hi!"
Arrays consist of an ordered list of values. These values can be primitive types, strings, structs or other arrays. There are two basic kinds of arrays: delimited and undelimited. Delimited arrays are typically used in circumstances where the exact number of elements in the array is not known in advance. Elements are transmitted one after the other until a particular byte is encountered instead of more data. With undelimited arrays, either the exact size or exact number of elements is known, so no delimiter is needed. Instead, parsing continues until the desired number of elements is read, or all the bytes that make up the array are consumed.
Structs are complex types composed of primitive types, strings, arrays or other
structs. These properties are always specified in a particular defined order, so that
it is unneccessary to declare each property's name when reading or writing a struct.
There are two type of structs: static structs and bit field structs. A static struct
always transmits all of its properties. A bit field struct has a bit field as its
first property. Each bit in the field corresponds to one of the remaining properties
in the struct. If a bit is 1
, that property is defined; if it's
0
, it is undefined and is omitted from the struct. When the Artemis
server sends game object updates, it will typically use bit field structs to only send
properties which have changed and leave the rest undefined; this reduces the payload
size for update packets.
When Artemis needs to refer to an item from a static list (enumeration), it will use a predefined numeric value to represent it. This section documents these enumerations.
0x00 |
Normal |
0x01 |
Red Alert |
0x00 |
Play |
0x01 |
Dismiss |
0x00 |
unused |
0x01 |
playing |
0x02 |
incoming |
0x00 |
A |
0x01 |
B |
0x02 |
C |
0x03 |
D |
0x04 |
E |
To players:
0x00 |
Yes. |
0x01 |
No. |
0x02 |
Help! |
0x03 |
Greetings. |
0x04 |
Die! |
0x05 |
We're leaving the sector. Bye. |
0x06 |
Ready to go. |
0x07 |
Please follow us. |
0x08 |
We'll follow you. |
0x09 |
We're badly damaged. |
0x0a |
We're headed back to the station. |
0x0b |
Sorry, please disregard. |
To enemies:
0x00 |
Will you surrender? |
0x01 |
Taunt #1 (varies by race) |
0x02 |
Taunt #2 (varies by race) |
0x03 |
Taunt #3 (varies by race) |
0x00 |
Prepare Docking |
0x01 |
Report Status |
0x02 |
Build Homing |
0x03 |
Build Nukes |
0x04 |
Build Mines |
0x05 |
Build Emps |
0x06 |
Build Pshocks |
To other ships:
0x00 |
Report status |
0x01 |
Turn to heading 0 |
0x02 |
Turn to heading 90 |
0x03 |
Turn to heading 180 |
0x04 |
Turn to heading 270 |
0x05 |
Turn 10 degrees to port |
0x06 |
Turn 10 degrees to starboard |
0x07 |
Attack nearest enemy |
0x08 |
Proceed to your destination |
0x09 |
Go defend [target] |
0x0a |
unused |
0x0b |
unused |
0x0c |
unused |
0x0d |
unused |
0x0e |
unused |
0x0f |
Turn 25 degrees to port |
0x10 |
Turn 25 degrees to starboard |
0x00 |
Player |
0x01 |
Enemy |
0x02 |
Station |
0x03 |
Other |
0x01 |
Server |
0x02 |
Client |
0x00 |
Available |
0x01 |
Yours |
0x02 |
Unavailable |
< v2.1 | ≥ v2.1, < v2.3 | ≥ v2.3 | |
---|---|---|---|
0x00 |
main screen | main screen | main screen |
0x01 |
helm | helm | helm |
0x02 |
weapons | weapons | weapons |
0x03 |
engineering | engineering | engineering |
0x04 |
science | science | science |
0x05 |
communications | communications | communications |
0x06 |
observer | data | fighter |
0x07 |
captain's map | observer | data |
0x08 |
game master | captain's map | observer |
0x09 |
unused | game master | captain's map |
0x0a |
unused | unused | game master |
0x00 |
Classic Monster |
0x01 |
Whale |
0x02 |
Shark |
0x03 |
Dragon |
0x04 |
Piranha |
0x05 |
Charybdis |
0x06 |
Insect |
0x07 |
Wreck |
0x00 |
Warp |
0x01 |
Jump |
Note: Special abilities can stack, in which case the values are ORed together. For
example, cloak and warp would be 0x14
. A ship with no special abilities
would have a special ability value of 0x00
.
Special abilities used to be called
Flag | Internal name | Alt name | Description |
---|---|---|---|
0x0001 | ELITE_INVIS_TO_MAIN_SCREEN | Stealth | Cannot be seen on main screen |
0x0002 | ELITE_INVIS_TO_TACTICAL | LowVis | Cannot be seen on tactical map |
0x0004 | ELITE_CLOAKING | Cloak | Can become completely invisible |
0x0008 | ELITE_HET | HET | ? |
0x0010 | ELITE_WARP | Warp | ? |
0x0020 | ELITE_TELEPORT | Teleport | ? |
0x0040 | ELITE_TRACTOR_BEAM | Tractor | Can lock player ships in, preventing them from escaping |
0x0080 | ELITE_DRONE_LAUNCHER | Drones | Can launch drones |
0x0100 | ELITE_ANTI_MINE_BEAMS | Anti-mines | ? |
0x0200 | ELITE_ANTI_TORP_BEAMS | Anti-torp | ? |
0x0400 | ELITE_ANTI_SHIELD | Shield-drain | Can drain the energy of player ship shields |
0x0800 | ELITE_? | ShldVamp | Can steal energy from player ship shields (unconfirmed) |
< v2.1 | ≥ v2.1 | |
---|---|---|
0x00 |
siege | siege |
0x01 |
single front | single front |
0x02 |
double front | double front |
0x03 |
unused | deep strike |
0x04 |
unused | peacetime |
0x05 |
unused | border war |
0x00 |
Forward |
0x01 |
Port |
0x02 |
Starboard |
0x03 |
Aft |
0x04 |
Tactical |
0x05 |
Long Range |
0x06 |
Status |
< v2.1.5 | ≥ v2.1.5 | |
---|---|---|
0x00 |
end of ObjectUpdatePacket | end of ObjectUpdatePacket |
0x01 |
player ship | player ship |
0x02 |
weapons console | weapons console |
0x03 |
engineering console | engineering console |
0x04 |
NPC ship (enemy or civilian) | player ship upgrades |
0x05 |
base | NPC ship (enemy or civilian) |
0x06 |
mine | base |
0x07 |
anomaly | mine |
0x08 |
unused | anomaly |
0x09 |
nebula | unused |
0x0a |
torpedo | nebula |
0x0b |
black hole | torpedo |
0x0c |
asteroid | black hole |
0x0d |
generic mesh | asteroid |
0x0e |
creature | generic mesh |
0x0f |
whale | creature |
0x10 |
drone | drone |
< v2.1.5 | ≥ v2.1.5 | |
---|---|---|
0x00 |
homing missile | homing missile |
0x01 |
nuke | nuke | 0x02 |
mine | mine |
0x03 |
EMP | EMP |
0x04 |
unused | plasma shock |
0x00 |
First Person |
0x01 |
Third Person |
0x00 |
Beams |
0x01 |
Torpedoes |
0x02 |
Sensors |
0x03 |
Maneuvering |
0x04 |
Impulse |
0x05 |
Warp Drive |
0x06 |
Fore Shields |
0x07 |
Aft Shields |
0x00 |
Auto |
0x01 |
Manual |
0x00 |
Unloaded |
0x01 |
Loaded |
0x02 |
Loading |
0x03 |
Unloading |
New as of v2.1.5. Upgrades marked with (*) can be activated by client consoles, meaning they can occur in the ActivateUpgrade packet.
Index | In-game name | Type | Description |
---|---|---|---|
0x00 * | Infusion P-Coils | Engine Boost | 5 Minute 10% Impulse and Warp Speed Boost |
0x01 * | Hydrogen Ram | Maneuver Boost | 5 Minute 10% Turn Speed Boost |
0x02 * | Tauron Focusers | Weapons Boost | 5 Minute 10% Beam and Reload Speed Boost |
0x03 * | Carapaction Coils | Shield Boost | 5 Minute 10% Shield Recharge Boost |
0x04 * | Polyphasic Capacitors | Energy Boost | 5 Minute 10% Energy Recharge Boost |
0x05 * | Coolant Reserves | Heat Reduction | 5 Minute 10% Faster Heat Reduction |
0x06 * | Lateral Array | Scanner Boost | 5 Minute Target Scan Triple Speed |
0x07 * | ECM Starpulse | Jammer Boost | 5 Minute Enemy Cannot Lock |
0x08 * | Double Agent | Auto-Surrender | Can force one ship to auto surrender |
0x09 | Wartime Production | Prod Boost | 10% (min +1) boost to all starting base munitions |
0x0a | Infusion P-Coils PERM | Engine Refit | Permanent 10% Impulse and Warp Speed Boost |
0x0b | Protonic Verniers | Maneuver Refit | Permanent 10% Turn Speed Boost |
0x0c | Tauron Focusers PERM | Weapons Refit | Permanent 10% Reload and Beam Speed |
0x0d | Regenerative Pau-Grids | Shield Refit | Permanent 10% Shield Recharge Speed |
0x0e | Veteran DamCon Teams | Faster DamCon | Damcon teams move/repair 10% faster |
0x0f | Cetrocite Heatsinks | Heatsink Refit | Heat builds 10% slower |
0x10 | Tachyon Scanners | Scanner Refit | Permanent 10% Scan Speed Boost |
0x11 | Gridscan Overload | Sensor Refit | Permanent 10% Range Booster |
0x12 | Override Authorization | Improved Prod | All bases produce 10% faster |
0x13 | Resupply Imperatives | Mission Enhance | 10% More missions |
0x14 | Patrol Group | Allied Combat | Additional TSN Escort Ship in-sector |
0x15 | Fast Supply | Allied Supply | Additional TSN Cargo Ship in-sector |
0x16 | Vanguard Refit | Improved Console | Perm 10% Boost to Impulse, Warp, and Turn Speed |
0x17 | Vanguard Refit | Improved Console | Perm 10% Boost to Beam, Shield and Reload Speeds |
0x18 | Vanguard Refit | Improved Console | Perm 10% Boost to Scan speed and Sensor Range |
0x19 | Vanguard Refit | Improved Console | Perm 10% Boost to Station production |
0x1a | Vanguard Refit | Improved Console | Perm 10% Boost to all Engineering Systems |
0x1b | Vanguard Refit | Systems Overhaul | Permanent 10% Boost to all Ship Systems |
New as of v2.1.5.
Index | Internal name | Known names |
---|---|---|
0x00 | ITEMTYPE_ENERGY | Anomaly / HiDens Power Cell |
0x01 | ITEMTYPE_RESTORE_DAMCON | Vigoranium Nodule |
0x02 | ITEMTYPE_HEAT_BUFF | Cetrocite Crystal |
0x03 | ITEMTYPE_SCAN_BUFF | Lateral Array |
0x04 | ITEMTYPE_WEAP_BUFF | Tauron Focusers |
0x05 | ITEMTYPE_SPEED_BUFF | Infusion P-Coils |
0x06 | ITEMTYPE_SHIELD_BUFF | Carapaction Coils |
0x07 | ITEMTYPE_COMM_BUFF | Secret code case / Double agent |
Artemis packets have two parts: the preamble and the payload.
The preamble consists of metadata that describes what kind packet it is and how long it is. The information in the preamble is needed in order to interpret the payload. The preamble consists of the following parts:
The first four bytes constitute a header which identifies the packet as an Artemis
packet. This value should always be 0xdeadbeef
.
Gives the total length of the packet in bytes, including both the preamble and the payload.
A connection type enumeration value indicating whether the packet originates from the server or the client.
This value is always 0x00
.
The number of bytes following this field in the packet. This is the length of the packet type field (4) plus the length of the payload, or the length of the entire packet minus 20.
This value identifies the type of this packet. Refer to the packet types table to find the values that correspond to the various packet types. Note that many packets also have a subtype value; for those packets, the subtype will be the first value transmitted in the payload.
The remaining bytes in the packet after the preamble constitute the payload. Its format will vary depending on the packet type. Refer to the next section to see what packet types exist and the formats of their payloads.
The table below lists the known packet types. The type names are derived from the class names for the packets in ArtClientLib.
Name | Origin | Type | Subtype(s) |
---|
0x0351a5ac
:0x03
[from client]This packet has not been observed, but has been hypothesized to exist based on the numeric range of the subtype. Nothing concrete is known about this packet type at this point, or even if it exists.
Always 0x03
.
0x69cc01d9
:0x01
[from client]This packet has not been observed, but has been hypothesized to exist based on the numeric range of the subtype. Nothing concrete is known about this packet type at this point, or even if it exists.
Always 0x01
.
0xf754c8fe
:0x02
[from server]This packet has not been observed, but has been hypothesized to exist based on the numeric range of the subtype. Nothing concrete is known about this packet type at this point, or even if it exists.
Always 0x02
.
0xf754c8fe
:0x0e
[from server]This packet has not been observed, but has been hypothesized to exist based on the numeric range of the subtype. Nothing concrete is known about this packet type at this point, or even if it exists.
Always 0x0e
.
0xf754c8fe
:0x16
[from server]This packet has not been observed, but has been hypothesized to exist based on the numeric range of the subtype. Nothing concrete is known about this packet type at this point, or even if it exists.
Always 0x16
.
0x0351a5ac
:0x07
[from client]
Always 0x07
.
0x4c821d3c
:0x05
[from client]This packet type has been observed, and is known to exist, but its function is as of yet completely unknown. All examples so far have seen was sent from Helm to Server.
Always 0x05
.
So far, only 0x00000000 has been observed.
0x4c821d3c
:0x06
[from client]This packet type has been observed, and is known to exist, but its function is as of yet completely unknown. All examples so far have seen was sent from Helm to Server.
Always 0x06
.
So far, only 0x00000000 has been observed.
0x4c821d3c
:0x1e
[from client]
Always 0x1e
.
0xf754c8fe
:0x01
[from server]This packet type has been confirmed to exist. Every example so far has an empty payload.
Always 0x01
.
0xf754c8fe
:0x07
[from server]This packet type has been observed, and its payload structure is believed to be understood. However, its function has not determined with certainty. Contains three floats which seem to correspond to map coordinates of ships with special abilities. Could relate to cloak/decloak graphical effects.
Always 0x07
.
0xf754c8fe
:0x08
[from server]This packet type has been observed, and its payload structure is believed to be understood. However, its function is as of yet completely unknown. Has been hypothesized as having some relation to SoundEffectPacket.
Always 0x08
.
Values of 0.0, 50.0 and 100.0 has been observed. It is unclear if other values have been observed.
0xf754c8fe
:0x13
[from server]This packet type has been observed, and its payload structure is believed to be understood. However, its function is as of yet completely unknown. Seems to happen immediately before DestroyObject(Mine, objID) or DestroyObject(Torpedo, objID). Speculated to have some relation to detonations.
Always 0x13
.
Only the value 7 has been observed so far. Unknown function or significance.
In the observed packets, the object ids correspond to a mixture of torpedos and mines, destroyed in the very next packet.
0x4c821d3c
:0x1c
[from client]This packet is sent whenever a client wishes to activate a ship upgrade from the "upgrades" menu.
Always 0x1c
.
The upgrade to activate. The game supports 28 different types of powerups, but only 8 are activated abilities. The others are all passive abilities, that are simple active on any ship that has them.
0xf754c8fe
:0x0f
[from server]Provides the list of available player ships.
Always 0x0f
.
A list of the eight available player ships.
0x6aadc57f
[from client]Instructs the server to play or dismiss an audio message.
The ID for the audio message. This is given by the IncomingAudioPacket.
The desired action to perform.
0xb83fd2c4
[from server]Notifies the client that a beam weapon has been fired.
A unique identifier for this beam. Each time a beam is fired, it gets its own ID.
In single-bridge games, this value has been observed as 0 for beams fired by enemies and 1 for beams fired by the player's ship.
Values of 1200 (for beams from the player's ship) and 100 (for enemy beams) have been observed.
All ships that can fire beams have beam ports. These are defined in vesselData.xml as <beam_port> entries. This value gives the index of the beam port on the originating ship that fired the beam. This value is zero-based; thus, vessels that only have one beam port will always give 0 for this value.
Indicates the type of object that fired the beam.
Indicates the type of object that was struck by the beam.
This field is present in v2.3 and later. A value of 0 has been observed.
The ID of the object that fired the beam.
The ID of the object that was struck by the beam.
The X coordinate (relative to the center of the target) of the impact point. This is used to determine the endpoint for the beam. A negative value means an impact on the target's starboard (right) side; a positive value means an impact on the target's port (left) side.
The Y coordinate (relative to the center of the target) of the impact point. This is used to determine the endpoint for the beam. A negative value means an impact on the target's ventral (bottom) side; a positive value means an impact on the target's dorsal (top) side.
The Z coordinate (relative to the center of the target) of the impact point. This is used to determine the endpoint for the beam. A negative value means an impact on the target's aft (rear) side; a positive value means an impact on the target's forward (front) side.
Indicates whether the beam was auto- or manually-fired.
0x4c821d3c
:0x11
[from client]Notifies the server that a new target has been selected on the captain's map.
Always 0x11
.
The object ID for the new target, or 1 if the target has been cleared.
0x4c821d3c
:0x1b
[from client]Causes the ship to climb or dive. This differs from HelmSetPitchPacket in that it indicates a direction in which to change the ship's current pitch, rather than setting a precise pitch value. The circumstances in which one type of packet might be sent versus the other are not fully understood at this time.
Always 0x1b
.
Indicates the change in the ship's direction: 0x00000001 (1) for down, 0xffffffff (-1) for up. For example, if the ship is diving when the instruction to go up is received, the ship will level out. If a second up command is received, the ship will start climbing.
0xd672c35f
[from server]Contains a single incoming text message to display at the COMMS station.
Indicates the channel on which the message was received. Values range from 0x00 to 0x08. In the stock client, this affects the message's background color; the lower the channel number, the more red the background color. While this would seem to indicate priority, in practice, the channel number doesn't seem to correlate with message importance. Below is a list of message types received on each channel; note that this list may be incomplete and custom scenarios may send messages on any channel: 0x00 = Enemy taunts 0x01 = ? 0x02 = ? 0x03 = Base destroyed 0x04 = Base is under attack, docking complete, ship refuses orders 0x05 = Base acknowledges build order or docking request 0x06 = Ship accepts orders, base status response, ordnance built notice, GM message 0x07 = Mission notification, mission transfer complete 0x08 = Messages sent from player ships
The name of the entity that sent the message. Note that this does not necessarily correspond to the exact name of that entity. This field appears to always at least start with the name of the originating ship or station in non-scripted missions, but may have additional text afterward (e.g. “DS3 TSN Base”). Custom missions could have any string in this field.
The contents of the incoming message. The carat symbol (^) in the message indicates a line break.
0x574c4c4b
[from client]Sends a COMMs message to the server.
The type of target for the message.
ID of the object that is to receive the message.
A value that indicates what message is to be transmitted. The interpretation of the value depends on the COMM target type.
The ID of the object to be targeted by the message. Currently, the only message that accepts a target is “Other ship: Go defend [target].” This value will be ignored if the message cannot support a target, but must still be provided; the value 0x00730078 has been observed in this case, but it is unknown why.
Possibly reserved for a second message argument. It is always ignored but must still be provided. The value of 0x004f005e has been observed for this field, but it is unknown why.
0x19c6e2d4
[from server]Indicates that a change has occurred in the availability status of one or more bridge consoles.
The number of the ship whose consoles are being described. Before v2.3.0, this value was one-based, so by default the ship identified by 0x01 was Artemis. As of v2.3.0 it is now zero-based.
This array contains one element for each possible console, with the availability status of each console represented with a single byte. The consoles are iterated in the order given by the console type enumeration. Note that the helm, weapons, engineering, and game master stations permit only one client to claim them. Once they've been claimed, their status will be reported as unavailable to other clients. All other stations will remain available to other clients when claimed.
0x69cc01d9
:0x03
[from client]Converts a homing torpedo to energy or vice versa.
Always 0x03
.
Indicates whether we are converting a torpedo to energy (0.0, 0x00000000) or energy to a torpedo (1.0, 0x3f800000). Why this is expressed as a float when a byte seems like it would be more appropriate is unknown.
padding, because this packet is of type "valueFourInts"
padding, because this packet is of type "valueFourInts"
padding, because this packet is of type "valueFourInts"
0xcc5a3e30
[from server]Notifies the client that an object has been removed from play.
Indicates the type of object being destroyed.
The ID of the object being destroyed.
0xf754c8fe
:0x00
[from server]In earlier versions, sent when the simulation starts, but this appears to have been discontinued as of v2.1.1. Starting in v2.3, this packet indicates that an object was destroyed.
Always 0x00
.
The type of object destroyed.
The ID of the object destroyed.
0x3de66711
[from server]Informs clients of the difficulty level when starting or connecting to a game.
The difficulty level (a value from 1 to 11).
A value indicating the type of game. This applies only to solo and co- op games; the field is present but its value is undefined for PvP and scripted games.
0xf754c8fe
:0x10
[from server]Sends DMX messages. This packet is only sent to main screen consoles for ships other than the first.
Always 0x10
.
The DMX flag name.
The DMX flag's current state.
0xf754c8fe
:0x0b
[from server]Informs the client of changes to DAMCON team autonomy status. Triggered by the "Autonomous" button in the engineering console.
Always 0x0b
.
Whether DAMCON teams are directed autonomously or not.
0x077e9f3c
[from server]Updates damage to the various system grids on the ship and DAMCON team locations and status.
Requested: This field is false on normal engineering update from the server, but will be set to 1 when in response to the RequestEngGridUpdate packet.
This array contains information on all system nodes
This array contains information on all DAMCON teams
0x4c821d3c
:0x19
[from client]Sent from the engineering station, to request a full update for all values. This causes the server to send a full update, instead of the normal update type where only changes are sent.
Always 0x19
.
Always 0.
0x69cc01d9
:0x04
[from client]Directs a DAMCON team to go to a particular grid location on the ship.
Always 0x04
.
The number assigned to the team (0 to 2 inclusive).
The X coordinate of the grid location that is the team's destination.
The Y coordinate of the grid location that is the team's destination.
The Z coordinate of the grid location that is the team's destination.
0x4c821d3c
:0x0c
[from client]Notifies the server that DAMCON team autonomy has been togged on/off.
Always 0x0c
.
Indicates whether DAMCON team autonomy is on or off.
0x69cc01d9
:0x00
[from client]Sets the amount of coolant to be allocated to a system.
Always 0x00
.
The system whose coolant level is being adjusted.
The number of coolant units to allocate to the system (0 to 8 inclusive).
padding, because this packet is of type "valueFourInts"
padding, because this packet is of type "valueFourInts"
0x0351a5ac
:0x04
[from client]Sets the amount of energy to be allocated to a system.
Always 0x04
.
The amount of energy to allocate to the system. This value can range from 0.0 to 1.0 inclusive, which in the stock UI corresponds to 0% to 300%. Therefore, the default energy allocation of 100% would be represented as 0.333....
The system whose coolant level is being adjusted.
0x9ad1f23b
[from server]Updates the client of the current status of the ship's fighter bays.
The payload consists of an array of structs, each one describing a single fighter, and terminated with 0x00000000.
0x4c821d3c
:0x1d
[from client]Notifies the server that a fighter is being launched. The server will send back a FighterLaunchedPacket in response.
Always 0x1d
.
The ID of the fighter, as shown in FighterBayStatusPacket.
0xf754c8fe
:0x17
[from server]Notifies the client that a fighter was just launched.
Always 0x17
.
The ID of the fighter, as shown in FighterBayStatusPacket.
0xc2bee72e
[from client]Notifies the server that the weapons officer wants to manually fire beam weapons.
The ID of the ship or entity at which to fire.
The X coordinate at which to fire, relative to the center of the target ship.
The Y coordinate at which to fire, relative to the center of the target ship.
The Z coordinate at which to fire, relative to the center of the target ship.
0x4c821d3c
:0x08
[from client]Notifies the server that the weapons officer wants to fire whatever's loaded in a certain tube.
Always 0x08
.
The index number of the tube to fire.
0x26faacb9
:0x63
[from server]Sent by the server to the game master console to provide instructions to be displayed on request.
Always 0x63
.
A title to display above the instructions.
The body content for the help screen.
0x809305a7
:0x01
[from client]New as of v2.4.0. A packet sent by the game master console to the server which causes a message to be displayed on a client.
Always 0x01
.
FIXME: perhaps ship_index?
If this value is 0x00, the message is received by the communications officer as a normal COMM message. Otherwise, it is sent as a popup message at a particular console type. The console that receives the message is determined by subtracting 1 from the value; the result then matches the values for the console type enumeration.
The name of the message's sender. This can be any arbitrary string; it doesn't have to match the name of an existing object.
The message to send.
0x0351a5ac
:0x06
[from client]Notifies the server that a new target has been selected on the game master's map.
Always 0x06
.
The coordinate of the selected location on the Z axis.
Seems to always be `0x00000000`.
The coordinate of the selected location on the X axis.
0x4c821d3c
:0x12
[from client]Notifies the server that a new target has been selected on the game master's map.
Always 0x12
.
ID of the selected object.
0xf754c8fe
:0x0a
[from server]Contains a message to be displayed on the screen. The stock client displays the message in a “popup” box in the lower-right corner.
Always 0x0a
.
The message to display.
0xf754c8fe
:0x06
[from server]Informs the client that the game is over. Transmitted when the "End Game" button on the statistics page is clicked.
Always 0x06
.
0xf754c8fe
:0x14
[from server]Provides the reason why the game ended.
Always 0x14
.
Text describing why the game ended. Each string is one line.
0xf754c8fe
:0x15
[from server]Provides endgame statistics.
Always 0x15
.
Stats are presented in vertical columns; each packet contains one column of stats data. This fields is the index for this column of data. In practice, there are only two possible values: 0 and 1.
The remaining bytes in the packet are an array, where each element constitutes a row in the stats column. The last element is followed by 0xce.
0xf5821226
[from server]
0x0351a5ac
:0x05
[from client]Initiates a jump. Note that the stock client molly-guards jumps, asking for confirmation from helm. This packet isn't sent until helm confirms the jump.
Always 0x05
.
The direction to jump, expressed as a value between 0.0 and 1.0 inclusive. To compute this value, take the desired bearing in degrees and divide by 360.
The distance to jump, expressed as a value between 0.0 and 1.0 inclusive. To compute this value, take the desired distance in μls and divide by 50 (the maximum jump distance).
0x4c821d3c
:0x07
[from client]Request docking with the nearest station, or, in the case of a fighter, with its mothership.
Always 0x07
.
Always 0x00.
0x0351a5ac
:0x00
[from client]Sets the throttle for impulse engines.
Always 0x00
.
Any value between 0.0 and 1.0 inclusive, where 0.0 is no throttle and 1.0 is full throttle. Actual velocity will depend on the ship's maximum velocity and the power allocated to impulse by engineering.
0x0351a5ac
:0x02
[from client]Sets the desired pitch for the player ship. This differs from ClimbDivePacket in that it sets a precise pitch value for the ship instead of just indicating a direction to change pitch. The circumstances in which one type of packet might be sent versus the other are not fully understood at this time.
Always 0x02
.
Any value between -1.0 and 1.0 inclusive, where 0.0 is level, -1.0 is a hard climb, and 1.0 is a hard dive.
0x0351a5ac
:0x01
[from client]Sets the position of the ship's "rudder", controlling its turn rate.
Always 0x01
.
Any value between 0.0 and 1.0 inclusive, where 0.0 is hard to port (left), 0.5 is rudder amidships (straight), and 1.0 is a hard to starboard (right). Actual turn rate will depend on the ship's maximum turn rate and the power allocated to maneuvering by engineering.
0x4c821d3c
:0x00
[from client]Sets the ship's warp factor. Actual velocity will depend on the power allocated to warp by engineering.
Always 0x00
.
The desired warp factor, from 0 to 4 inclusive. Warp 0 means to drop out of warp and move on impulse only.
0x4c821d3c
:0x18
[from client]Toggles the impulse engines between forward and reverse drive.
Always 0x18
.
Always 0x00.
0xae88e058
[from server]Informs the client of incoming audio messages (used in custom scenarios).
The ID for this audio message.
“Incoming” means that the communications officer is to be notified that an audio message is available, and offered the option to play or dismiss it. “Playing” is given in response to the communications officer giving the instruction to play the message, and notifies them that the message is now being played by the main screen. In the stock client, this results in the “Play” button changing to “REPlay.” (sic)
Title of the incoming message. This should be displayed to the COMMs officer. (incoming mode only)
The filename for the audio clip. The client doesn't need to do anything with this string; as the audio is played by the server. (incoming mode only)
0xee665279
[from server]Contains intel about another ship. Intel on allied ships (and biomechs, for some reason) is sent right away. Intel for enemy ships is sent after undergoing a level 2 scan. Theoretically, the intel should only need to be sent once, but the game re-transmits known intel periodically.
The ID of the ship to which this intel pertains.
Values of 0 and 1 have been observed
The intel message about the ship. This is displayed to the science officer when selecting this ship.
0xf754c8fe
:0x0c
[from server]Notifies the client that a jump has started.
Always 0x0c
.
0xf754c8fe
:0x0d
[from server]Notifies the client that a jump has completed.
Always 0x0d
.
0xf754c8fe
:0x11
[from server]Sent to all consoles when key capture is enabled or disabled for any console.
Always 0x11
.
Whether this console should capture keystrokes or not. Note that because this packet is sent to all consoles when the capture status of any console is changed, a console may get a KeyCaptureTogglePacket telling it to do what it's already doing; this is normal.
0x4c821d3c
:0x14
[from client]Informs the server that the player at this console pressed a particular key. This is used for custom mission scripts to allow keystrokes to trigger events. This packet should only be sent when keystroke capture is enabled for the console in question. Keystroke capture is always enabled for the game master console; other consoles require the script to activate keystroke capture first.
Always 0x14
.
The code identifying the key that was pressed. Microsoft has a good reference page that documents the key codes. Many languages have constants for these values. For example: in Java, they are defined in the KeyEvent class.
0x69cc01d9
:0x02
[from client]Loads a tube with a particular type of ordnance.
Always 0x02
.
Indicates which tube is to be loaded.
The type of ordnance to load into the tube.
0x80803df9
[from server]Updates the status of one or more objects in the game world. Each type of object update has its own encoding within this package, which makes this packet both the single most important server packet type, as well as the most complicated one to implement.
Whereas other packet types that have many subtypes (for example, 0x4c821d3c) are documented for each subtype, that is not possible for this packet type, since it can contain more than one object update type in each packet.
Note: The official Artemis server always seems to send objects of only one type in a single packet. If other types of objects need to be updated, they'll be transmitted in separate packets. However, keep in mind that the protocol does not require this, so it might change in the future.
The payload consists of an array of object update
entries. Parsing continues in a loop until the end of
the packet is reached, or the object type byte is
0x00
. Note that the array may be empty.
Each entry in the array is structured as follows:
The type of object represented by this entry. All objects in the same array will
be of the same type. If you get 0x00
for this field, there are no
more objects in the array.
In earlier protocol versions, this property was transmitted as an int rather than a byte. At least version 2.1.1 and onwards use the single byte encoding, but it is not verified if version 2.1.1 is the first version to do so.
A unique identifier assigned to this object.
In order to minimize the amount of data that has to be transmitted, the server
typically only sends the properties that have changed instead of the entire
object every time. This bit field indicates which properties are included in the
update. Each bit represents a single property; if a bit is set to
1
, that property is included. The length of the bit field depends
the number of properties the object has.
The rest of the entry consists of the updated values for the properties indicated in the bit field.
For details about the properties of the various object types which may be included in the array entries, see the Object Properties section.
0xf754c8fe
:0x04
[from server]Sent by the server when the simulation is paused or resumed.
Always 0x04
.
True if the simulation is paused; false otherwise.
0xf754c8fe
:0x12
[from server]Sent by the server when the main viewscreen perspective has changed.
Always 0x12
.
The current main screen perspective.
0xf754c8fe
:0x05
[from server]Appears to be sent when the player ship is hit by enemy fire. Has been observed when fired upon by enemy beams. Information about this packet is still uncertain and the documentation for it should not be considered reliable at this time.
Always 0x05
.
Value of 1 observed.
Appears to have values of 1.0 or less for hits against shields, and values greater than 1.0 and less than or equal to 2.0 for hits that pass through the shields and strike the hull.
0x4c821d3c
:0x0f
[from client]Sent by the client when they click the "Ready" button to indicate that it is ready to join the game. The client must select at least one station before sending this packet. When a game ends, the stock client typically sends this packet again immediately, on the assumption that they will play again with the same console(s).
Always 0x0f
.
Always 0.
0x4c821d3c
:0x13
[from client]Starts a science scan.
Always 0x13
.
The object ID for the target to be scanned.
0x4c821d3c
:0x10
[from client]Notifies the server that a new target has been selected on the science map.
Always 0x10
.
The object ID for the new target, or 1 if the target has been cleared.
0x4c821d3c
:0x0b
[from client]Sets the beam frequency.
Always 0x0b
.
The new beam frequency.
0x4c821d3c
:0x0e
[from client]Sets whether or not this client will use a particular console. A single client may use multiple consoles, and some consoles allow multiple clients to use them. Clients should send SetShipPacket before sending this one.
Always 0x0e
.
The console whose status is being updated.
True if this client is using the indicated console, false otherwise.
0x4c821d3c
:0x01
[from client]Sets the view to display on the main screen.
Always 0x01
.
The view to display on the main screen.
0x4c821d3c
:0x0d
[from client]Sets which ship the client will be on. This should be sent before SetConsolePacket.
Always 0x0d
.
The index of the desired ship; valid values are 0 through 7 inclusive.
0x4c821d3c
:0x16
[from client]Sets the name, ship type and drive type for the currently-selected ship. (version 2.1.0 up to 2.3.0)
Always 0x16
.
0x4c821d3c
:0x17
[from client]Sets the name, ship type and drive type for the currently-selected ship. (version 2.4.0+)
Always 0x17
.
0x4c821d3c
:0x02
[from client]Notifies the server that a new target has been selected on the weapons console.
Always 0x02
.
The object ID for the new target, or 1 if the target has been cleared.
0xf754c8fe
:0x09
[from server]Sent to change the displayed skybox image on the client. The server will send this packet at the start of a mission. The server will also send it any time a custom script instructs it to do so, but instead of sending the skybox index specified by the script, it will always send <code>0x0a</code> instead. This may be a bug in the Artemis server.
Always 0x09
.
The number of the skybox image to load on the client. Under the Artemis install directory is an "art" folder; this folder contains a bunch of subfolders whose names start with "sb" followed by a two- digit decimal value. This value is the skybox ID, and each folder contains image files for a single skybox. The stock install of Artemis has skybox images for IDs 00 through 05 and 10 through 29. It is presumed but not yet confirmed that other skybox IDs will work if a corresponding folder is created and contains the appropriate files.
0xf754c8fe
:0x03
[from server]Causes the client to play a sound effect file.
Always 0x03
.
Path to the file to play the sound effect from, e.g "dat/enemy-explode.wav".
0x4c821d3c
:0x03
[from client]Informs the server that the auto beams setting has been toggled.
Always 0x03
.
Always 0.
0x4c821d3c
:0x1a
[from client]Toggles between first- and third-person perspective on the main screen.
Always 0x1a
.
Always 0.
0x4c821d3c
:0x0a
[from client]Toggles the ship's red alert status.
Always 0x0a
.
Always 0.
0x4c821d3c
:0x04
[from client]Toggles the shields up or down.
Always 0x04
.
Always 0.
0x4c821d3c
:0x09
[from client]Removes whatever ordnance is loaded in a tube.
Always 0x09
.
Index of the tube to unload.
0xe548e74a
[from server]Gives the server version number. This packet is sent immediately after the WelcomePacket
Unknown function, but has been observed to follow the cycle "ec f0 e8 d4 d8 dc e0 e4"
The version of Artemis running on the server. If the client doesn't support the given version, it should disconnect. This field is deprecated as of v2.1; it is still sent by the server, but client should ignore its value unless there are no more bytes after it in the packet.
These three int values constitute the major, minor and patch version numbers. For example, v2.1.1 will transmit 02000000 01000000 01000000 (interpreted 2 1 1) for this field. If the client doesn't support the given version, it should disconnect. The version specified in this field supersedes any specified in the legacy version field. It has been officially confirmed that the schema is <major>.<network>.<minor>. In other words, the 2 first digits should uniquely identify any protocol version.
0x6d04b3da
[from server]Indicates a successful connection to the Artemis server. This is the first packet sent upon connection.
Unlike all other strings in Artemis packets, this one is encoded in plain ASCII, so each character is one byte, not two. Also, the given length for the string does not include a terminating null. Currently, it says, "You have connected to Thom Robertson's Artemis Bridge Simulator. Please connect with an authorized game client."
This section documents the bit fields and properties for each of the object types. See ObjectUpdatePacket for how these objects are updated by the Artemis server.
New as of v.2.1.5. Previously, anomalies were handled by the “other” property structure.
Note that only the values 0x00 through 0x07 have been observed, as the built-in mission types do not put other upgrade types in anomaly pickups.
The name assigned to this base. In standard, non-custom scenarios, base names will be unique, but there is no guarantee that the same will be true in custom scenarios.
The current strength of the base's shields.
Bases only have one shield, but all shielded objects in Artemis are encoded with front and rear shields. This value is therefore meaningless and should be ignored.
The index of this base. Each base will have a unique index from 0 to (number of bases-1). In a standard solo game, DS1 is 0, DS2 is 1, etc.
The vessel type ID, as found in vesselData.xml.
The base's location along the X-axis.
The base's location along the Y-axis.
The base's location along the Z-axis.
Note that wrecks are also considered creatures, for some reason. This structure is new as of v2.1.5. Previously, the only type of creature was the classic space monster, which was handled by the “other” property structure, and space whales had their own structure.
The X coordinate of this creature.
The Y coordinate of this creature.
The Z coordinate of this creature.
The creature's name
The creature's current heading.
The creature's current pitch.
The creature's current roll.
The type of creature. FIXME: size?
Values observed range from approximately -0.01 to 53.7. Might be related to pitch/yaw.
Perhaps related to pitch/yaw.
Each byte of the field represents a category of values: Heat levels Energy allocations Coolant allocations
The bits in each byte represent the ship systems, in the order specified in the ship system enumeration. So for example, if the first bit field is 0x01, it means that this packet will contain a single heat level value (beams).
The heat level for each system, as a value between 0 (no heat) and 1 (maximum heat). Reaching maximum heat for a system will cause an explosion, which will damage a system node of that type and release some of the heat.
The energy allocation for each system, as a value between 0 (no energy allocated) and 1 (maximum possible energy allocation). In the UI, this is expressed as a percentage between 0% and 300%, so the nominal allocation level (100%) is represented by a value of 0.3333....
These are arbitrary 3D objects to display in the game world. Players and enemies don't interact with these objects; they are just decoration.
The object's location on the X axis.
The object's location on the Y axis.
The object's location on the Z axis.
The name of this object.
The name of the file containing the 3D mesh data.
The name of the file containing the texture to apply to the mesh. Note that this uses the same bit as the mesh name, and that bit 2.5 is unused.
Red color channel (bit 3.1, float)
Green color channel (bit 3.2, float)
Blue color channel (bit 3.3, float)
Front shields (bit 3.4, float)
Rear shields (bit 3.5, float)
Red color channel (bit 1.4, float)
Green color channel (bit 1.5, float)
Blue color channel (bit 1.6, float)
The ship's name.
Values range from 0.0 for all stop to 1.0 for full speed.
Values range from 0.0 for hard to port (left), to 1.0 for hard to starboard (right).
The ship's maximum possible speed at impulse.
The ship's maximum possible turning speed.
In single-bridge games, as well as multi-bridge co-op games this value will be true if the ship is hostile and false if it is friendly. In PvP and scripted games, this field is always true, regardless of whether the NPC is hostile or not.
The ID corresponding to the <vessel> entry in vesselData.xml that describes the vessel type for this ship.
True if this ship has surrendered; false otherwise.
The number of the fleet to which this ship belongs. For custom missions, this is specified in the mission file.
The elite abilites posessed by this ship. The value in this field is only meaningful if the ship's faction has the “elite” attribute, as specified in vesselData.xml. Other ships should ignore this value even if it is present, as they cannot have elite abilities.
The elite abilites posessed by this ship that are currently in use. As with the previous field, this field should be ignored if the ship can't have elite abilities, even if it is present.
This field appears to contain a different value for each side in the conflict. Ships with the same value will presumably be friendly to each other.
Values of 0.0 and -100000.0 have been observed.
Damage to various ship systems, in the order specified in the enumeration. A system with a damage value of 0.0 is undamaged; a higher value (up to 1.0) means the system is damaged. In the stock client, damaged systems on NPC vessels can be seen via the science console. Barring further damage or actions by a custom script, damage values gradually decrease as the ship is repaired, until they return to 0.0.
The ship's resistance to the five beam frequencies. Higher values indicate greater resistance to beams tuned to the corresponding frequency.
5 bytes before v2.3.0
This might be the ship targeted by the weapons console.
Current impulse power for this ship. Values range from 0.0 (all stop) to 1.0 (full speed) inclusive.
Values range from 0.0 to 1.0 inclusive, with 0.0 meaning hard to port (left), 0.5 meaning rudder amidships (straight), and 1.0 meaning hard to starboard (right).
The ship's location on the X axis.
The ship's location on the Y axis.
The ship's location on the Z axis.
(values still uncertain) Values range from -1.0 to 1.0 inclusive, where -1.0 means the port (left) side points straight “up” and 1.0 means it points straight “down.”
(values still uncertain) Values range from -1.0 to 1.0 inclusive, where -1.0 means straight “up” and 1.0 means straight “down.”
A value from pi to negative pi. A value of pi corresponds to a heading of 0° (or “north”). The ship turns to port (left) as the value decreases. A value of 0.0 corresponds to a heading of 180° (or “south”).
FIXME: copy pasta A value from pi to negative pi. A value of pi corresponds to a heading of 0° (or “north”). The ship turns to port (left) as the value decreases. A value of 0.0 corresponds to a heading of 180° (or “south”).
Current strength of forward shield. A value greater than 0.0 indicates that this shield is up, while a value of 0.0 or less means it's down. If enemy fire penetrates the shield, this value can go negative; it will climb back towards 0.0 as the shield recovers.
The maximum strength of the forward shield.
Current strength of rear shield. A value greater than 0.0 indicates that this shield is up, while a value of 0.0 or less means it's down. If enemy fire penetrates the shield, this value can go negative; it will climb back towards 0.0 as the shield recovers.
The maximum strength of the aft shield.
The ID of the base that most recently initiated docking with the ship. This field updates when a base's tractor beam latches onto the ship. Undocking does not change this field; to detect undocking, watch for the ship's impulse (bit 1.2) or warp factor (bit 1.7) fields to go above zero.
The view currently displayed on the ship's main screen.
The frequency to which the beams are currently tuned.
The total amount of coolant if a capital ship, or the number of missiles if a fighter.
The ID of the object selected by the science officer, or 1 if the selection was cleared.
The ID of the object selected by the captain, or 1 if the selection was cleared.
The type of drive system the ship has.
The ID of the object currently being scanned by the science officer.
A value from 0.0 to 1.0 inclusive indicating the current progress of the active science scan.
True if the impulse drive is in reverse; false otherwise.
Usually 0.0, though -1.0 has been observed.
0x02 has been observed.
0 has been observed.
The object ID of the associated capital ship, if this ship is a fighter. new as of v2.3.0
The accent color of the ship. new as of v2.4.0
new as of v2.4.0
New as of v2.1.5. Indicates how many of each upgrade the player ship has on board, which ones are active, and how many seconds are left of each type of activation. There are 28 upgrade types available, each of which are described in this packet type. First, every upgrade is described with an 8-bit boolean value. If this value is true, the upgrade is currently activated. Secondly, every upgrade is described with a i8 (signed 8-bit integer), that determines how many of that type of upgrade the ship has available. Finally, every upgrade is described with a u16, that determines how many more seconds the upgrade is active for.
The torpedo's location on the X axis.
The torpedo's location on the Y axis.
The torpedo's location on the Z axis.
Appears to range from -1.0 to 1.0.
The plasma shock torpedo type was added in v.2.1.5. It was inserted at bit 1.5, and all subsequent bits were shifted by one bit. Before this addition, the bit field was only three bytes long instead of four.
Unknown (bit 1.6, byte)
This array contains up to six float elements. Each element gives the (un)load time for the corresponding tube. This field should be ignored (even when present) if the tube's status is not loading or unloading.
This array contains up to six byte elements. Each element indicates the occupation status of each tube.
This array contains up to six byte elements. Each element indicates the type of ordnance in each tube. If the tube's status is unloaded, the tube is empty, and this field should be ignored even when present.
This type became obsolete starting v2.1.5, when whales were folded into the new creature object type.
Always “WHALE” in non-custom missions.
Values range from 0.0 to 1.0.
Values range up to 1.0. Lowest value seen so far is approximately 0.855, minimum might be 0.0.
Observed ranges have been from about 0.5 to 1.36.
The remaining object types (asteroids, black holes and mines) all use the same properties. Prior to v2.1.5, anomalies and space monsters also used this structure.
The object's name. In standard missions, this property is never used, but there may be named objects in custom missions.
Certain in-game events cause the transmission specific patterns of packets. This section documents some of these observed patterns:
0xf754c8fe
subtype=0x08
The layout of system nodes in a vessel is stored in an .snt file referenced by the vessel's entry in vesselData.xml. This section documents the file format used by these files.
A vessel's internal system grid is laid out in a 5 × 5 × 10 matrix: X (port to starboard), Y (dorsal to ventral), then Z (fore to aft). An .snt file contains 250 blocks of data, with each block representing one node in the system grid. The nodes are iterated first in the X axis, then Y, then Z. So the first ten nodes are (0,0,0) through (0,0,9), followed by (0,1,0) through (0,1,9), etc.
Each block is 32 bytes long. The first 12 bytes contain the node's position in the vessel's 3D coordinate system. (This is separate from its system grid coordinates.) The coordinates are stored as three floats: X, Y, then Z.
Next is an int value which describes what kind of node it is. A value from 0 to 7 indicates that the node contains vital equipment for one of the ship systems; you can tell which system by looking up the corresponding value in the ship system enumeration. A value of -1 indicates a hallway; it contains no ship systems but is still accessible to DAMCON teams. A value of -2 indicates an empty node; it contains no ship systems and is not accessible to DAMCON teams. This is typically for nodes that would fall outside the vessel's hull.
The remaining 16 bytes in the block appear to be reserved for future use.