game
na
Is sent by the server when the client has performed an action from a menu item (i.e create character, delete character, etc...)
na
na
na
na
na
na
na
na
na
na
na
na
na
Force a player model to change its exo-suit.
Force a player model to change its exo-suit.
Set all GUI elements and functional elements to be associated with that type of exo-suit.
Inventory and holster contents are discarded.
Due to the way armor is handled internally, a player of one faction may not spawn in the exo-suit of another faction.
That style of exo-suit is never available through this packet.
As MAX units do not get their weapon by default, all the MAX values produce the same faction-appropriate mechanized exo-suit body visually.
(The MAX weapons are supplied in subsequent packets.)
Mechanized Assault Subtypes:
0 - na
1 - AI MAX
2 - AV MAX
3 - AA MAX
the player
the type of exo-suit
the exo-suit subtype, if any
Dispatched by the server to manipulate the client's management of the Player object owned by the user as his "avatar."
The cycle of a player is generally Alive to Dead and Dead to Release and Release to RespawnTimer to Alive.
Dispatched by the server to manipulate the client's management of the Player object owned by the user as his "avatar."
The cycle of a player is generally Alive to Dead and Dead to Release and Release to RespawnTimer to Alive.
When deconstructing oneself, the user makes a jump between Alive and Release;
and, he may make a further jump from Release to Alive depending on spawning choices.
Being Alive is the most common state.
(Despite what anyone says.)
Being Dead is just a technical requirement to initialize the revive timer.
The player should be sufficiently "dead" by having his health points decreased to zero.
If the timer is reduced to zero, the player is sent back to their faction-appropriate sanctuary continent.
Release causes a "dead" player to have its character model converted into a backpack or a form of pastry.
This cancels the revival timer - the player may no longer be revived - and brings the user to the deployment map.
From the deployment map, the user may select a place where they may respawn a new character.
The options available form this spawn are not only related to the faction affinity of the bases compared to the user's player(s)
but also to the field faction as is provided in the packet.
If the player is converted to a state of Release while being alive, the deployment map is still displayed.
Their character model is not replaced by a backpack or pastry.
RespawnTimer is like Dead as it is just a formal distinction to cause the client to display a timer.
The state indicates that the player is being resurrected at a previously-selected location in the state Alive.
avatar's mortal relationship with the world;
the following timers are applicable during Death and RespawnTimer;
faction is applicable mainly during Release
total length of respawn countdown, in milliseconds
initial length of the respawn timer, in milliseconds
player's last position
spawn points available for this faction on redeployment map
na
Dispatched to the server when the player encounters something for the very first time in their campaign.
Dispatched to the server when the player encounters something for the very first time in their campaign.
For example, the first time the player rubs up against a game object with a yellow exclamation point.
For example, the first time the player draws a specific weapon.
When the first time events (FTE's) are received, battle experience is awarded.
Text information about the object will be displayed.
A certain itemized checkbox under the "Training" tab that corresponds is marked off.
The latter list indicates all "encounter-able" game objects for which a FTE exists.
These effects only happen once per character/campaign.
(The Motion Sensor will occasionally erroneously display the information window on repeat encounters.
No additional experience is given, though.)
FTE's are recorded in a great List of Strings in the middle of player ObjectCreateMessage data.
Tutorial complete events are enqueued nearby.
the player
the game object that triggers the event
na
the string name of the event
Report the state of the grenade throw animation for this player.
Report the state of the grenade throw animation for this player.
The default state is "held at side," though the client's avatar never has to announce this.
The throwing animation has a minor timing glitch.
Causing another player to raise his arm will always result in that arm being lowered a few seconds later.
This is as opposed to the client's avatar, who can seem to hold a grenade in the "prepare to throw" state indefinitely.
If the avatar looks away from a player whose grenade arm is up ("prepare to throw"), however, when they look back at the player,
his grenade arm will occasionally have been lowered ("held at side") again before it would normally be lowered.
A client will dispatch state 'Primed' and state 'Thrown' for the avatar's actions.
A client will only react temporarily for another character other than the avatar when the given a state 'Primed'.
If that internal state is not changed, however, that other character will not respond to any subsequent 'Primed' state.
(This may also be a glitch.)
States:
1 - prepare to throw (grenade held back over shoulder)
2 - throwing (grenade released overhand and then reset) (avatar only)
the player
the animation state
Change the state of the implant.
Change the state of the implant.
Spawn messages for certain implant-related events.
The implant Second Wind is technically an invalid ImplantType for this packet.
This owes to the unique activation trigger for that implant - a near-death experience of ~0HP.
the player
how to affect the implant or the slot
: from 0 to 2
: a value that depends on context from ImplantAction:
Add - 0-9 depending on the ImplantType
Remove - any valid value; field is not significant to this action
Initialization - 0 to revoke slot; 1 to allocate implant slot
Activation - 0 to deactivate implant; 1 to activate implant
UnlockMessage - 0-3 as an unlocked implant slot; display a message
OutOfStamina - lock implant; 0 to lock; 1 to unlock; display a message
ImplantType
Tell the server that the player is is jumping.
Tell the server that the player is is jumping.
This will allow it to coordinate animation with other clients.
During the jump, the avatar's "height" coordinate does change, as reported in PlayerStateMessageUpstream.
PlayerStateMessage, however, can depict another player with a proper jumping animation without the explicit coordinate change.
The server must probably account for the distance to the ground when passing along data somehow.
Exploration:
Is state ever not true?
true
na
na
na
na
na
na
na
na
player guid !
name of the item or vehicle name (ex : medkit, fury ...)
in seconds
NA - Seems to be false when it's for medkit, true for vehicles
A particular instruction in the rendering of this battleplan's diagram entry.
A particular instruction in the rendering of this battleplan's diagram entry.
the behavior of this stroke; a hint to the kind of stroke data stored, if at all, and how to use it or incorporate prior data
the data;
defaults to None
Inform the client how many battle experience points (BEP) the player currently has earned.
The amount of experience earned is an accumulating value.
Inform the client how many battle experience points (BEP) the player currently has earned.
The amount of experience earned is an accumulating value.
Whenever the server sends this packet, the value of this field is equal to the player's current total BEP.
Each packet updates to a higher BEP score and the client occasionally reports of the difference as an event message.
"You have been awarded x battle experience points."
Milestone notifications that occur due to BEP gain, e.g., rank progression, will trigger naturally as the client is updated.
It is possible to award more battle experience than is necessary to progress one's character to the highest battle rank.
(This must be accomplished in a single event packet.)
Only the most significant notifications will be displayed in that case.
If the BEP has been modified, there will be an extra three bits to indicate which message to display.
Messages:
0 - Normal
1 - Normal (repeat?)
2 - Support bonus ("due to support activity")
4 - Rabbit bonus ("+25% rabbit Bonus")
(Support message has priority over Rabbit message.)
Exploration:
msg = 1 probably does not do the same thing as mod = 0.
the player
the current total experience
modifies the awarded experience message
Share drawn images and words on the tactical map among a group of players.
Each packet usually contains a small portion of an image, herein called a "diagram."
BattleplanMessage packets are accumulative towards a full diagram.
Share drawn images and words on the tactical map among a group of players.
Each packet usually contains a small portion of an image, herein called a "diagram."
BattleplanMessage packets are accumulative towards a full diagram.
Moreover, rather than the player_name, each diagram is associated on a client by the char_id field.
Only squad leaders and platoon leaders can draw on the map and share with other players in their squad or platoon.
To start drawing, a would-be artist must have all clients who will receive their diagrams acknowledge a StartDrawing action.
The char_id with this StartDrawing will associate all diagrams submitted with the same char_id's portfolio.
Multiple portfolio definitions may exist on a client at a given time and each will manage their own diagrams.
When a given portfolio submits a StopDrawing action that is received, the previous diagrams associated with it will be cleared.
That char_id will no longer accept diagrams on that client.
Other portfolios will continue to accept diagrams as initialized.
When no portfolios are being accepted, the "Toggle -> Battleplan" button on that client's tactical map will be disabled.
When there is at least one portfolio accepted, the "Battleplan" button will be functional and can be toggled.
To construct line segments, chain StrokeTwo diagrams in the given packet entry.
Each defined point will act like a successive vertex in a chain of segments.
Any non-vertex entry in between entries, e.g., a change of line color, will break the chain of line segments.
For example:
RED-A-B-C will construct red lines segments A-B and B-C.
RED-A-B-GREEN-C will only construct a red line segement A-B.
RED-A-B-GREEN-C-D will construct a red line segement A-B and a green line segment C-D.
(Default line color, if none is declared specifically, is gray.)
To construct a message, define a point to act as the center baseline for the text.
The message will be written above and outwards from that point.
Messages do not carry properties over from line segments - they set their own color and do not have line thickness.
Any single portfolio may have only fifteen messages written to the tactical map at a time.
na;
same as in CharacterInfoMessage
the player who contributed this battle plan
on which continent the battle plan will be overlaid; can identify as "no zone" 0 when performing instructions not specific to drawing
a list of the itemized actions that will construct this plan or are used to modify the plan
Dispatched by the client after the current map has been fully loaded locally and its objects are ready to be initialized.
Dispatched by the client after the current map has been fully loaded locally and its objects are ready to be initialized.
This packet is a direct response to LoadMapMessage.
When the server receives the packet, for each object on that map, it sends the packets to the client:
- SetEmpireMessage
- HackMessage
- PlanetSideAttributeMessage
- ... and so forth
Afterwards, an avatar POV is declared and the remaining details about the said avatar are assigned.
A packet dispatched to maintain a manually-set respawn location.
The packet establishes the player's ability to spawn in an arbitrary location that is not a normal local option.
A packet dispatched to maintain a manually-set respawn location.
The packet establishes the player's ability to spawn in an arbitrary location that is not a normal local option.
This process is called "binding one's matrix."
In addition to player establishing the binding, the packet updates as conditions of the respawn location changes.
If logging is turned on, packets will display different messages depending on context.
The bind descriptor will be used to flavor the events chat message.
As long as the event is marked to be logged, when the packet is received, a message is displayed in the events window.
If the logged action is applicable, the matrixing sound effect will be played too.
Not displaying events is occasionally warranted for aesthetics.
The game will always note if this is your first time binding regardless of the state of this flag.
Bind Descriptors:
@amp_station
@ams
@comm_station (interlink facility?)
@comm_station_dsp (dropship center?)
@cryo_facility (biolab?)
@tech_plant
Exploration:
Find other bind descriptors.
the purpose of the packet
a text description of the respawn binding point
show the selection icon on the redeployment map
true, to report on bind point change visible in the events window; false, to render spawn change silently; some first time notifications will always display regardless of this flag
the kind of spawn request that will be made;
affects the type of icon displayed;
will coincide with the value of unk2 in SpawnRequestMessage when the spawn option is selected
the number of the zone in which to display this spawn option;
if zone_number is not the current zone, and the action is positive,
a small map of the alternate zone with selectable spawn point will become visible
na
coordinates for any displayed deployment map icon;
x and y determine the position
Dispatched by the server to promote a warp gate's broadcast functionality.
Changes the map name of a warp gate into "Broadcast"
and allow a given faction to access the gate's intercontinental transport functionality to/from that gate,
even if the gate is not properly owned.
Dispatched by the server to promote a warp gate's broadcast functionality.
Changes the map name of a warp gate into "Broadcast"
and allow a given faction to access the gate's intercontinental transport functionality to/from that gate,
even if the gate is not properly owned.
If an actual warp gate is not designated, nothing happens.
If not set, the map name of the warp gate will default to whatever is normally written on the map.
The map designation of geowarps is not affected by this packet.
the zone ordinal number
the warp gate map id
players belonging to the Terran Republic interact with this warp gate as a "broadcast gate"
players belonging to the New Conglomerate interact with this warp gate as a "broadcast gate"
players belonging to the Vanu Sovereignty interact with this warp gate as a "broadcast gate"
BuildingInfoUpdateMessage
Allow the user to report a bug they have found in the game.
Bug reports are prepended by the version of the client on which the player is encountering the issue.
Allow the user to report a bug they have found in the game.
Bug reports are prepended by the version of the client on which the player is encountering the issue.
The last delivered client by Sony Online Entertainment was 3.15.84 with date Dec 2 2009.
The path of bug reports submitted to the game's official server is not known.
the client's major version number
the client's minor version number
the date the client was compiled
the kind of bug that took place
whether the bug is repeatable
0 when "other location", 2 when "current location"
which zone the bug took place
the x y z location where the bug took place
a short explanation of the bug
a detailed explanation of the bug
Update the state of map asset for a client's specific building's state.
Update the state of map asset for a client's specific building's state.
The most common application of this packet is to synchronize map state during world login.
A "building" mainly constitutes any map-viewable structure that has properties or whose ownership can be asserted.
This packet is valid for all major facilities, field towers, warp gates, and some static environment elements.
Additional properties, if available, can be viewed by selecting the sphere of influence of a given building.
The combination of continent UID and building UID ensures that all buildings are uniquely-defined.
This packet can be applied on any continent and will affect the appropriate building on any other continent.
As the intercontinental map is always available, all map assets will publish real time updates to all players.
Map information configured by this packet is not obscured from any players, regardless of faction.
(Network state updates will be delayed for, and the type of compromise will not be specified to, defenders.)
Aside from the map-viewable aspects, a few properties set by this packet also have game world effects.
Additionally, though most parameters are treated as mandatory, not all buildings will be able to use those parameters.
A parameter that is not applicable for a given asset, e.g., NTU for a field tower, will be ignored.
A collision between some parameters can occur.
For example, if is_hacking is false, the other hacking fields are considered invalid.
If is_hacking is true but the hacking empire is also the owning empire, the is_hacking state is invalid.
Lattice benefits: (stackable)
00 - None
01 - Amp Station
02 - Dropship Center
04 - Bio Laboratory
08 - Interlink Facility
16 - Technology Plant
Cavern benefits: (stackable)
000 - None
004 - Speed Module
008 - Shield Module
016 - Vehicle Module
032 - Equipment Module
064 - Health Module
128 - Pain Module
the continent (zone)
the map id of this building from the MPO files
if the building has a silo, the amount of NTU in that silo; NTU is reported in multiples of 10%; valid for 0 (0%) to 10 (100%)
if the building can be hacked and will take time to convert, whether the building is being hacked
if the building is being hacked, the empire that is performing the hacking
if the building is being hacked, the amount of time remaining until the hack finishes/clears; recorded in milliseconds (ms)
the empire that owns the building currently
na; value != 0 causes the next field to be defined
na
if the building has a generator, the state of the generator
if the building has spawn tubes, whether at least one of the tubes is powered and operational
if the building is a capitol facility, whether the force dome is active
the benefits from other Lattice-linked bases does this building possess
cavern benefits; any non-zero value will cause the cavern module icon (yellow) to appear; proper module values cause the cavern module icon to render green; all benefits will report as due to a "Cavern Lock"
na
na
na
na; value != 8 causes the next field to be defined
na
if the building has spawn tubes, the (boosted) strength of its enemy pain field
if the building has a generator, the (boosted) strength of its enemy pain field
na
na
always the carrier vehicle
cargo vehicle that requested mounting during the mounting process; blank when the process is complete
cargo vehicle that requested mounting after the mounting process is complete; blank before the process is complete
cargo vehicle that was mounted after disembarking;
blank before disembark
blank before mounting request, when packet MountVehicleCargoMsg is received
cargo hold mount position;
common values are 1 for the lodestar and 15 for the dropship
cargo mount status
direction the cargo vehicle faces when stowed in the carrier cargo bay;
0 is "normal," front facing forward;
1 is "sideways," front facing the side of the carrier vehicle, e.g. router
MountVehicleCargoMsg
CargoStatus
Switch the set of shortcuts displayed on the HUD's hotbar.
The hotbar contains eight slots for user shortcuts - medkits, implants, and text macros.
Switch the set of shortcuts displayed on the HUD's hotbar.
The hotbar contains eight slots for user shortcuts - medkits, implants, and text macros.
Next to the first slot are up and down arrow buttons with a number.
By progressing through the options available from the arrows, eight sets of eight shortcut slots are revealed.
Which set is visible determines the effect of the respective binding keys (the Function keys) for the hotbar.
Each set is called a "bank," obviously.
This packet coordinates the bank number both as an upstream and as a downstream packet.
the player
the shortcut bank (zero-indexed); 0-7 are the valid banks
Is sent by the PlanetSide client on character selection completion.
Is sent by the PlanetSide world server when sending character selection screen state.
Is sent by the PlanetSide world server when sending character selection screen state. Provides metadata about a certain character for rendering purposes (zone background, etc). Acts as an array insert for the client character list. A blank displayed character is most likely caused by a mismatch between an ObjectCreateMessage GUID and the GUID from this message.
True when there are no more characters to give info on
Is sent by the PlanetSide client when selecting a character to play from the character selection menu.
Instructs client to display and/or process a chat message/command when sent server to client.
Instructs client to display and/or process a chat message/command when sent server to client. Instructs server to route and/or process a chat message/command when sent client to server.
the type of the chat message (CMT)
whether the contents contains wide characters or not. This is required because Java/Scala have one String type with a charset of UTF-16. Therefore, there is no way at runtime to determine the charset of String.
identifies the recipient of the message, such as in a tell (occasionally used as "sender" instead i.e. /note)
the textual contents of the message
only used when the message is of note type
Dispatched from a client when its user is controlling a secondary object whose state must be updated.
When ChildObjectStateMessage is being sent to the server, it replaces PlayerStateMessage.
Dispatched from a client when its user is controlling a secondary object whose state must be updated.
When ChildObjectStateMessage is being sent to the server, it replaces PlayerStateMessage.
The packet frequently gets hidden in a MultiPacket, though it is not functionally essential to do that.
Note the lack of position data.
The secondary object in question is updated in position through another means or is stationary.
The only concern is the direction the object is facing.
The angles are relative to the object's normal forward-facing and typically begin tracking at 0, 0 (forward-facing).
the object being manipulated (controlled)
the amount of pitch that affects orientation from forward facing (0)
the amount of yaw that affects orientation from forward-facing (0)
Cloud data.
The remaining fields should be divided between a "location" and a "velocity" as per debug output.
Cloud data.
The remaining fields should be divided between a "location" and a "velocity" as per debug output.
The values are probably paired.
The converted data, however, seems weird for the kind of information those fields would suggest.
the id of the cloud; zero-indexed counter (probably)
na;
the z-component is always 0.0f
na;
the z-component is always 0.0f
Is sent in response to the PlanetSide client in order to give server information on the world server.
Is sent in response to the PlanetSide client in order to give server information on the world server.
The name of the server to connect to
The IP or hostname of the server to connect to
The 16-bit port number to connect on
Create a dispatched game packet that instructs the client to update the user about continents that are conquered.
This generates the event message "The [empire] have captured [continent]."
If the continent_guid is not a valid zone, no message is displayed.
Create a dispatched game packet that instructs the client to update the user about continents that are conquered.
This generates the event message "The [empire] have captured [continent]."
If the continent_guid is not a valid zone, no message is displayed.
If empire is not a valid empire, or refers to the neutral or Black Ops forces, no message is displayed.
identifies the zone (continent)
identifies the empire
Facilitate a quick-use button for the hotbar.
The hotbar is the eight quick-use slots along the bottom center of the HUD.
Facilitate a quick-use button for the hotbar.
The hotbar is the eight quick-use slots along the bottom center of the HUD.
Each of these slots is the application of a medkit, or use of an implant, or repetition of a text macro.
There are actually sixty-four of these slots, eight bound to the Function keys depending on which set is selected.
When addShortcut is true, the provided Shortcut will be defined and attached to the respective hotbar slot indicated by slot.
If it is false, the given slot will be unbound.
Nothing happens if the slot selection is invalid.
This packet coordinates the shortcut both as an upstream and as a downstream packet, leaning heavily towards the latter.
An interesting application is that, if the user does not already have a medkit or a medkit shortcut;
but, if he places a medkit in his inventory, the shortcut will be automatically added to his hotbar.
This, in turn, dispatches a packet informing the server.
The prior functionality will rarely be appreciated, however, as players rarely never have their medkit shortcut unbound.
the player
the hotbar slot number (one-indexed)
na; always zero?
true, if we are adding a shortcut; false, if we are removing any current shortcut
optional; details about the shortcut to be created
ChangeShortcutBankMessage
Dispatched by the server to indicate a source of damage affecting the player.
Dispatched by the server to indicate a source of damage affecting the player.
Unlike HitHint the damage source is defined by an actual coordinate location rather than a physical target.
The player will be shown a fading, outwards drifting, red tick mark.
The location will indicate a general direction towards the source.
If the option Game/Show Damage Flash is set, the player's screen will flash red briefly when a mark is displayed.
the intensity of the damage tick marks
the position
HitHint
na
na
na
vehicle ?, turret ? Found a HART GUID for now. Need more search.
na - maybe a delay ?
na
na
na
the continent
the building
na
Dispatched from the client to request that an object be deployed.
Information in the packet mainly reports about the surface on which the object will be coplanar when/if placed.
Dispatched from the client to request that an object be deployed.
Information in the packet mainly reports about the surface on which the object will be coplanar when/if placed.
The server responds with a ObjectDeployedMessage packet with the results.
If successful, that is followed by an ObjectCreateMessage packet and a DeployableObjectsInfoMessage packet.
the object
na
the location where the object is to be deployed
the angle of orientation
na
Dispatched by the client when the player attempts to deploy a vehicle.
Dispatched by the client when the player attempts to deploy a vehicle.
Dispatched by the server to cause a specific vehicle to be deployed.
"Deployment" usually isn't enough by itself.
It only changes the physical configuration of the vehicle.
(It's an animation request/trigger?)
Anything that can be "deployed" does so for a very specific reason, to perform a complex function.
These functions are not immediately available.
Attributes must be set properly for the transition between behaviors to occur properly.
In addition, the recently-deployed vehicles will hang in a state of limbo if not configured properly.
It will not even dispatch an un-deploy request upon command in this state.
This packet has nothing to do with ACE deployables.
the player requesting the deployment
the vehicle to be deployed
either requests for a specific deployment state or assignment of the requested state
na; usually 0
na
the position where the object will deploy itself
The entry of a deployable item.
The entry of a deployable item.
the deployable item
the map element depicting the item
the position of the deployable in the world (and on the map)
the player who is the owner
Dispatched by the server to inform the client of a change in deployable items and that the map should be updated.
When this packet defines a Build action, an icon of the deployable item is added to the avatar's map.
Dispatched by the server to inform the client of a change in deployable items and that the map should be updated.
When this packet defines a Build action, an icon of the deployable item is added to the avatar's map.
The actual object referenced does not have to actually exist on the client for the map element to appear.
The identity of the element is discerned from its icon rather than the actual object (if it exists).
When this packet defines a Deconstruct action, the icon of the deployable item is removed from the avatar's map.
(The map icon to be removed is located by searching for the matching UID.
The item does not need to exist to remove its icon.)
All deployables have a map-icon-menu that allows for control of and some feedback about the item.
At the very least, the item can be dismissed.
The type of icon indicating the type of deployable item determines the map-icon-menu.
Normally, the icon of a random (but friendly) deployable is gray and the menu is unresponsive.
If the player_guid matches the client's avatar, the icon is yellow and that marks that the avatar owns this item.
The avatar is capable of accessing the item's map-icon-menu and manipulating the item from there.
If the deployable item actually doesn't exist, feedback is disabled, e.g., Aegis Shield Generators lack upgrade information.
how the entries in the following List are affected
a List of information regarding deployable items
Display a message in the event window that informs of a player death.
The message is composed of three parts:
1) killer information
2) method information
3) victim information
In the case of a player kill, the player's name will be attributed directly.
Display a message in the event window that informs of a player death.
The message is composed of three parts:
1) killer information
2) method information
3) victim information
In the case of a player kill, the player's name will be attributed directly.
In the case of an absentee kill, a description of the method of death will be attributed.
In the case of a suicide, the player attributed is the player who was killed (message format displays only the victim).
The four bytes that follow each name seems to be important to the identification of the associated player.
The same value will be seen in every DestroyDisplayMessage that includes that player,
with respect to whether they are listed as the "killer" or as the "victim."
This holds true for every entry within the same login session, at least.
Blanking either of these values out does not change anything about the format of the event message.
If the two ids match, the packet will interpreted as the "suicide" format, even if the names do not match.
In the case of absentee kills where there is no killer listed, this field is zero'd.
When marked as being in a vehicle or a turret, the player's name will be enclosed within square brackets.
The length of the player's name found at the start of the character string does not reflect
whether or not there will be square brackets (fortunately).
The color of the resulting icon is borrowed from the attributed killer's faction affiliation if it can be determined
and the type of icon is the same as an object id.
An unidentified method or a missing icon defaults to a skull and crossbones.
the name of the player who did the killing
same as CharacterInfoMessage
the empire affiliation of the killer
true, if the killer was in a vehicle at the time of the kill; false, otherwise
na; but does not like being set to 0
modifies the icon in the message, related to the way the victim was killed
the name of the player who was killed
same as CharacterInfoMessage
the empire affiliation of the victim
true, if the victim was in a vehicle when he was killed; false, otherwise
A common ancestor of all the different "strokes" used to keep track of the data.
Dispatched to the client to force a disconnect.
The client's view of the game world will fade and be centered with a PlanetSide textbox with the given message.
Dispatched to the client to force a disconnect.
The client's view of the game world will fade and be centered with a PlanetSide textbox with the given message.
Using the button on the textbox will drop the current world session and return the player to the world select screen.
Technically, they're already disconnected by the time the textbox is visible.
Being disconnected like this has no client-based consequences on its own.
Exploration:
When do the other two messages appear, if at all?
the displayed message
na
na
Alert that the player is "dismounting" a building.
Paragraph in which "'dismounting' a building" is explained.
Alert that the player is "dismounting" a building.
Paragraph in which "'dismounting' a building" is explained.
the player
the building
Note: For some reason this packet does not include the GUID of the vehicle that is being dismounted from.
Note: For some reason this packet does not include the GUID of the vehicle that is being dismounted from. As a workaround vehicle.MountedIn in manually set/removed
// GUID of the player that is rqeuesting dismount
GUID of the vehicle that is requesting dismount
If the vehicle bailed out of the cargo vehicle
If a passenger of the vehicle in the cargo bay requests dismount this bit will be set
If the vehicle was kicked by the cargo vehicle pilot
Dispatched by the client when the player wishes to get out of a vehicle.
Dispatched by the client when the player wishes to get out of a vehicle.
the player
The dismount action e.g. normal dismount, kicked by owner, bailed
Seems to be true if a passenger was manually kicked by the vehicle owner
Dispatched to configure a player's merit commendation ribbons.
Normally, this packet is dispatched by the client when managing merit commendations through the "Character Info/Achievements" tab.
Dispatched to configure a player's merit commendation ribbons.
Normally, this packet is dispatched by the client when managing merit commendations through the "Character Info/Achievements" tab.
On Gemini Live, this packet was also always dispatched once by the server during character login.
It set the term of service ribbon explicitly.
Generally, this was unnecessary, as the encoded character data maintains information about displayed ribbons.
This behavior was probably a routine that ensured that correct yearly progression was tracked if the player earned it while offline.
It never set any of the other ribbon slot positions during login.
A specific ribbon may only be set once to one slot.
The last set slot is considered the valid position to which that ribbon will be placed/moved.
the player
the award to be displayed;
defaults to MeritCommendation.None;
use MeritCommendation.None when indicating "no ribbon"
any of the four positions where the award ribbon is to be displayed;
defaults to TermOfService
MeritCommendation
RibbonBars
Draw a string message on the tactical map.
Draw a string message on the tactical map. String messages have their own color designation and will not inherit line properties.
the x-coordinate marking the bottom center of this message's text
the y-coordinate marking the bottom center of this message's text
the color of the message; 0 is gray (default); 1 is red; 2 is green; 3 is blue
the available "slots" in which to display messages on the map; a maximum of 16 channels/messages (0-15) are available per player; no two messages may inhabit the same channel
the text to display
Dispatched by the client when the player's intent is to put an item down on the ground.
When a player drops an item, it normally appears right under their feet (where they are standing).
Dispatched by the client when the player's intent is to put an item down on the ground.
When a player drops an item, it normally appears right under their feet (where they are standing).
This part of the ground is chosen because it should be the stable.
Also, those coordinates belonging to the player are the most accessible.
This process, however, is not automatic.
The server determines the exact position where the item gets placed.
This packet is complemented by an ObjectDetachMessage packet from the server that performs the actual "dropping."
the item to be dropped
Displays a message about being awarded experience points in the events chat.
This packet does not actually award any experience points.
Displays a message about being awarded experience points in the events chat.
This packet does not actually award any experience points.
It merely generates the message:
"You have been awarded x experience points."
... where x is the number of experience points that have been promised.
If the Boolean parameter is true, x will be equal to the number provided followed by the word "Command."
If the Boolean parameter is false, x will be represented as an obvious blank space character.
(Yes, it prints to the events chat like that.)
the number of (Command) experience points earned
defaults to true for effect;
if false, the number of experience points in the message will be blanked
Dispatched by the client when driving a vehicle in the sphere of influence of an allied base that is an amp station facility or that possesses the lattice-connected benefit of an amp station.
Dispatched by the client when driving a vehicle in the sphere of influence of an allied base that is an amp station facility or that possesses the lattice-connected benefit of an amp station. The vehicle that is being driven will not have perfect fully-charged shields at the time.
the vehicle whose shield is being charged
Load the designator for an entry in the player's favorites list.
This entry defines a user-defined loadout label that appears on a "Favorites" tab list and can be selected.
Load the designator for an entry in the player's favorites list.
This entry defines a user-defined loadout label that appears on a "Favorites" tab list and can be selected.
A subsequent server request - ItemTransactionMessage - must be made to retrieve the said loadout contents.
Multiple separated favorites lists are present in the game.
All entries are prepended with their destination list which indicates how from how that list is viewable.
Different lists also have different numbers of available lines to store loadout entries.
Infantry equipment favorites are appended with a code for the type of exo-suit that they will load on a player.
This does not match the same two field numbering system as in ArmorChangedMessage packets.
Armors:
1 - Agile).
Which exo-suit is associated with which index?
2 - Reinforced
4 - AA MAX
5 - AI MAX
6 - AV MAX
ArmorChangedMessage
Exploration:
There are three unaccounted exo-suit indices - 0, 3, and 7;
and, there are two specific kinds of exo-suit that are not defined - Infiltration and Standard.
It is possible that one of the indices also defines the generic MAX (see
the destination list
the player
the zero-indexed line number of this entry in its list
the identifier for this entry
the type of exo-suit, if an Infantry loadout
na
na
the player
na
the behavior of this packet
what line of the applicable loadout ("Saved Favorites") list is modified
applicable when a load out is being saved; this is the string that will be displayed in the list of loadouts on that line
not sure for u1 / u2 / u3, maybe need a real brain ...
not sure for u1 / u2 / u3, maybe need a real brain ...
na
na; pos of what ?!
na
na
na
na
na; vel of what ?!
An entry in the list of players known to and tracked by this player.
An entry in the list of players known to and tracked by this player. They're called "friends" even though they can be used for a list of ignored players as well.
the name of the player
the player's current state of activity; defaults to false, or offline
Manage the lists of other players whose names are retained by the given player.
Players can be remembered by their names and added to a list of remembered names - the "friends list."
They can also be dropped from the list.
Manage the lists of other players whose names are retained by the given player.
Players can be remembered by their names and added to a list of remembered names - the "friends list."
They can also be dropped from the list.
A list of "ignored" player names can also be retained.
Ignored players will have their comments stifled in the given player's chat window.
No name will be appended or removed from any list until the response to this packet is received.
Actions that involve the "remove" functionality will locate the entered name in the local list before dispatching this packet.
A complaint will be logged to the event window if the name is not found.
Actions:
0 - display friends list
1 - add player to friends list
2 - remove player from friends list
4 - display ignored player list
5 - add player to ignored player list
6 - remove player from ignored player list
Exploration:
Are action = 3 and action = 7 supposed to do anything?
the purpose of this packet
the player name that was entered; blank in certain situations
Manage the lists of other players whose names are retained by the given player.
Friends can be remembered and their current playing status can be reported.
Manage the lists of other players whose names are retained by the given player.
Friends can be remembered and their current playing status can be reported.
Ignored players will have their comments stifled in the given player's chat window.
This does not handle outfit member lists.
Actions:
0 - initialize friends list (no logging)
1 - add entry to friends list
2 - remove entry from friends list
3 - update status of player in friends list;
if player is not listed, he is not added
4 - initialize ignored players list (no logging)
5 - add entry to ignored players list
6 - remove entry from ignored players list
the purpose of the entry(s) in this packet
na; always 0?
na; always true?
na; always true?
a list of Friends
Reports that something has happened, or makes something happen.
When sent from the server to a client, there are twenty-seven individual actions caused by this packet.
Reports that something has happened, or makes something happen.
When sent from the server to a client, there are twenty-seven individual actions caused by this packet.
They are only vaguely organized by behavior and some numbers may not be associated with an action.
When sent by the client to the server, an unknown number of actions are available.
The highest known action is a server-sent 45.
Actions (when sent from server):
03 - symbol: show Mosquito radar
04 - symbol: hide Mosquito radar
07 - warning: missile lock
08 - warning: Wasp missile lock
09 - warning: T-REK lock
12 - sound: base captured fanfare
14 - prompt: new character basic training
22 - message: awarded a cavern capture (updates cavern capture status)
23 - award a cavern kill
24 - message: you have been imprinted (updates imprinted status; does it?)
25 - message: you are no longer imprinted (updates imprinted status; does it?)
27 - event: purchase timers reset (does it?)
31 - switch to first person view, attempt to deconstruct but fail;
event: fail to deconstruct due to having a "parent vehicle"
32 - switch to first person view
33 - event: fail to deconstruct
43 - prompt: friendly fire in virtual reality zone
45 - ?
Actions (when sent from client):
29 - AFK
30 - back in game
36 - turn on "Looking for Squad"
37 - turn off "Looking for Squad"
what this packet does
Dispatched by the client when the player has encountered a physical interaction that would cause damage.
Collision information reports about two subjects who were involved in an altercation.
Dispatched by the client when the player has encountered a physical interaction that would cause damage.
Collision information reports about two subjects who were involved in an altercation.
The first is the player, that is, the client's avatar.
The second is the target with respect to the player - whatever the avatar ran into, or whatever ran into the avatar.
In the case of isolated forms of collision such as fall damage the target fields are blank or zero'd.
na
the player or player-controlled vehicle
the other party in the collision
the player's health
the target's health
the player's velocity
the target's velocity
the player's world coordinates
the target's world coordinates
na
na
na
Dispatched by the server to enact an effect on some game object.
Dispatched by the server to enact an effect on some game object. (Write more some other time.)
the target object
the action code 24 - deconstructs player 28 - start imprinting process (progress bar + character animation) 32 - finish imprinting? 36 - cloak 40 - uncloak 82 - hit flinch? 138 - time till item can be used ????? 44, 45, 46, 47 - Deploy capital base shield pole with animation and broadcasts "The capitol force dome at X has been activated" 48, 49, 50, 51 - Stow capital base shield pole with animation and broadcasts "The capitol force dome at X has been deactivated" 52, 53, 54, 55 - Deploy capital base shield pole (instantly, unless still in the middle of the stow animation) 60, 61, 62, 63 - Displays "This facility's generator is under attack!" 64, 65, 66, 67 - Displays "Generator has Overloaded! Evacuate Generator Room Immediately!" 68, 69, 70, 71 - Displays "This facility's generator is back on line" 88, 89, 90, 91 - ???? (Has been seen on vehicle pad objects, possibly some sort of reset flag after base faction flip / hack clear?) 92, 93, 94, 95 - Plays vehicle pad animation moving downwards 96, 97, 98, 99 - Makes the vehicle bounce slightly. Have seen this in packet captures after taking a vehicle through a warpgate 200, 201, 202, 203 - For aircraft - client shows "THe bailing mechanism failed! To fix the mechanism, land and repair the vehicle!" 224 - Sets vehicle or player to be black ops 228 - Reverts player from black ops
Dispatched by the server to control the progress of hacking.
Dispatched by the server to control the progress of hacking.
While "hacking" is typically performed against enemy targets,
some actions that involve ally on ally hacking can occur.
In this sense, hacking can be consider change progress.
In general, the act of hacking is maintained by the server but the conclusion is managed by the client.
Hacking typically locks the player into a cancellable firing animation and works as all-or-nothing.
The progress bar window is displayed and updated each tick by the server; but, the client can cancel it on its own.
When hacking is complete as indicated by the appropriate HackState,
the client performs the intended action upon the target.
Facility amenities will temporarily ignore IFF requirements;
vehicles will permanently transfer control over to the hack-starter's empire;
facility turret weapons will temporarily convert to their anti-vehicle or anti-aircraft configurations;
facilities will be compromised and begin the long process of converting to the hack-starter's empire;
and, so forth.
As mentioned, one of the unexpected uses of this message
will assist the conversion of allied facility turreted weapons to their upgraded armaments.
na; 0 commonly; 2 when performing (phalanx) upgrades; 3 for building objects during login phase; hack type? possibly player hacking level 0-3?
the target of the hack
the player
the amount of progress visible; visible range is 0 - 100
na;
often a large number;
doesn't seem to be char_id?
hack state
na; 5 - boost pain field at matrixing terminal? usually, 8?
Dispatched by the server to indicate a target or source of damage affecting the player.
When a source is provided, and within render distance, the player will be shown a fading, outwards drifting, red tick mark.
Dispatched by the server to indicate a target or source of damage affecting the player.
When a source is provided, and within render distance, the player will be shown a fading, outwards drifting, red tick mark.
The location and movement of the mark will indicate a general direction towards the source.
If the option Game/Show Damage Flash is set, the player's screen will flash red briefly when a mark is displayed.
For while some mark is being displayed, the player will also make a grunt of pain.
the source of implied damage
the player
Information for positioning a hotspot on the continental map.
The origin point is the lowest left corner of the map grid.
Information for positioning a hotspot on the continental map.
The origin point is the lowest left corner of the map grid.
The coordinates of the hotspot do necessarily match up to the map's internal coordinate system - what you learn using the /loc command.
Instead, all maps use a 0 - 8192 coordinate overlay.
the x-coord of the center of the hotspot
the y-coord of the center of the hotspot
how big the hotspot explosion icon appears
A list of data for creating hotspots on a continental map.
A list of data for creating hotspots on a continental map.
Hotspots indicate player activity, almost always some form of combat or aggressive encounter.
The hotspot system is an all-or-nothing affair.
The received packet indicates the hotspots to display and the map will display only those hotspots.
Inversely, if the received packet indicates no hotspots, the map will display no hotspots at all.
To clear away only some hotspots but retains others, a continental list would have to be pruned selectively for the client.
Exploration:
What does (zone) priority entail?
the zone
na
a List of HotSpotInfo
Dispatched by the server to update the value associated with an object in a specific container object.
The object indicated by object_guid must be associated with the inventory (container_guid) at the time.
Dispatched by the server to update the value associated with an object in a specific container object.
The object indicated by object_guid must be associated with the inventory (container_guid) at the time.
A common use for this packet is to update weapon data when gaining control over that weapon.
For example, before boarding any kind of turret for the first time, it's ammunition component will have exactly one shot.
This shot was established when the turret was first created.
This information would be displayed in the holster icon across the bottom of the GUI while it is mounted.
Furthermore, the mounted player will only fire the turret exactly one time.
This packet can provide the turret with its correct and current amount of ammunition before the player mounts it.
the object being affected
na; usually 0
the object in which object_guid is contained
an amount with which to update object_guid
Dispatch to the client in response to an ItemRequestMessage, roughly after the request has been fulfilled.
Dispatch to the client in response to an ItemRequestMessage, roughly after the request has been fulfilled.
This TCP-like "after" behavior is typically supported by pushing this packet at the end of the MultiPacket that fulfills the request.
the terminal used
the type of transaction
whether the transaction was a success
an error code, if applicable; no error by default
na
na
na
na
na
na
na
na
map_name and nav_map_name should match (unless you want to be lost :))
map_name and nav_map_name should match (unless you want to be lost :))
ex: map13 & home3 = vs sanc map10 & z10 = amerish map07 & z7 = esamir
This message is sent from the server to the client upon reception of a LoginMessage.
This message is sent from the server to the client upon reception of a LoginMessage.
The result of the login is contained in this message. When a login is successful, a session token is returned to the client which then forwards this to the World server it chooses to connect to.
In terms of failed logins, the PS client favors errors in this order
1. LoginError 2. StationError 3. StationSubscriptionStatus
Don't try and set more than one error at the same time. Just provide a single error message to be displayed.
A 'token' which acts exactly like a session cookie in a browser. Allows logins to not use a password
A general login error message
A PlanetSide Sony Online Entertainment (SOE) station result
A response detailing the current subscription type
An unknown possible bitfield that controls some game variables (possibly expansions?)
The login username
If set above 10000, then the user has access to GM commands. Not sure of other values.
Dispatched by the client when the user right-clicks on a piece of Equipment
in an inventory that is not his own backpack
in an attempt to quick-swap that Equipment into his inventory.
Dispatched by the client when the user right-clicks on a piece of Equipment
in an inventory that is not his own backpack
in an attempt to quick-swap that Equipment into his inventory.
Examples of this "other" inventory include: corpses, lockers, and vehicle trunks.
Compared to MoveItemMessage, the source location where item currently resides is not provided.
Additionally, while the over-all destination is provided, the specific insertion point of the destination is not.
the item being taken
where the item will be placed; generally, the player is taking the item
MoveItemMessage
Dispatched from the server, sending a "priority message" to the given client's avatar.
Dispatched from the server, sending a "priority message" to the given client's avatar.
The messaging inbox is generally accessible through the use of alt+i.
It is also made accessible through use of an icon in the lower right corner when there is an outstanding message.
Exploration:
How does the PlanetSide Classic mail system work?
At the moment, it only seems possible to receive and read mail from the server.
the name of the player who sent the mail
the subject
the message
The guid of the player sending the request to board another vehicle with a cargo vehicle
The guid of the vehicle for the requesting player
The cargo vehicle guid e.g. Galaxy / Lodestar
Alert that the player wishes to board a vehicle at a specific entry point.
The client will only dispatch this packet when it feels confident that the player can get into a vehicle.
Alert that the player wishes to board a vehicle at a specific entry point.
The client will only dispatch this packet when it feels confident that the player can get into a vehicle.
It makes its own check whether or not to display that "enter vehicle here" icon on the ground.
This is called an "entry point."
Entry points and seat numbers are not required as one-to-one;
multiple entry points can lead to the same seat, such as the driver seat of an ANT.
The player is not allowed to board anything until the server responds in affirmation.
the player
the vehicle
the entry index that maps to a seat index, specific to the selected vehicle
Change the location of an object - the child - within the inventory system for another object - the parent.
Change the location of an object - the child - within the inventory system for another object - the parent.
(Where the child object was before it was moved is not specified or important.)
The data portion of this packet defines a parent object, a child object to-be, and a destination.
After the packet is delivered, the child object will be expected to be a possession of the parent object in the codified inventory location.
The "inventory" of the parent object is a generalization of that object's containment or installation positions.
The inventory is has different referral words for these positions depending on the target parent;
but, it is generally "seats" or "mounting points" for vehicles;
and, it is generally "holsters" or "grid inventory positions" for players.
For players, "holsters" and "grid inventory positions" have 1:1 numerical mapping.
For vehicles, however, "seats" and "mounting points" are not consistently mapped and are much more context sensitive.
For that reason, this installation position will hitherto be referred to as a generic "slot."
Both the client and the server can send and receive this packet.
Its interplay with other packets simulate a lazy TCP-like approach to object manipulation.
If the client sends this packet, it will generally have already done what it was going to do.
If the server sends this packet, the client will have been waiting on confirmation of an action it previously requested.
Player inventory slots:
0x80 - 0 - pistol holster 1
0x81 - 1 - pistol holster 2
0x82 - 2 - rifle holster 1
0x83 - 3 - rifle holster 2
0x84 - 4 - knife holster
0x86 - 6 - grid (1,1)
0x00FA - 250 - is a special dest/extra code that "attaches the item to the player's cursor"
the parent object
the child object
a codified location within the parent object's inventory;
8u (0 - 127 or 0x80 - 0xFF) or 16u (128 - 32767 or 0x0080 - 0x7FFF)
Communicate with the client that a certain object with certain properties is to be created.
Communicate with the client that a certain object with certain properties is to be created.
In general, ObjectCreateMessage and its counterpart ObjectCreateDetailedMessage should look similar.
In normal packet data order, the parent object is specified before the actual object is specified.
This is most likely a method of early correction.
"Does this parent object exist?"
"Is this new object something that can be attached to this parent?"
"Does the parent have the appropriate attachment slot?"
There is no fail-safe method for any of these circumstances being false, however, and the object will simply not be created.
In instance where the parent data does not exist, the object-specific data is immediately encountered.
The object's GUID is assigned by the server.
The clients are required to adhere to this new GUID referring to the object.
There is no fail-safe for a conflict between what the server thinks is a new GUID and what any client thinks is an already-assigned GUID.
Likewise, there is no fail-safe between a client failing or refusing to create an object and the server thinking an object has been created.
(The GM-level command /sync tests for objects that "do not match" between the server and the client.
It's implementation and scope are undefined.)
Knowing the object's type is essential for parsing the specific information passed by the data parameter.
If the object does not have encoding information or is unknown, it will not translate between byte data and a game object.
the total length of the data that composes this packet in bits, excluding the opcode and end padding
the code for the type of object being constructed
the GUID this object will be assigned
if defined, the relationship between this object and another object (its parent)
the data used to construct this type of object;
on decoding, set to None if the process failed
Communicate with the client that a certain object with certain properties is to be created.
Communicate with the client that a certain object with certain properties is to be created.
In general, ObjectCreateMessage and its counterpart ObjectCreateDetailedMessage should look similar.
ObjectCreateMessage is capable of creating every non-environmental object in the game through the use of encoding patterns.
The objects produced by this packet generally do not always fully express all the complexities of the object class.
With respect to a client's avatar, all of the items in his inventory are given thorough detail so that the client can account for their interaction.
The "shallow" objects produced by this packet are not like that.
They express only the essential information necessary for client interaction when the client interacts with them.
For example, a weapon defined by this packet may not care internally what fire mode it is in or how much ammunition it has.
Such a weapon is not in the client's player's holster or inventory.
It is imperceptive information to which he would not currently have access.
An 0x17 game object is, therefore, a game object with only the essential data exposed.
When interacting with an 0x17 game object, the server will swap back and forth between it and an 0x18 object.
(Or it will be removed when it is placed somewhere a given client will no longer be able to see it.)
The purpose of this conversion is to control network traffic and object agency.
It is not necessary to keep track of all objects on every player on every client individually.
This relates to the goal of this packet exposing only "essential data."
One player does not need to know how much ammunition remains in a weapon belonging to another player normally.
One player also does not need to know how much ammunition is used up when another player reloads their weapon.
The only way the first player will know is when the weapon is transferred into his own inventory.
All other clients are spared micromanagement of the hypothetical other player's weapon.
Updated information is only made available when and where it is needed.
Knowing the object's type is necessary for proper parsing.
If the object does not have encoding information or is unknown, it will not translate between byte data and a game object.
the total length of the data that composes this packet in bits; exclude the opcode (1 byte) and end padding (0-7 bits); when encoding, it will be calculated automatically
the code for the type of object being constructed; always an 11-bit LE value
the GUID this object will be assigned
if defined, the relationship between this object and another object (its parent)
the data used to construct this type of object;
on decoding, set to None if the process failed
ObjectCreateMessageParent
ObjectCreateDetailedMessage
Dispatched by the server to generate a message in the events chat when placing deployables.
This packet does not actually modify anything in regards to deployables.
Dispatched by the server to generate a message in the events chat when placing deployables.
This packet does not actually modify anything in regards to deployables.
The most common form of the generated message is:
"You have placed x of a possible y thing s."
... where x is the current count of objects of this type that have been deployed;
y is the (reported) maximum amount of objects of this type that can be deployed;
and, thing is the token for objects of this type.
If the thing is a valid string token, it will be replaced by language-appropriate descriptive text in the message.
Otherwise, that text is placed directly into the message, with an obvious space between the text and the "s".
"boomer," for example, is replaced by "Boomer Heavy Explosives" in the message for English language.
"bullet_9mm_AP," however, is just "bullet_9mm_AP s."
When the action is Success, the message in the chat will be shown as above.
When the action is Failure, the message will be:
"thing failed to deploy and was destroyed."
... where, again, thing is a valid string token.
na; usually 0?
descriptive text of what kind of object is being deployed; string token of the object, at best
the form the message will take
the current number of this type of object deployed
the maximum number of this type of object that can be deployed
Dispatched by the server to cause two associated objects to disentangle from one another.
ObjectDetachMessage is the opposite of ObjectAttachMessage.
Dispatched by the server to cause two associated objects to disentangle from one another.
ObjectDetachMessage is the opposite of ObjectAttachMessage.
When detached, the resulting freed object will be placed at the given coordinates in the game world.
For detachment from some container objects, a default placement point may exist.
This usually matches the position where the original mounting occurred, or is relative to the current position of the container.
This mounting position overrides the input one, but other temporary side-effects may occur.
For example, if a player detaches from a vehicle with coordinates for "somewhere else,"
the camera will temporarily be moved to that location "somewhere else" for the duration of the animation
but it will soon regain the player who appeared where expected.
An object that is already dropped is a special case where the parent (container) does not technically exist.
The parent also does not need to exist as the object will still be transported to the specified coordinates.
the container/connector object
the contained/connected object
where the contained/connected object will be placed after it has detached
the amount of roll that affects orientation of the dropped item
the amount of pitch that affects orientation of the dropped item
the amount of yaw that affects orientation of the dropped item
Update a list of (new) objects that have been detected by this client in one way or another.
Update a list of (new) objects that have been detected by this client in one way or another.
the player
the player(?);
often matches with player_guid1
na
list of detected objects; normally contains at least one element
Dispatched by the server to tell the client to display an orbital strike waypoint somewhere in the game world.
Waypoints are kept unique by the guid that is passed with them.
Dispatched by the server to tell the client to display an orbital strike waypoint somewhere in the game world.
Waypoints are kept unique by the guid that is passed with them.
To clear a waypoint is to pass the another packet to the client with the same GUID but with no coordinates.
Passing new coordinates with that GUID will update the position of the indicated waypoint.
If the GUID sent with the packet belongs to the client's avatar that player will be given text overlay instructions:
"Press the fire key or button to launch an orbital strike at the waypoint."
The text will fade shortly after the waypoint has been cleared.
All OrbitalStrikeWaypointMessage packets sent to a client will create a waypoint that will be seen by that client.
All rendered waypoints, regardless of the users who summoned them, will be seen in the faction color of the client's avatar.
(Black OPs orbital strike waypoints are green, as expected.)
The server should not notify the wrong clients about another faction's prepared orbital strikes;
however, even if it did, those beams would be seen as a same-faction's marker.
coordinates used to identify the waypoint; ostensibly, the GUID of the player who placed the waypoint
the coordinates of the waypoint;
None if clearing a waypoint (use the same guid as to create it)
Dispatched by the server to cause the player to slowly drown.
Dispatched by the server to cause the player to slowly drown.
If the player is mounted in a vehicle at the time, alert the player that the vehicle may be disabled.
When a player walks too far underwater, a borderless red progress bar with a countdown from 100 (98) is displayed across the screen.
The countdown proceeds to zero at a fixed rate and is timed with the depleting progress bar.
When it reaches zero, the player will be killed.
If the player is in a vehicle after a certain depth, a blue bar and countdown pair will superimpose the red indicators.
It depletes much more rapidly than the red indicators.
When it reaches zero, the vehicle will become disabled.
All players in the vehicle's seats will be kicked and they will not be allowed back in.
Normally, the countdowns should be set to begin at 100 (100.0).
This is the earliest the drowning GUI will appear for either blue or red indicators.
Passing greater intervals - up to 204.8 - will start the countdown silently but the GUI will be hidden until 100.0.
(The progress indicators will actually appear to start counting from 98.)
Managing the secondary vehicle countdown independent of the primary player countdown requires updating with the correct levels.
The countdown can be cancelled by instructing it to be active = false.
Except for updating the indicators, all other functionality of "drowning" is automated by the server.
the player
the remaining countdown; for character oxygen, the progress per second rate is about 1
show a new countdown if true (resets any active countdown);
clear any active countdowns if false
optional state of the vehicle the player is driving
Dispatched by the client when the player's intent is to collect an item from the ground.
When a player faces a freed item on the ground in the game world, a prompt appears that invites him to pick it up.
Dispatched by the client when the player's intent is to collect an item from the ground.
When a player faces a freed item on the ground in the game world, a prompt appears that invites him to pick it up.
Doing so generates this packet.
The server determines the exact inventory position where the item will get placed.
If the inventory has insufficient space to accommodate the item, it gets put into the player's hand (on the cursor).
This packet is complemented by an ObjectAttachMessage packet from the server that performs the actual "picking up."
na
na
na
na
Sent periodically by the PlanetSide client when connected to the Login server.
Sent periodically by the PlanetSide client when connected to the Login server. Not encrypted
Which server on the server display is the ping referring to
The number of ticks. Usually just reflected back to the client
na
Global:
50 - Common Initialization?
51 - Common Initialization?
67 - ???
Global (GUID=0)
75 - Russian client region check (value checks with bitmask & 8)
82 - ???
83 - max boomers
84 - max he mines
85 - max disruptor mines
86 - max spitfire turrets
87 - max motion sensors
88 - max shadow turrets
89 - max cerebus turrets
90 - max Aegis shield generators
91 - max TRAPs
92 - max OMFTs
93 - max sensor disruptors
94 - boomers
95 - he mines
96 - disruptor mines
97 - spitfire turrets
98 - motion sensors
99 - shadow turrets
100 - cerebus turrets
101 - Aegis shield generators
102 - TRAPSs
103 - OMFTs
104 - sensor disruptors
112 - enable/disable festive backpacks
Players/General:
Server to client :
0 - health (setting to zero on vehicles/terminals will destroy them)
1 - healthMax
2 - stamina
3 - staminaMax
4 - armor
5 - armorMax
6 - PA_RELEASED - transform the (other) avatar in backpack on ground
7 - Sets charge level for MAX capacitor
8 - Enables empire specific max capacitor function - NC Shield, TR Overdrive, VS Jumpjets
9 - Possibly unused now - PA_SHIELDSTRENGTH in beta client
14 - Something with grief
15 - Weapon Lock. Value exemple : 600 to have 1 min lock. Max possible is 30min lock
16 - PA_DECONSTRUCTING in beta client
17 - BEP. Value seems to be the same as BattleExperienceMessage
18 - CEP.
19 - Anchors. Value is 0 to disengage, 1 to engage.
20 - Control console hacking. "The FactionName has hacked into BaseName - also sets timer on CC and yellow base warning lights on
na
Global:
50 - Common Initialization?
51 - Common Initialization?
67 - ???
Global (GUID=0)
75 - Russian client region check (value checks with bitmask & 8)
82 - ???
83 - max boomers
84 - max he mines
85 - max disruptor mines
86 - max spitfire turrets
87 - max motion sensors
88 - max shadow turrets
89 - max cerebus turrets
90 - max Aegis shield generators
91 - max TRAPs
92 - max OMFTs
93 - max sensor disruptors
94 - boomers
95 - he mines
96 - disruptor mines
97 - spitfire turrets
98 - motion sensors
99 - shadow turrets
100 - cerebus turrets
101 - Aegis shield generators
102 - TRAPSs
103 - OMFTs
104 - sensor disruptors
112 - enable/disable festive backpacks
Players/General:
Server to client :
0 - health (setting to zero on vehicles/terminals will destroy them)
1 - healthMax
2 - stamina
3 - staminaMax
4 - armor
5 - armorMax
6 - PA_RELEASED - transform the (other) avatar in backpack on ground
7 - Sets charge level for MAX capacitor
8 - Enables empire specific max capacitor function - NC Shield, TR Overdrive, VS Jumpjets
9 - Possibly unused now - PA_SHIELDSTRENGTH in beta client
14 - Something with grief
15 - Weapon Lock. Value exemple : 600 to have 1 min lock. Max possible is 30min lock
16 - PA_DECONSTRUCTING in beta client
17 - BEP. Value seems to be the same as BattleExperienceMessage
18 - CEP.
19 - Anchors. Value is 0 to disengage, 1 to engage.
20 - Control console hacking. "The FactionName has hacked into BaseName - also sets timer on CC and yellow base warning lights on
These values seem to correspond to the following data structure: Time left - 2 bytes, faction - 1 byte (1-4), isResecured - 1 byte (0-1)
24 - Learn certifications with value :
01 : Medium Assault
02 : Heavy Assault
03 : Special Assault
04 : Anti-Vehicular
05 : Sniping
06 : Elite Assault
07 : Air Cavalry, Scout
08 : Air Cavalry, Interceptor
09 : Air Cavalry, Assault
10 : Air Support
11 : ATV
12 : Light Scout
13 : Assault Buggy
14 : Armored Assault 1
15 : Armored Assault 2
16 : Ground Transport
17 : Ground Support
18 : BattleFrame Robotics
19 : Flail
20 : Switchblade
21 : Harasser
22 : Phantasm
23 : Galaxy Gunship
24 : BFR Anti Aircraft
25 : BFR Anti Infantry
26 : ?! Removed Cert ?
27 : ?! Removed Cert ?
28 : Reinforced ExoSuitDefinition
29 : Infiltration Suit
30 : MAX (Burster)
31 : MAX (Dual-Cycler)
32 : MAX (Pounder)
33 : Uni-MAX
34 : Medical
35 : Advanced Medical
36 : Hacking
37 : Advanced Hacking
38 : Expert Hacking
39 : Data Corruption
40 : Electronics Expert (= Expert Hacking + Data Corruption) Must have Advanced Hacking
41 : Engineering
42 : Combat Engineering
43 : Fortification Engineering
44 : Assault Engineering
45 : Advanced Engineering (= Fortification Engineering + Assault Engineering) Must have Combat Engineering
25 - Forget certifications (same order as 24)
26 - Certification reset timer (in seconds)
27 - PA_JAMMED - plays jammed buzzing sound
28 - PA_IMPLANT_ACTIVE - Plays implant sounds. Valid values seem to be up to 20.
29 - PA_VAPORIZED - Visible ?! That's not the cloaked effect, Maybe for spectator mode ?. Value is 0 to visible, 1 to invisible.
31 - Info under avatar name : 0 = LFS, 1 = Looking For Squad Members
32 - Info under avatar name : 0 = Looking For Squad Members, 1 = LFS
35 - BR. Value is the BR
36 - CR. Value is the CR
43 - Info on avatar name : 0 = Nothing, 1 = "(LD)" message
45 - NTU charge bar 0-10, 5 = 50% full. Seems to apply to both ANT and NTU Silo (possibly siphons?)
46 - Sends "Generator damage is at a critical level!" message
47 - Sets base NTU level to CRITICAL. MUST use base modelId not base GUID
48 - Set to 1 to send base power loss message & turns on red warning lights throughout base. MUST use base modelId not base GUID
49 - Vehicle texture effects state? (>0 turns on ANT panel glow or ntu silo panel glow + orbs) (bit?)
52 - Vehicle particle effects? (>0 turns on orbs going towards ANT. Doesn't affect silo) (bit?)
53 - LFS. Value is 1 to flag LFS
54 - Player "Aura". Values can be expressed in the first byte's lower nibble:
- 0 is nothing
- 1 is plasma
- 2 is ancient
- 4 is LLU (?)
- 8 is fire
-- e.g., 13 = 8 + 4 + 1 = fire and LLU and plasma
55 - "Someone is attempting to Heal you". Value is 1
56 - "Someone is attempting to Repair you". Value is 1
67 - Enables base shields (from cavern module/lock). MUST use base modelId not GUID
73 - "You are locked into the Core Beam. Charging your Module now.". Value is 1 to active
77 - Cavern Facility Captures. Value is the number of captures
78 - Cavern Kills. Value is the number of kills
106 - Custom Head
116 - Apply colour to REK beam and REK icon above players (0 = yellow, 1 = red, 2 = purple, 3 = blue)
Client to Server :
106 - Custom Head
224 - Player/vehicle joins black ops
228 - Player/vehicle leaves black ops
Vehicles:
10 - Driver seat permissions (0 = Locked, 1 = Group, 3 = Empire)
11 - Gunner seat(s) permissions (same)
12 - Passenger seat(s) permissions (same)
13 - Trunk permissions (same)
21 - Declare a player the vehicle's owner, by globally unique identifier
22 - Toggles gunner and passenger mount points (1 = hides, 0 = reveals; this also locks their permissions)
54 - Vehicle EMP? Plays sound as if vehicle had been hit by EMP
68 - Vehicle shield health
79 - ???
80 - Damage vehicle (unknown value)
81 - ???
113 - Vehicle capacitor - e.g. Leviathan EMP charge
the object
the field
the value
na
The one common use of this packet is to transmit information about the name of the player's outfit during login.
na
The one common use of this packet is to transmit information about the name of the player's outfit during login.
The guid will belong to the player; the "type will be 0; the outfit name will appear on the appropriate window.
na
na
na
Causes the avatar to be prepped for drop pod use.
This packet is dispatched from the server to all occupants of the HART shuttle when it has completed its take-off animation.
Causes the avatar to be prepped for drop pod use.
This packet is dispatched from the server to all occupants of the HART shuttle when it has completed its take-off animation.
When received by the client, that player's avatar is "removed from the world" and the Interstellar Map is displayed for them.
The "Launch Drop Pod" button window is also made visible.
Selecting individual continental maps for viewing and clicking on the landmasses has the expected behavior for drop pods implementation.
Being seated on the HART shuttle at the time, a player's avatar does not physically exist when the packet is received.
If the packet is received while the player is outside of the HART shuttle, the state of their avatar is not known to them.
"Removed from the world" merely implies that one can not leave the Interstellar Map once it has been displayed.
According to packet capture, their avatar is not explicitly deconstructed until the dropped-into map is loaded.
When the packet is received on one's client, but is addressed to another player, nothing seems to happen to that player.
If that player's model is outside of the HART, it will not deconstruct.
Only the client's avatar can be affected by this packet.
the player
true by default;
nothing when false (?)
The server instructs some clients to render a player (usually not that client's avatar) to move in a certain way.
This packet instructs the basic aspects of how the player character is positioned and how the player character moves.
The server instructs some clients to render a player (usually not that client's avatar) to move in a certain way.
This packet instructs the basic aspects of how the player character is positioned and how the player character moves.
Each client keeps track of where a character "currently" is according to that client.
pos reflects an update in regards to where the character should be moved.
Data between this "currently" and "new" are interpolated over a fixed time interval.
Position and velocity data is standard to normal PlanetSide ranges.
All angles follow the convention that every 0x1 is about 2.8125 degrees; so, 0x10 is 45.0 degrees.
The avatar model normally moves from where it "currently" is to pos.
When vel is defined, pos is treated as where the avatar model starts its animation.
In that case, it appears to teleport to pos to carry out the interpolated movement according to vel.
After the move, it remains at essentially pos + vel * t.
The repositioning always takes the same amount of time.
The player model is left in a walking/running animation (in place) until directed otherwise.
If the model must interact with the environment during a velocity-driven move, it copes with local physics.
A demonstration of this is what happens when one player "runs past"/"into" another player running up stairs.
The climbing player is frequently reported by the other to appear to bounce over that player's head.
If the other player is off the ground, passing too near to the observer can cause a rubber band effect on trajectory.
This effect is entirely client-side to the observer and affects the moving player in no way.
the avatar's guid
the position of the avatar in the world environment (in three coordinates)
an optional velocity
a "yaw" angle
a "pitch" angle
a "yaw" angle that represents the angle of the avatar's upper body with respect to its forward-facing direction; this number is normally 0 for forward facing; the range is limited between approximately 61 degrees of center turned to left or right
A sequential counter
avatar is crouching
avatar is jumping; must remain flagged for jump to maintain animation
provide a measure of vertical stability when really close to the avatar character
avatar is cloaked by virtue of an Infiltration Suit
Constantly sent from the client to the server to update player avatar properties.
Exploration:
seq_time appears to be used in other message definitions as well.
Constantly sent from the client to the server to update player avatar properties.
Exploration:
seq_time appears to be used in other message definitions as well.
It seems to represent a timestamp for ordering, e.g., player and weapon events.
the player's GUID
where the player is in the world
how the player is moving
a "yaw" angle
a "pitch" angle
a "yaw" angle that represents the angle of the avatar's upper body with respect to its forward-facing direction; this number is normally 0 for forward facing; the range is limited between approximately 61 degrees of center turned to left or right
na
na
avatar is crouching
avatar is jumping; must remain flagged for jump to maintain animation
provide a measure of vertical stability when really close to the avatar character
avatar is cloaked by virtue of an Infiltration Suit
na
na
Push specific motion-based stimuli on a specific character.
PlayerStateMessageUpstream involves data transmitted from a client to the server regarding its avatar.
Push specific motion-based stimuli on a specific character.
PlayerStateMessageUpstream involves data transmitted from a client to the server regarding its avatar.
PlayerStateMessage involves data transmitted from the server to the clients regarding characters other than that client's avatar.
PlayerStateShiftMessage involves data transmitted from the server to a client about that client's avatar.
It temporarily asserts itself before normal player movement and asserts specific placement and motion.
An application of this packet is being /warped within a zone via a non-triggering agent (like a teleporter).
Another, more common, application of this packet is being thrown about when the target of an attempted roadkill.
if defined, the behaviors to influence the character
na
Dispatched to deliberately render certain projectiles of a weapon on other players' clients.
This packet is generated by firing specific weapons in specific fire modes.
Dispatched to deliberately render certain projectiles of a weapon on other players' clients.
This packet is generated by firing specific weapons in specific fire modes.
For example, the Phoenix (hunterseeker) discharged in its primary fire mode generates this packet;
but, the Phoenix in secondary fire mode does not.
The Striker (striker) discharged in its primary fire mode generates this packet;
but, the Striker in secondary fire mode does not.
The chosen fire mode(s) are not a straight-fire projectile but one that has special control asserted over it.
For the Phoenix, it is user-operated.
For the Striker, it tracks towards a target while the weapon's reticle hovers over that target.
This packet will continue to be dispatched by the client for as long as the projectile being tracked is in the air.
All projectiles have a maximum lifespan before they will lose control and either despawn and/or explode.
This number is tracked in the packet for simplicity.
If the projectile strikes a valid target, the count will jump to a significantly enormous value beyond its normal lifespan.
This ensures that the projectile - locally and the shared model - will despawn.
the projectile
the position of the projectile
the velocity of the projectile
na; usually 0
na; will remain consistent for the lifespan of a given projectile in most cases
na; will remain consistent for the lifespan of a given projectile in most cases
na; usually false
how long the projectile has been in the air; often expressed in multiples of 2
Dispatched by the server to alert the client about custom permissions in different zones.
The primarily way this packet was used on Gemini Live was to restrict weapons per zone.
Dispatched by the server to alert the client about custom permissions in different zones.
The primarily way this packet was used on Gemini Live was to restrict weapons per zone.
The Battle Island restrictions, for example, were enforced by these properties.
Exploration:
What else can you do with this packet?
a List defining scopes for the targets of internal property changes
The player's avatar has moved in relation to a set piece that reacts with the player due to his proximity.
Elements that exhibit this behavior include Repair/Rearm Silos in facility courtyards and various cavern crystals.
The player's avatar has moved in relation to a set piece that reacts with the player due to his proximity.
Elements that exhibit this behavior include Repair/Rearm Silos in facility courtyards and various cavern crystals.
The packets are only dispatched when it is appropriate for the player to be affected.
Exploration:
Packets where the bytes for the player's GUID are blank exist.
the player
the object whose functionality is triggered
na
Instructs client to update the quantity of an item based on a delta when sent server to client.
Instructs client to update the quantity of an item based on a delta when sent server to client.
See also QuantityUpdateMessage
the item to update
the change in quantity of the item
Instructs client to update the quantity of an item when sent server to client.
Instructs client to update the quantity of an item when sent server to client.
See also QuantityDeltaUpdateMessage
the item to update
the quantity to update the item to
Packet send by client when clic on button after death https://streamable.com/4r16m
Dispatched to the client to report the amount of repair that is performed upon a target item.
Dispatched to the client to report the amount of repair that is performed upon a target item. The item could be a player or a vehicle or a stationary game object, e.g., a terminal.
an item
how much the item has been repaired for
Modify the list of squads available to a given player.
Modify the list of squads available to a given player.
The squad list updates in real time rather than just whenever a player opens the squad information window.
The four main operations are: initializing the list, updating entries in the list, removing entries from the list, and clearing the list.
The process of initializing the list and clearing the list actually are performed by similar behavior.
Squads would just not be added after the list clears.
Moreover, removing entries from the list overrides the behavior to update entries in the list.
The two-three codes per entry (see SquadHeader) are important for determining the effect of a specific entry.
As of the moment, the important details of the behaviors is that they modify how the packet is encoded and padded.
Referring to information in SquadListing, entries are identified by their index in the list.
This is followed by a coded section that indicates what action the entry will execute on that squad listing.
After the "coded action" section is the "general information" section where the data for the change is specified.
In this manner, all the entries will have a knowable length.
The total number of entries in a packet is not known until they have all been parsed.
During the list initialization process, the entries must be in ascending order of index.
Otherwise, the specific index of the squad listing is referenced.
The minimum number of entries is "no entries."
The maximum number of entries is supposedly 254.
The last item is always the index 255 and this is interpreted as the end of the stream.
When no updates are provided, the client loads a default (but invalid) selection of data comprising four squads:
0 Holeesh another purpose Desolation 6/7
1 Korealis another purpose Drugaskan 10/10
2 PsychoSanta blah blah blah 10/10
3 Squishling another purpose Cyssor 8/10
The last entry is entirely in green text.
Behaviors:
behavior behavior2
1 X Update where initial entry removes a squad from the list
5 6 Clear squad list and initialize new squad list
5 6 Clear squad list (transitions directly into 255-entry)
6 X Update a squad in the list
a code that suggests the primary purpose of the data in this packet
during initialization, this code is read;
it supplements the normal behavior and is typically is an "update" code
a Vector of the squad listings
Dispatched by server to assert control of a player's vehicle, usually temporarily, and to relinquish that control.
The "vehicle" counts as any mobile platform where the user's character is currently sitting.
Dispatched by server to assert control of a player's vehicle, usually temporarily, and to relinquish that control.
The "vehicle" counts as any mobile platform where the user's character is currently sitting.
If the player is not sitting in what the game considers a "vehicle," the packet is wasted.
Either of the first two parameters - lock_accelerator or lock_wheel - constitutes any vehicle being overrode.
Either of the latter two parameters - lock_thrust or lock_strafe - constitutes a flight vehicle being overrode.
No message is displayed if the vehicle is placed under any form of server control.
During server control, this is an acceleration value (?);
during cancellable auto-drive, a constant velocity value.
Vertical thrust control for aircraft is either on or off;
the amount of that thrust can not be controlled.
After being controlled, when the vehicle is no longer under control,
it will transition into a state of constant speed auto-drive.
The message regarding the vehicle being back in the driver's control will display,
unless one of the aforementioned lock_* parameters is still set to true.
When dismounting a bailable vehicle while it is under the server's control,
the player will behave like they are bailing from it.
(The vehicle actually has to be "bailable" first, of course.)
"Something like speed:"
For ground vehicles, for n, the calculated in-game speed for the value in this packet will be at least 3.45 x n.
For flight vehicles, for n, the forward air speed for the value in this packet will be at least 1.18 * n.
This approximation is not always going to be accurate but serves as a good rule of thumb.
driver has no control over vehicle acceleration
driver has no control over vehicle turning
move in reverse 0 = forward 1 = reverse
na; something to do with vehicle bailable speed
pilot has no control over vertical thrust; asserts a constant positive vertical thrust; the only valid setting appears to be 1
pilot has no control over strafing thrust; 0 = not locked 1 = no strafing 2 = strafe left automatically 3 = strafe right automatically
"something like speed"
na;
set lock_wheel to true to expose this value
Which comm.
Which comm. channels are allowed to display in the main chat window.
The server sends a SetChatFilterMessage and the client responds with the same during login.
Nine channels exist.
Their values can be modified by radio buttons found under the current chat window's "Options" pane.
Each time the client updates the channel permissions, it sends this packet to the server nine times.
The packet starts with the previous channel filter states and then updates each channel sequentially.
The send_channel and the channel_filter values are in the following order:
Unknown, Tells, Local, Squad, Outfit, Command, Platoon, Broadcast, Squad Leader
The first channel is unlisted.
automatically select the fully qualified channel to which the user sends messages
where this packet was dispatched;
true, from the server; false, from the client
each channel permitted to post its messages; when evaluated from a packet, always in original order
The object_guid space for SetEmpireMessage is continent specific.
The object_guid space for SetEmpireMessage is continent specific. SetEmpireMessage is usually followed by HackMessage (indicating the hack disposition of the same object_guid)
Instructs an avatar to be stood, to look, and to move, in a certain way.
The position defines a coordinate location in the avatar's current zone to which the avatar is immediately moved
This movement is instantaneous and has no associated animation.
Instructs an avatar to be stood, to look, and to move, in a certain way.
The position defines a coordinate location in the avatar's current zone to which the avatar is immediately moved
This movement is instantaneous and has no associated animation.
If velocity is defined, the avatar is provided an "external force" that "pushes" the avatar in a given direction.
This external force is not accumulative.
Also, the external force is only applied once the avatar is set to the provided position.
The angle defines the center of a range of angles that count as "in front of the avatar."
Specifically, this range is the upper body's turn limit.
A stationary player may look left and right, rotating their upper body only, until they hit a certain angle.
Normally, the player's whole body will then turn to accommodate turning further than this angle.
This packet marks that limit as a hard limit for rotation and will reset the player's model and camera if necessary.
While it is in effect, the player will not turn their whole body once they can no longer turn their upper body.
na
the position to move the character to in the world environment
the center of the range of upper body angles, the player's actual yaw;
if this value is beyond its angular limit values,
the model will attempt to snap to what it considers the closest upper body turning limit angle;
the actual range is approximately viewYawLimit +/- 61.8215;
if defined, the velocity to apply to to the character at the given position
PlayerStateMessage.facingYawUpper
PlayerStateMessageUpstream.facingYawUpper
Details regarding this shortcut.
The parameters purpose and tile are closely related.
Details regarding this shortcut.
The parameters purpose and tile are closely related.
These two fields are consistent for all shortcuts of the same type.
purpose indicates the purpose of the shortcut.
tile is related to what kind of graphic is displayed in this shortcut's slot on the hotbar based on its purpose.
The parameters effect1 and effect2 are exclusive to text macro shortcuts and are defaulted to empty Strings.
The shortcut_macro setting displays a word bubble superimposed by the (first three letters of) effect1 text.
Implants and the medkit should have self-explanatory graphics.
Purpose:
0 - Medkit
1 - Macro
2 - Implant
Tile:
advanced_regen (regeneration)
audio_amplifier
darklight_vision
medkit
melee_booster
personal_shield
range_magnifier
second_wind
shortcut_macro
silent_run (sensor shield)
surge
targeting (enhanced targetting)
Exploration:
What is purpose when 3?
the primary use of this shortcut
the visual element of the shortcut
for macros, a three letter acronym displayed in the hotbar
for macros, the chat message content
na
na
when defined, na; non-zero when selecting the sanctuary option from a non-sanctuary continent deployment map
the type of spawn point destination
na
na
when defined, the continent number
Dispatched to the server when a type of effect that influence multiple targets activates.
Splash does not refer to the effect upon an applicable target.
Dispatched to the server when a type of effect that influence multiple targets activates.
Splash does not refer to the effect upon an applicable target.
Splash denotes the fixed radius wherein a said effect exerts temporary influence.
Being damaged is the most common splash effect; the jammering effect is another.
A pain field does not count because it is an environmental constant.
Lashing is considered different because it is a type of inheritable influence.
Valid targets for splash are all interactive game objects that maintain a GUID.
This includes: players, of course; vehicles, of course; doors; terminals; spawn tubes; and, such objects.
Not all targets listed will actually be influenced by the effect carried by splash.
The effect commonly modifies the visual depiction of the splash.
Being able to "see" splash also does not necessarily mean that one will be influenced by it.
Visually and spatially, it may seem to bleed through surfaces on occasion.
The effect will not be carried, however.
Splash will also respect the game's internal zoning and not pass through temporary obstacles like closed doors.
Not being able to see splash also does not stop a target from being affected.
The radius of influence is typically a bit larger than the visual indication.
All sources of splash damage herein will be called "grenades" for simplicity.
na
the grenade's object
the position where the grenade landed (where it is)
na; frequently 42
na; frequently 0
the velocity of the grenade when it landed
na
a List of all targets influenced by the splash
An entry of the target that was hit by splash damage.
An entry of the target that was hit by splash damage.
the target's uid
the target's position (when hit)
na
na
Manage composition and details of a player's current squad, or the currently-viewed squad.
The action code indicates the format of the remainder data in the packet.
Manage composition and details of a player's current squad, or the currently-viewed squad.
The action code indicates the format of the remainder data in the packet.
The following formats are translated; their purposes are listed:
(None)
3 - Save Squad Definition
8 - List Squad
26 - Reset All
35 - Cancel Squad Search
41 - Cancel Find
Boolean
28 - Auto-approve Requests for Invitation
29 - UNKNOWN
30 - UNKNOWN
31 - Location Follows Squad Lead
Int
10 - Select this Role for Yourself
11 - UNKNOWN
20 - (Squad leader) Change Squad Zone
21 - (Squad leader) Close Squad Member Position
22 - (Squad leader) Add Squad Member Position
33 - UNKNOWN
40 - Find LFS Soldiers that Meet the Requirements for this Role
Long
13 - UNKNOWN
14 - UNKNOWN
15 - UNKNOWN
37 - UNKNOWN
String
7 - UNKNOWN
19 - (Squad leader) Change Squad Purpose
Int :: Long
12 - UNKNOWN
25 - (Squad leader) Change Squad Member Requirements - Weapons
38 - UNKNOWN
Int :: String
23 - (Squad leader) Change Squad Member Requirements - Role
24 - (Squad leader) Change Squad Member Requirements - Detailed Orders
Long :: Long
36 - UNKNOWN
String :: Long :: Int :: Int
34 - Search for Squads with a Particular Role
Exploration:
Some notes regarding the full list of action codes follows after this packet.
Asides from codes whose behaviors are unknown, some codes also have unknown data format.
No information for codes 1, 5, 9, 27, or 35 has been found yet.
the purpose of this packet; also decides the content of the parameter fields
na
na
the optional String parameter
the first optional Int parameter;
will not necessarily conform to a single bit length
the second optional Int parameter
the first optional Long parameter;
will not necessarily conform to a single bit length
the second optional Long parameter
the optional Boolean parameter
Define three fields determining the purpose of data in this listing.
The third field unk3 is not always be defined and will be supplanted by the squad (definition) GUID during initialization and a full update.
Actions:
unk1 unk2 unk3
0 true 4 -- Remove a squad from listing
128 true 0 -- Update a squad's leader
128 true 1 -- Update a squad's task or continent
128 true 2 -- Update a squad's size
129 false 0 -- Update a squad's leader or size
129 false 1 -- Update a squad's task and continent
131 false X -- Add all squads during initialization / update all information pertaining to this squad
Define three fields determining the purpose of data in this listing.
The third field unk3 is not always be defined and will be supplanted by the squad (definition) GUID during initialization and a full update.
Actions:
unk1 unk2 unk3
0 true 4 -- Remove a squad from listing
128 true 0 -- Update a squad's leader
128 true 1 -- Update a squad's task or continent
128 true 2 -- Update a squad's size
129 false 0 -- Update a squad's leader or size
129 false 1 -- Update a squad's task and continent
131 false X -- Add all squads during initialization / update all information pertaining to this squad
na
na
na; not always defined
information pertaining to this squad listing
Maintains squad information changes performed by this listing.
Maintains squad information changes performed by this listing. Only certain information will be transmitted depending on the purpose of the packet.
the name of the squad leader as a wide character string, or None if not applicable
the task the squad is trying to perform as a wide character string, or None if not applicable
the continent on which the squad is acting, or None if not applicable
the current size of the squad, or None if not applicable;
"can" be greater than capacity, though with issues
the maximum number of members that the squad can tolerate, or None if not applicable;
normal count is 10;
maximum is 15 but naturally can not be assigned that many
a GUID associated with the squad, used to recover the squad definition, or None if not applicable;
sometimes it is defined but is still not applicable
An indexed entry in the listing of squads.
Squad listing indices are not an arbitrary order.
An indexed entry in the listing of squads.
Squad listing indices are not an arbitrary order.
The server communicates changes to the client by referencing a squad's listing index, defined at the time of list initialization.
Once initialized, each client may organize their squads however they wish, e.g., by leader, by task, etc., without compromising this index.
During the list initialization process, the entries must always follow numerical order, increasing from 0.
During any other operation, the entries may be prefixed with whichever index is necessary to indicate the squad listing in question.
the index of this listing; first entry should be 0, and subsequent valid entries are sequentially incremental; last entry is always a placeholder with index 255
the data for this entry, defining both the actions and the pertinent squad information
na
na
na
na
na
Storm data.
Storm data.
the location of the storm;
the z-component is always 0.0f
na
na; 100 is about 819.2
na
na
the x-coordinate of this point
the y-coordinate of this point
na; 1024.0f - 0.0f
na
na
na
Set style properties for the line segemnt(s) to be drawn.
Set style properties for the line segemnt(s) to be drawn. Color and thickness can not vary within a given line and will only apply to the subsequent line segments. Attempting to list a change in between coordinate points will invalidate that segment.
the line width in pixels; 0.0f - 16.0f; 3.0f is about normal and 0.0f is smaller than the map grid lines
the color of the line; 0 is gray (default); 1 is red; 2 is green; 3 is blue
An entry regarding a target's health and, if applicable, any secondary defensive option they possess, hitherto, "armor."
An entry regarding a target's health and, if applicable, any secondary defensive option they possess, hitherto, "armor."
the target
the amount of health the target has, as a percentage of a filled bar scaled between 0f and 1f inclusive
the amount of armor the target has, as a percentage of a filled bar scaled between 0f and 1f inclusive; defaults to 0f
An entry regarding a specific target.
An entry regarding a specific target.
the target
na
Dispatched by the client when the advanced targeting implant activates to collect status information from the server.
This packet is answered by a TargetingInfoMessage with List entries of thed corresponding UIDs.
Dispatched by the client when the advanced targeting implant activates to collect status information from the server.
This packet is answered by a TargetingInfoMessage with List entries of thed corresponding UIDs.
a List of targets
Dispatched by the server to update status information regarding the listed targets.
This packet is often in response to a client-sent TargetingImplantRequest packet, when related to the implant's operation.
Dispatched by the server to update status information regarding the listed targets.
This packet is often in response to a client-sent TargetingImplantRequest packet, when related to the implant's operation.
It can also arrive independent of a formal request and will operate even without the implant.
The enumerated targets report their status as two "progress bars" that can be empty (0f) or filled (1f).
When this packet is received, the client will actually update the current fields associated with those values for the target.
For example, for 0x17 player characters, the values are assigned to their health points and armor points respectively.
Allied player characters will have their "progress bar" visuals updated immediately;
the implant is still necessary to view enemy target progress bars, if they will be visible.
This function can be used to update fields properly.
The value between 0 and 255 (0f to 1f) can be inserted directly into ObjectCreateMessage creations as it matches the scale.
The target will be killed or destroyed as expected when health is set to zero.
a list of targets
Sets Auraxis time for a continent (zone) on the client.
Sets Auraxis time for a continent (zone) on the client.
Use the slash-command /time to view the current time in the event window.
Auraxis time is represented as a standard military twenty-four hour clock, displayed in hours and minutes.
Time is set per zone on map loading.
Time affects, primarily, ambient light on surfaces.
It goes from full daylight, to twilights, to slightly darker nights, though the actual intensity will differ by zone.
Auraxis time is weird.
The data from the server is deconstructed into both a current time and a rate of progression.
The lower the value, the lower the rate; the greater the value, the greater the rate.
The rate is the product of the number of "cycles" between the current time and an origin time and a base interval.
The current time is constrained to a looping twenty-four hour interval.
If no time is set, the client starts counting from 10:00 at an initial rate of about one Auraxis minute every four or five real seconds.
Setting the current time to 1107296256 sets the current time to 00:00 with an indeterminate, but slow, rate.
Time is normally initialized somewhere within an interval between 1174405120 and 1207959296.
Setting the current time extremely high (near the numerical maximum) can cause psychedelic rendering.
(Setting the time to 4294967040 exactly will reduce the rendering system to gibberish.)
The interval from 1178164736 (~03:18) to 1203765248 (03:18) is about a full twenty-four hours.
That is a count of 25600512.
Auraxis time
consistently 1092616192; does nothing?
Dispatched when the player wants to go to the training zones.
Dispatched when the player wants to go to the training zones.
When a player enters the virtual reality hallways behind sanctuary spawn rooms and walks to the base of the ramp, he is presented with a prompt.
From the prompt, the player accepts either "Shooting Range" or "Vehicle Training Area."
Both sets of training zones utilize the same map for their type - map14 for shooting and map15 for vehicles.
The factions are kept separate so there are actually six separated zones - two each - to accommodate the three factions.
There is no global map notation, i.e., map##, for going to a faction-instance training zone map.
The zone modifier is used in conjunction with the LoadMapMessage packet to determine the faction-instance of the training map.
Players are sent to their respective empire's area by default.
A TR player utilizing the virtual reality hallway in the NC sanctuary and will still only be offered the TR virtual reality areas.
Black OPs do not have normal access to virtual reality areas.
Zone:
17 - 11 - TR Shooting Range
18 - 12 - NC Shooting Range
19 - 13 - VS Shooting Range
20 - 14 - TR Vehicle Training Area
21 - 15 - NC Vehicle Training Area
22 - 16 - VS Vehicle Training Area
the virtual reality zone to send the player
na; always 0?
Dispatched by the server to cause a client to display a special graphical effect.
The effect being triggered can be based around a specific game object or replayed freely, absent of an anchoring object.
Dispatched by the server to cause a client to display a special graphical effect.
The effect being triggered can be based around a specific game object or replayed freely, absent of an anchoring object.
If object-based then the kinds of effects that can be activated are specific to the object.
If unbound, then a wider range of effects can be displayed.
Regardless, one category will rarely ever be activated under the same valid conditions of the other category.
For example, the effect "on" will only work on objects that accept "on" normally, like a deployed motionalarmsensor.
The effect "spawn_object_effect" can be applied anywhere in the environment;
but, it can not be activated in conjunction with an existing object.
an object that accepts the effect
the name of the effect
na; when activating an effect on an existing object
an optional position where the effect will be displayed; when activating an effect independently
Dispatched by the server to render a "damage cloud" around a target.
Exploration:
This is not common but it happened while on Gemini Live.
Dispatched by the server to render a "damage cloud" around a target.
Exploration:
This is not common but it happened while on Gemini Live.
Why does it happen?
na;
usually 2;
when 2, will generate a short dust cloud around the target_guid;
if a player, will cause the "damage grunt animation" to occur, whether or not there is a dust cloud
the target around which to generate the temporary damage effect
na; usually 5L
Dispatched by the server to cause a sound to be played at a certain location in the world.
Dispatched by the server to cause a sound to be played at a certain location in the world.
the kind of sound
the location where the sound gets played
na; may be radius
the volume of the sound at the origin (0.0f - 1.0f)
na
na
na;
true to apply the effect usually
na
Activate an effect that is not directly associated with an existing game object.
Activate an effect that is not directly associated with an existing game object. Without a game object from which to inherit position and orientation, those explicit parameters must be provided.
the position in the game world
the angle of orientation
Dispatched by the client when its player is done using something.
The common example is sifting through backpacks, an activity that only one player is allowed to do at a time.
Dispatched by the client when its player is done using something.
The common example is sifting through backpacks, an activity that only one player is allowed to do at a time.
When a backpack is accessed by one player, other players are blocked.
When the first player is done accessing the backpack, this packet informs the server so other players may be allowed access.
the player
the item
(Where the child object was before it was moved is not specified or important.)
(Where the child object was before it was moved is not specified or important.)
the player
the item used; e.g. a REK to hack or a medkit to heal.
the object affected; e.g., door when opened, terminal when accessed, avatar when medkit used
na;
when upgrading phalanx turrets, 1 for AVCombo and 2 for FlakCombo
using tools, e.g., a REK or nano-dispenser
seems to be related to T-REK viruses. 0 - unlock all doors 1 - disable linked benefits 2 - double ntu drain 3 - disable enemy radar 4 - access equipment terminals
na
na; 25 when door 223 when terminal
na; 0 when door 1 when use rek (252 then equipment term)
the object id object_guid's object
Definition.ObjectId
TurretUpgrade
Dispatched to report and update the operational condition of a given vehicle.
Dispatched to report and update the operational condition of a given vehicle.
the vehicle
na
the xyz-coordinate location in the world
the orientation of the vehicle
optional movement data
flight information, valid only for a vehicle that can fly when in flight;
Some(7), when in a flying state (vertical thrust unnecessary to unlock movement)
None, when landed and for all vehicles that do not fly
na
na
for ground vehicles, whether and how much the wheels are being turned; 15 for straight; 0 for hard right; 30 for hard left; values in between are possible; vehicles that hover also influence this field as expected
na - Possibly a flag to indicate the vehicle is attached to something else e.g. is in a galaxy/lodestar cargo bay
vehicle is cloaked
PlacementData
Dispatched by the client of a driver who is involved in a collision with another vehicle that has no driver.
Dispatched by the client of a driver who is involved in a collision with another vehicle that has no driver.
May be supplemented with GenericCollisionMsg packets that call out both vehicles.
Multiple packets may be generated for a single event representing either
entanglement, escalation, or a lack of resolution.
the vehicle that was collided with
the player who drove into the vehicle
the xyz-coordinates of the displaced collision vehicle in reference to the player's client
the orientation of the displaced collision vehicle in reference to the player's client
optional velocity (unknown)
na
na
Indicate coordinates on the tactical map.
Indicate coordinates on the tactical map. Any adjacent sets of coordinates will be connected with a line segment.
the x-coordinate of this point
the y-coordinate of this point
Used by PlanetSide in conjunction with wiredred/pscs.exe to establish local platoon/squad voice chat.
Used by PlanetSide in conjunction with wiredred/pscs.exe to establish local platoon/squad voice chat.
We are not focusing on implementation of this feature.
This packet should not be generated because VoiceHostRequest will be ignored.
the player who sent this info (the originator of voice chat?)
everything else
Used by PlanetSide in conjunction with wiredred/pscs.exe to establish local platoon/squad voice chat.
Used by PlanetSide in conjunction with wiredred/pscs.exe to establish local platoon/squad voice chat.
We are not focusing on implementation of this feature.
As a precaution, all attempts at sending VoiceHostRequest should be replied to with a VoiceHostKill.
This packet seems to publish no data.
Used by PlanetSide in conjunction with wiredred/pscs.exe to establish local platoon/squad voice chat.
Used by PlanetSide in conjunction with wiredred/pscs.exe to establish local platoon/squad voice chat. We are not focusing on implementation of this feature. At the most, we will merely record data about who requested it.
na
the player who sent this request
everything else
Alert the server that a player wishes to engage in warp gate transport.
This packet is dispatched after a player interacts with the transportation beam in the center of a warp gate.
Alert the server that a player wishes to engage in warp gate transport.
This packet is dispatched after a player interacts with the transportation beam in the center of a warp gate.
The player has either chosen a destination from the Interstellar Map or was assigned a fixed destination.
When the the destination is limited to a specific continent and warp gate - "fixed" - the destination fields can be blanked.
Otherwise, they must be specified.
The process of gate transportation should not start until the server responds to this packet.
Exploration 1:
Does this packet apply to geowarp transport as well?
the continent (zone)
the warp gate
the destination warp gate
the destination continent (zone)
na; always zero?
na; always zero?
Alert the condition of a vehicle the player is using when going too far underwater.
Alert the condition of a vehicle the player is using when going too far underwater. The player must be mounted in/on this vehicle at start time for this countdown to display.
the player's mounted vehicle
the remaining countdown; for vehicle waterlog condition, the progress per second rate is very high
show a new countdown if true (resets any active countdown);
clear any active countdowns if false;
defaults to true
The position of a waypoint in the game world.
The position of a waypoint in the game world. Only two coordinates are required as the beam travels from a specific height to ground level.
the x-coordinate of the waypoint
the y-coordinate of the waypoint
WeaponDelayFireMessage seems to be sent when a weapon has a delayed projectile after firing, such as the knife.
WeaponDelayFireMessage seems to be sent when a weapon has a delayed projectile after firing, such as the knife.
See PlayerStateMessageUpstream for explanation of seq_time.
Instructs client to play a weapon's dryfire sound when sent server to client.
Instructs client to play a weapon's dryfire sound when sent server to client.
The particular sound played depends on the type of weapon that the guid is (likely from adb gamedata). See also WeaponJammedMessage
the weapon that is dry firing
WeaponFireMessage seems to be sent each time a weapon actually shoots.
WeaponFireMessage seems to be sent each time a weapon actually shoots.
See PlayerStateMessageUpstream for explanation of seq_time.
Always zero from testing so far
Seems semi-random
Seems semi-random
Maximum travel distance in meters - seems to be zero for decimator rockets
Possibly always 255 from testing
0 for bullet 1 for possibly delayed explosion (thumper alt fire) or thresher/leviathan flux cannon 2 for vs starfire (lockon type?) 3 for thrown (e.g. grenades)
Seems to be thrown weapon velocity/direction
Instructs client to play the weapon jammed sound when sent server to client.
Instructs client to play the weapon jammed sound when sent server to client.
Appears to have the same functionality and sound regardless of guid, as long as the client has that item in inventory. See also WeaponDryFireMessage
the weapon that is jammed
Dispatched to the server when a position is being marked by a laze pointer tool.
When the laze tool is used, a progress bar window is displayed, along with the text "Acquiring Target Position."
The player using the tool constantly sends packets to the server for as long as the progress bar is filling.
Dispatched to the server when a position is being marked by a laze pointer tool.
When the laze tool is used, a progress bar window is displayed, along with the text "Acquiring Target Position."
The player using the tool constantly sends packets to the server for as long as the progress bar is filling.
In all, about fifty packets are sent.
(Measured during low-load testing.
The actual number of packets may be related to network load.)
While firing, the player's movement is locked for the duration.
The weapon fire can be aborted at any time, returning control.
the laze pointer tool
the position of (the player holding the) laze pointer
position of the tip of the laze pointer's beam, or where it intersects something
Dispatched by the server to update weather conditions.
Dispatched by the server to update weather conditions.
On former live (Gemini), the server sent a new packet to connected clients once every ~60s.
Information about the fields in this packet come from extracted debug information.
It is not necessarily "correct" but it is the best approximation for now.
Message type: %d (%s)\n length: %d\n
Number of Clouds : %d\n
Cloud ID: %d\n
\tCloud Location: %f %f\n
\tCloud Velocity: %f %f\n
Number of Storms : %d\n
Storm:\n
\tStorm Location: %f %f\n
\tStorm Intensity: %d\n
\tStorm Radius: %d\n
a list of cloud data; typically, just one entry
a list of storm data; typically, fluctuates between nine and eleven entries
Dispatched by the client when the player is interacting with a zip line.
Dispatched by the client when the player is interacting with a zip line.
Dispatched by the server to instruct the client to use the zip line.
Cavern teleportation rings also count as "zip lines" as far as the game is concerned, in that they use this packet.
Action:
0 - Attach to a node
1 - Arrived at destination
2 - Forcibly detach from zip line in mid-transit
the player
whether this corresponds with the "entry" or the "exit" of the zip line, as per the direction of the light pulse visuals
how the player interacts with the zip line
a number that is consistent to a terminus
the coordinates of the point where the player is interacting with the zip line; "optional," in theory
Dispatched to the client in regards to cavern connections via geowarp gates.
Dispatched to the client in regards to cavern connections via geowarp gates.
the zone
na
Change the "Empire Status" text in the Interstellar Map zone description for the specified zone.
Change the "Empire Status" text in the Interstellar Map zone description for the specified zone.
The Empire Incentives window also displays the changed information.
The Long value is applicable to the caverns.
It indicates how long the given cavern will remain locked until at least one of their geowarps will open during normal rotation.
As thus, when a cavern has its status as "inactive," this number will always be a non-zero.
On normal continents, this number is always zero, though a non-zero number will not have any effect anyway.
the zone id
true displays the queue availability for the avatar's empire;
false displays "Inactive"
how long until the continent naturally unlocks (in ms); only applicable to caverns
ZonePopulationUpdateMessage for information on population and queues
Change the "Empire Status" text in the Interstellar Map zone description for the specified zone.
Change the "Empire Status" text in the Interstellar Map zone description for the specified zone. The Empire Incentives window also displays the changed information.
the zone id
true displays "Locked;"
false displays the queue availability for the avatar's empire
na;
usually true
Report the raw numerical population for a zone (continent).
Populations are displayed as percentages of the three main empires against each other.
Report the raw numerical population for a zone (continent).
Populations are displayed as percentages of the three main empires against each other.
Populations specific to a zone will be displayed in the Incentives window for that zone.
Populations in all zones will contribute to the Global Population window and the Incentives window for the server.
The Black OPs population does not show up in the Incentives window for a zone but will be indirectly represented in the other two windows.
This packet also shifts the flavor text for that zone.
The size of zone's queue is the final upper population limit for that zone.
Common values for the zone queue fields are 0 (locked) and 414 positions.
When a continent can not accept any players at all, a lock icon will appear over its view pane in the Interstellar View.
Setting the zone's queue to zero will also render this icon.
The individual queue fields set the maximum empire occupancy for a zone that is represented in the zone Incentives text.
Common values for the empire queue fields are 0 (locked population), 138 positions, and 500 positions.
Zone Incentives text, however, will never report more than a "100+" vacancy.
The actual limits are probably set based on server load.
The latter queue value is typical for VR area zones.
The value of the zone queue trumps the sum of all individual empire queues.
Regardless of individual queues, once total zone population matches the zone queue size, all populations will lock.
For normal zones, if the individual queues are not set properly, whole empires can even be locked out of a zone for this reason.
In the worst case, other empires are allowed enough individual queue vacancy that they can occupy all the available slots.
Sanctuary zones possess strange queue values that are occasionally zero'd.
They do not have a lock icon and may not limit populations the same way as normal zones.
the continent
the maximum population of all three (four) empires that can join this zone
the maximum number of TR players that can join this zone
the current TR population in this zone
the maximum number of NC players that can join this zone
the current NC population in this zone
the maximum number of VS players that can join this zone
the VS population in this zone
the maximum number of Black OPs players that can join this zone
the current Black OPs population in this zone
The purpose of the BindPlayerMessage packet.
Bind and Unbind are generally manual actions performed by the player.
The purpose of the BindPlayerMessage packet.
Bind and Unbind are generally manual actions performed by the player.
Available is applied to automatic Advanced Mobile Spawn points and other "Bound" points at the time of redeployment.
Lost and Unavailable remove the status of being bound and have slightly different connotations.
Each generates a different a events chat message if logging it turned on.
An Enumeration of the kinds of bugs applicable to the reporting system.
An Enumeration of the valid chat channels.
An Enumeration of the various states a Player may possess in the cycle of nanite life and death.
An Enumeration for the forms of the event chat message produced by this packet.
An Enumeration of the map element icons that can be displayed based on the type of deployable item.
An Enumeration of the actions that can be performed upon a deployable item.
A Codec for the actions that each layer of the diagram performs.
A Codec for the actions that each layer of the diagram performs.
Style, Vertex, Action5, DrawString, and Action7 have additional DiagramStroke input data.
An Enumeration of the various states and activities of the hacking process.
An Enumeration of the various states and activities of the hacking process.
These values are closely tied to the condition of the hacking progress bar and/or the condition of the hacked object.
Start initially displays the hacking progress bar.
Ongoing is a neutral state that keeps the progress bar displayed while its value updates. (unconfirmed?)
Finished disposes of the hacking progress bar. It does not, by itself, mean the hack was successful.
Hacked modifies the target of the hack.
HackCleared modifies the target of the hack, opposite of Hacked.
An Enumeration for all the actions that can be applied to implants and implant slots.
An Enumeration Codec that represents that various states of a major facility's Generator.
An Enumeration of the slots for award ribbons on a player's RibbonBars.
An Enumeration of the sounds triggered by this packet.
An Enumeration of the sounds triggered by this packet.
Twenty-one possible sounds are available for playback.
na
na
na
na