Supporting Tacview Natively

Tacview can be natively supported by any simulator, game, or training system able to export telemetry.

A basic implementation can be simple: record the objects present in the simulation, save their position and state over time, then export the result as an ACMI file. From there, the integration can grow step by step with more objects, events, weapons, sensors, terrain, textures, 3D models, and real-time telemetry.

Native Tacview support can be added early during development, or later when the simulator is more mature. Both approaches are common. Early support has an extra advantage: Tacview can immediately become a practical debugging and validation tool for the development team.

Why Support Tacview?

Tacview is often seen as a debriefing tool for players, pilots, instructors, and analysts. But it is also useful during development.

A Tacview recording can help developers and mission designers see what happened across the whole battlefield, not only from one cockpit or one in-game map. This can be useful to debug AI behavior, mission logic, weapons, sensors, multiplayer synchronization, and unexpected gameplay situations.

ACMI files can also be attached to bug reports. Instead of relying only on screenshots, videos, or text descriptions, testers and users can provide a compact recording of the situation.

Telemetry can also contain custom properties and events for internal debugging. For example, a simulator can export AI state, decision markers, mission triggers, sensor state, or other useful information without changing the normal debriefing workflow.

Real-time telemetry can later be used to monitor a mission while it is running, debug mission creation, validate AI behavior, or observe a simulation from an external review station.

Recommended Integration Path

Tacview support is modular. It does not have to be implemented all at once.

A typical integration can be developed in the following order:

Export a basic ACMI file with time, object ids, positions, names, and types.
Add object orientation, coalitions, colors, pilots, and life cycle events.
Add weapons, sensors, events, and simulator-specific data.
Optimize the export rate and data size.
Add terrain elevation, terrain textures, 3D models, and database entries when needed.
Optionally add real-time telemetry over TCP.

This makes it possible to start with a useful prototype, then improve accuracy, readability, and performance over time.

Minimum Useful Telemetry

The most important requirement is to provide stable object ids.

Tacview supports 64-bit integer object ids. Each aircraft, vehicle, missile, projectile, ship, or static object should keep the same id for its whole lifetime in the recording.

A minimal useful export usually contains:

Recording time
Stable object ids
Object position
Object name or model, such as F-16C
Object type or category, such as FixedWing, Ground, Missile, or Ship
Object creation and removal

Additional data should be added progressively:

Object orientation
Coalition, team, or color
Pilot or player name
Weapons and shots
Sensors and locks
Mission events
Damage and destruction events
Custom properties for debugging

Tacview can estimate some information when it is missing, but explicit data is always better. Accurate orientation is especially important for dogfights, missiles, ships, ground vehicles, turrets, and sensors.

Generic velocity is not always required because Tacview can calculate it from position samples. However, simulator-native values such as IAS, CAS, Mach number, vertical speed, engine state, fuel state, or AI state can be very useful when they are available.

Coordinates and World Representation

Tacview ultimately needs geographic coordinates: longitude, latitude, and altitude.

For real-world simulators, exporting the real geographic position is usually the best choice.

For fictional or flat worlds, the simulator can emulate longitude, latitude, and altitude using a stable mapping. If the world has no intended real location, an isolated ocean area near the equator can be a practical default.

When possible, documenting the coordinate conversion helps preserve accuracy and makes future improvements easier.

If several theaters or maps are supported, each one should have a unique Theater. It is a good idea to define one from the start, even when the simulator has only one map. This avoids future conflicts with DLCs, mods, test maps, or later expansions.

An accurate recording date and time helps Tacview display the sun at the correct position. This can matter for visibility, shadows, IR missiles, sensors, and comparison with simulator footage. For fictional worlds, the date and time can simply be chosen to match the simulator lighting.

Terrain, Textures, 3D Models, and Database

Telemetry alone is enough to create a useful first integration.

Later, the experience can be improved with:

Terrain elevation
Terrain textures or imagery
Low-poly 3D models
Static objects
Database entries for simulator-specific objects

Small or fictional worlds can often be described with simple custom terrain and texture declarations. Larger worlds can use tiled elevation and texture data.

Custom database entries are useful when the simulator contains fictional aircraft, vehicles, weapons, sensors, or other objects unknown to Tacview.

Data Size and Export Frequency

A first prototype does not need to be perfectly optimized.

Once the exported telemetry is correct, it is worth reducing the amount of data written to disk. This usually means choosing a reasonable export frequency and avoiding repeated data when values have not changed.

A clean export can remain compact even for long missions, while still preserving all useful information for debriefing and debugging.

Real-Time Telemetry

Real-time telemetry is optional.

It is essentially the same ACMI telemetry stream sent over a TCP connection. It can be added after the ACMI file export is working and can usually reuse the same telemetry generation code.

Real-time telemetry is useful for live monitoring, instructor stations, mission debugging, and external tools. The simulator only needs to start streaming when a Tacview telemetry client connects.

We Can Help

The Tacview team can help studios implementing native support.

We can answer technical questions, review early ACMI files, help validate coordinates and object behavior, and suggest the best integration path for each simulator.

When a studio is actively implementing native Tacview support, we can also provide development licenses so the team can test and debug the integration with the appropriate Tacview tools.

For technical questions, examples, or validation, please contact us by email.