Updated on 2019-05-23, viewed 6079 times

Tacview 2.0 – ACMI flight recordings

DRAFT v2.2: The following specifications are subject to change.

Legacy & Future

The goal of the following draft is to present the new 2.0 acmi file format which will provide a cleaner, simpler and yet more powerful way to record telemetry data to be reviewed after a flight or in real-time in Tacview. This new format will be accessible to beginners while remaining powerful and modular to fit the specific needs of advanced users.

The following work is based on about 10 years of experience and feedback from the community. Even if the current file format is quite powerful, it is not easy to understand and to use by beginners and it does not provide the real-time and out-of-order functionalities required to reach the next level of data analysis.

Simple & smart

The new format specification is fully public and will be used to exclusively produce text data. Tacview will not produce binary files anymore. That way it will be much easier for users to tweak, inject, and debug any data even after being exported by Tacview main application. If at any time Tacview detects an error or notice something strange in the provided data, it will display an appropriate notification in the debug log introduced in Tacview 1.4.2.

The new telemetry engine will interpret strictly and smartly any data injected thru the new file format. Out-of-order data as well as merge from different sources will be natively supported. Any missing data will be dynamically and smartly interpolated, extrapolated or replaced based on past, current and future data injected in the engine.

As a matter of fact, with the new engine, it will be possible to improve the quality of existing data by merging complementary source of data (like cockpit information coming from each member of the same squadron). Everything will be done in background while reviewing the flight. No more down time: The user will be able to start the debriefing while files are being loaded and processed in background. Amongst other things, this behavior naturally enables real-time flight analysis over a network connection.

Performance

Because it is not necessary anymore to declare types and because each file will be text only, the new format will be easy and efficient to output from any language, especially for limited ones like LUA script.

To save as much network or storage space as possible, generated data can optionally be compressed in a zip or 7z archive. Tacview will compress any exported data in a clean and compact 7z archive which can be later opened and analyzed by a non-programmer using any mainstream decompression tool.

Hello world!

To demonstrate how the new format is simple to understand and use, here is a simple hello world file:

FileType=text/acmi/tacview
FileVersion=2.0
0,Comment=Hello world!

Aside the obvious file type and version declaration, everything in the file is optional. In this example, we have just added a comment Hello world! which will be displayed in the event log. Tacview will just display an empty world using the date of the file as a reference point in time.

Let's see how this hello world line is structured:

0,

Almost each line is starting with an object id. Comments can be assigned to any object in the world. In this case, we have assigned a comment to the object zero (id #0) which represents the world and which is always available.

Comment=

The object id must be followed by the name of a property we want to change the value. In this case, we want to assign a text to the property Comment which will then be displayed in the event log and can be used, for example, to help with the debug of a flight data recording.

Hello world!

Since the file is in UTF-8 format, you can use any non-roman character, they will be properly displayed by Tacview. (note that some characters may not be supported yet in Tacview 1.x 3D view)

As you can see, it is possible to inject just very few data in the new telemetry engine and yet have a valid flight recording. On the other hand, you are going to see that it is now possible to provide much more data than before if required...

Adding some telemetry

Now let's put an aircraft in the sky!

FileType=text/acmi/tacview
FileVersion=2.0
3000100,C=-116.46811942491|37.338314828045|1997.6|0|.3|63.8

Even if it is very concise, this file is perfectly valid and will be interpreted as well as possible by the new telemetry engine. You can see here the declaration of an object position. We did not specify what the object is and we did not specify a date and time, but there is already enough information to display something on screen.

Let's have a look at these fields:

3000100,

As in the previous example, this line begins with the id of the object we want to update, in that case we want to update the object #3000100. Object ids can be 64-bit and recycling is smartly supported. Objects declarations are now implicit. This simplifies the exporter code while reducing the file size.

C=

The C telemetry identifier is used to introduce complex object transform data. In other words, this declares an object position, rotation in spherical and flat worlds as required. There are several format for this identifier which will be discussed later.

-116.46811942491|37.338314828045|1997.6|0|.3|63.8

Here we are declaring the object position and rotation.

  • -116.46811942491 is the longitude
  • 37.338314828045 is the latitude
  • 1997.6 is the object altitude in meters
  • The last three values are the roll, pitch and yaw angles

So the aircraft is somewhere over the Nevada desert. In this case, the aircraft is heading toward 63.8 degrees to the North/East.

Core specifications

All data is stored in UTF-8 text format. It can be encapsulated in a zip or 7z archive to save storage space or bandwidth. All data are expressed in the metric system; angles are in degrees to make the file easier to read. To save space, end-of-lines are marked by the LF character (Unix style). Tacview will ignore CR characters.

The online mandatory fields are the file header specifying the type and version of file:

FileType=text/acmi/tacview
FileVersion=2.0

The "frame" concept has been replaced by a time offset which can be specified using the sharp sign followed by a number of seconds relative to the mission time:

#0.00

Time offsets can be out-of-order, in that case the engine will do its best to appropriately reorder and merge data. They are relative to mission time. If no mission time has been provided, Tacview will use whatever data is available in that domain, like the current file date.

When an object id is prefixed by a minus sign, this indicates that the object has been removed from the battlefield (could be destroyed). Ids are 64-bit hexadecimal values which can be recycled. In case of recycling, it is important to not forget to remove the previous instance using the minus sign so Tacview knows that the new declaration is about a new object.

Each line can be an id followed by one or more fields of data separated by comas. Each field is identified by a normalized name followed by the equal sign, followed by values separated by vertical bar | (if applicable). If a text value contains any separator or backslash, they must be escaped using the backslash \ character.

The id=0 is special and represent any global data associated with the world or the flight. For example: Weather data, debriefing text, mission time, ... are all associated with the object #0.

All objects fields are dynamic. Which mean that it is possible, at any time, to change the collation of an object (for example a captured base), or the name of a pilot for example.

Putting everything together!

Here is an example of a more complete and typical file:

FileType=text/acmi/tacview
FileVersion=2.0
0,DataSource=DCS 2.0.0.48763
0,DataRecorder=Tacview 1.5
0,RecordingTime=2016-01-12T14:39:06Z
0,MissionTime=2011-06-02T20:00:00Z
0,LongitudeOffset=-121.46826042491
0,LatitudeOffset=32.338305828045
0,Coalition0Name=Allies
0,Coalition0Color=Red
0,Coalition1Name=Enemies
0,Coalition1Color=Blue
#0.00
3000100,Type=Vehicle Air Plane Attack,Coalition=Allies,Country=us,Name=A-10C,Pilot0=Vyrtuoz
3000100,C=5.000141|5.000009|1997.6|-146894.3|-277477.1|63.5|0|.3|63.8
#143.5
-3000100

It is usually handy to declare some meta data like how the flight was recorded and by which device. MissionTime is particularly important since it specify a reference which is used as a base for the subsequent time offsets expressed in seconds.

The LongitudeOffset and LatitudeOffset are optional. Thier default values are zero. These offset are added to each subsequent spherical coordinates. It is strongly encouraged to use these properties because they help to reduce the file recording size by about two characters per transform entry. For example, the effective spherical coordinates for the object 3000100 declared at 0.00 seconds are:

  • Longitude = 5.000141 + LongitudeOffset( -121.46826042491 ) = -116.46811942491
  • Latitude = 5.000009 + LatitudeOffset( 32.338305828045 ) = 37.338314828045

Which is somewhere over the Nevada desert...

As you can notice, object properties declaration are much more intuitive than before. You can specify a lot of data like the country, object name, pilots' names, ... With this new data engine, it is even possible to change these data on the fly! Which means that – for example – you could change the coalition of an object which has been captured.

Later at 143.5 seconds, you can see how an object is be removed from the battlefield. This is as simple as using the minus sign prefix. When no reason is specified, Tacview will do its best to guess why the object has been removed. When the information is available, it can be specified by using the object properties.