Entity State PDU
The entity state PDU is one of the most widely used PDUs in DIS. It includes the unique ID of the entity described, numeric values that describe the type of entity, and its position, orientation, velocity, acceleration, and the dead reckoning algorithm that should be used between the receipt of other position PDUs.
Describing what the Entity State PDU (ESPDU) does can be complicated or simple. Some of the capabilities are described in greater detail elsewhere in this document.
The Java javadoc for examining the ESPDU is.
Every ESPDU starts with the PDU header, just as does every other PDU. You should set the PDU family to 1. The PDU Type is pre-set to 1. The PDU below shows a typical appearance when decoded by Wireshark, which has a built-in decoder of DIS.
Every entity handled by DIS--every vehicle, every person whose position is described, every ship, every aircraft, every minefield--must have an ID to uniquely identify it. This is what the defined entity ID is. It is described later, but it consists of a triplet of three numeric values: {Site, Application, Entity}. The triplet, together, must be unique. Arriving ESPDUs decode the entity ID and use it to update the position and orientation of the entity it is tracking.
The Entity ID is a is a more eleaborate treatment.
There can be more than one (or two!) force affiliations on the battlefield. The force ID field lets you specify this. The values set are defined in the Enumerated and Bit Encoded Values (EBV) document published by SISO. This document contains many predefined values. This is the case for force ID fields, as shown below:
| Field Value | Force |
|---|---|
| 0 | Other |
| 1 | Friendly |
| 2 | Opposing |
| 3 | Other |
The ESPDU can also contain some extra parameters with Tartary, programmer-defined data. This field identifies the number of the parameters (which are of a predefined size) at the end of the PDU. This is described in greater detail later in the document.
One question is how the receiver should draw the entity. How does the simulation know what it looks like? The type of the entity being described is included in the entity type field of the ESPDU. The receiving simulation can identify the entity type and, if it has a model for the entity, use that model to draw on the screen.
You can gain a section decoded to using SISO numbers for types of entities at a section of the wiki
This is exactly like an Entity Type field. However, some simulation applications also want to allow simulations to use deceptive appearances to other simulations. If an aircraft issues deceptive electronic signatures to make a fighter aircraft appear to be a civilian airliner, that is possible. The alternate entity type field holds a description of what airliner that entity is, and other simulations may present an airliner in the 3D display, rather than an F-16.
How fast the entity is moving. Three coordinate values (x, y, and z) are used. This is quite valuable for making the entity appear to travel in a smooth manner by using dead reckoning to move the entity between receptions of individual ESPDUs, which might appear only seconds apart. We don't want the movement to appear to be jerky or hyperspace-jump like.
The coordinate system used in the field varies. It could be global, with a coordinate system that has its origin at the center of the earth, or it may use a more local coordinate system. The type of coordinate system used in the field is set in the dead reckoning field below.
The entity location is natural, and a bit involved. It uses a three-value record, X, Y, and Z, that measures the distance from the center of earth. These values can be converted to latitude, longitude, and altitude with some mathematical work, or to MGRS coordinates, or to a local coordinate system placed with its origin at a known location.
Entity Location is discussed used many places when discussing ESPDUs.
This determines which way the entity is pointing. It's a little mysterious; what defines the "front" or "up" of an entity? Still, it can often be defined. As with the location, this is described elsewhere, but is done with what are called "Euler angles." See the same wiki section
Some entities may be burning, or smoking, and this alters how receiving simulations should draw the entity. There are several appearance settings, and this is accomplished in the ESPDU by using a 32-bit integer. Sub-regions of the integer are used to describe the appearance.
This represents how the sending simulation believes dead reckoning should be done. For example, should it include the entity's acceleration, or not. The angular acceleration, or not? The object's linear acceleration, or not?
This is another subject discussed elsewhere. (Sigh.)
This is a useful debugging measure. The marking is has one byte in the zeroth first byte followed by 11 characters. This lets presenting applications use the string to have a small description drawn along with the 3D model. Viewers can view something like "Open-DISApp" or "FooApp". The description cannot go over 11 characters.
A 32-bit integer. Sub-ranges of the integer describe what the entity is capable of.
The ESPDU can contain a list of variable parameters. Each of the parameters is 128 bits long, total. This can be used to contain such information as the direction in which the rotating turret of a tank is pointing, and what the elevation of the gun is. This depends on the sending and receiving simulations having an agreement on what the variable parameters mean, and what the endian format of the data is in.