What is an XML debriefing?

In overall, an XML debriefing is an XML file which describes all events like the ones we can see in Tacview flight-log window. This is a great tool for squadrons or single pilots who want to generate statistics about previously flown missions.

In itself, an XML debriefing does nothing. It is just a plain data file. You have to use or develop a tool which will read it and compile statistics (or any other information you need) into useable and displayable information for your squadron.

Please remember that some information may not be always available. For instance, Lock-On 1.1 does not export data about unguided weapons. This is why Tacview is not able to neither display nor export any information related to bombs, rockets and shells from Flaming Cliffs. However other flight simulations supported by Tacview may export theses data so they should be available to you thought XML debriefings.

Here a raw XML debriefing sample: Tacview-Demo-Ironhand-A-10A-M02.xml

Is there any tool to manage XML debriefings?

PHPTacview

Before starting to work from scratch on a whole new program, I suggest you to have a look first at Ezor's flight events log viewer written in PHP. It can already fulfill your objectives or act as a starting point for your own project. In any case this is a very interesting use of Tacview XML debriefing files.

PHPTacview is an open source project. As an external add-on for Tacview it is not supported.

NOTICE: PHPTacview was written for Tacview 0.85. In order to make it support latest versions of Tacview some modifications may be required.

XML Debriefing Technical Reference

Since XML debriefing file format evolve over time, the first thing to do is to ensure that the file version is supported by your tool before working with it. The file itself is composed of two headers followed by the objects list followed by the events list. Some components may be omitted if they are not available or applicable.

This header contains meta-data about the flight recording:

<Source> ... </Source>

This is the source flight simulator full name and version number if applicable. If the recording is from real life, then this should be the source aircraft name.

<Recorder> ... </Recorder>

Hardware or software flight recorder full name including its version number if applicable.

<RecordingTime> ... </RecordingTime>

Recording start time expressed in Coordinated Universal Time (UTC). The format is: YYYY-MM-DDThh:mm:ssZ. This is the effective real-life recording time, which is not necessarily the mission start time.

<Author> ... </Author>

Pilot or operator name. It can be in any format, including callsign, nickname and rank if applicable.

The second header contains data about the flight itself:

<Title> ... </Title>

Flight/Mission name. It can be of any form and length.

<Category> ... </Category>

Flight/Mission type. It can be of any form and length.

<MissionTime> ... </MissionTime>

Mission start time expressed in Coordinated Universal Time (UTC). The format is: YYYY-MM-DDThh:mm:ssZ. This is the true mission start time, which is not necessarily the recording start time.

<Duration> ... </Duration>

Total flight recording length in seconds.

<MainAircraftID> ... </MainAircraftID>

This ID is expressed as a 32bits unsigned decimal number. In fact, it can designate any unit in the mission: the local aircraft, the aircraft which records the mission, the aircraft which offers the most reliable data or simply what is considered as the main unit (e.g. an AWACS)...

<Briefing> ... </Briefing>
<Debriefing> ... </Debriefing>
<Comments> ... </Comments>

This is the usual information provided with any flight/mission. They are free text of any length which can be composed of any character including carriage return.

This is an abbreviated list which contains active objects only. Objects which are not referenced by any events are omitted.

Objects IDs are 32 bits unsigned decimal numbers. They are unique and never recycled. For instance, if a network player is killed then revived; his new aircraft will have a new ID. Obviously the pilot name will remain the same so you should not have any problem to properly assign statistics.

<Type> ... </Type>

The object type is expressed as a string and can be one of the following:

• Aircraft
• Helicopter
• SAM/AAA
• Tank
• Car
• Infantry
• Ship
• Carrier
• Ship
• Missile
• Rocket
• Shrapnel
• Shell
• Bullet
• Bomb
• Chaff
• Flare
• Airport
• Building

<Name> ... </Name>

The object name is the object NATO code when applicable.

<Pilot> ... </Pilot>

This is the pilot name when available. Sometime it can be the unit name.

<Coalition> ... </Coalition>

This is the object coalition name.

<Country> ... </Country>

This is the ISO 3166-1 alpha-2 object country code expressed in lower case.

<Parent> ... </Parent>

Parent ID which is usually used to associate a weapon (e.g. AIM-120C) to its parent (e.g. F-15C). A notable case is that cluster bombs (e.g. Mk20 Rockeye) can generate children objects.

<Group> ... </Group>

Object group name when applicable and available.

<Rank> ... </Rank>

Object rank in group when applicable. This is an integer code (from 1 to n) which specifies the object rank / order in the group. Each object in the group has a distinct rank order.

The following list contains all events like the ones you can see in Tacview flight log window:

<Time> ... </Time>

Time offset since the mission beginning (in seconds).

<Object> ... </Object>

Object ID which designate the object which has triggered this event.

<Action> ... </Action>

This is string which can be one of the following:

• HasEnteredTheArea
• HasLanded
• HasFired
• HasBeenHitBy
• HasBeenDestroyed
• HasTakeOff
• HasLeftTheArea

<SecondaryObject> ... </SecondaryObject>

When required this ID designate the secondary object associated to this event.

<Airport ID="..." > ... </Airport>
<Carrier> ... </Carrier>

Typically used for takeoff and landing events when the secondary object is an airport or an aircraft carrier. This node contains airport/carrier name. Airport ICAO or IATA code can also be stored in the ID attribute when available.

<OccurenceCount> ... </OccurenceCount>

Event occurrences count. Typically used when firing one type of weapon multiple times in a row. This parameter is very useful to reduce event log size.