Tacview Wiki
Advertisement

Some of you may have noticed that, in some circumstances, you can lose precious fps while recording your flight within DCS World. This could be particularly annoying on low end computers as well as on VR setups where each frame per second matter.

Why is that?[]

To record the telemetry, Tacview uses the official Lua script interface provided by DCS World via the Export.lua script. More specifically, the LoGetWorldObjects() function which gives the list of all dynamic (a well as a few static) objects currently active in the mission.

All is well until you run a mission with thousands of active objects (including aircraft, SAMs, vehicles, missiles, to name a few). In that case, LoGetWorldObjects() could be quite inefficient and can slow down the whole simulation.

How can a modern computer be so slow at enumerating a few thousand objects? I believe this comes down to the way the Lua language is working. Imagine that each frame, via LoGetWorldObjects(), you request the full list of dynamic objects, and for each of them, their ID, name, country, detailed coordinates (such as latitude, longitude, altitude…), so on. This could easily mean more than 15000 samples of data. In this example, we can ignore bullets which are numerous but sporadic over a four-hour mission.

That would not be a problem for the usual C++ program, but in that case, creating a full list from scratch of 10000+ samples of data going through Lua, is kind of devastating for the CPU. Because this requires a log of memory allocation/free and copy operations.

In the end you may notice stuttering or overall lower performance depending on your system and the size (in objects) of the mission.

Can’t this be fixed?[]

Short answer: not easily.

Long answer:

Unfortunately, the problem lies in the way DCS World enumerates active objects and gives them to Tacview via Lua.

On one hand you have Tacview exporter which is now fully written in multithreaded C++, it uses less than 1% of CPU on the main thread, and all the rest (such as telemetry fusion, data cleanup, zip compression, real-time telemetry over the network) is handled on background threads at a cost which is considered negligible.

On the other hand, you have the infamous LoGetWorldObjects() function: There is no way around it, it is the only way to request objects, it is not possible to split it over several frames, and it is probably the most inefficient way to enumerate a lot of objects.

The only way to fix this would be for DCS World to offer a new API, which could be more selective, progressive, and efficient in the way objects are enumerated. That way its load would be minimal and spread over several frames.

While working on Tacview 2, I am thinking about a better way of enumerating objects. When I will believe I have found a clean and efficient solution, I will propose it to Eagle Dynamics so they can upgrade DCS export API. Not only this will help with Tacview export, but this will also benefit to any add-ons such as LotAtc.

Is it possible to avoid this problem in the first place?[]

Right now, there are several ways to mitigate this issue, while still enjoying the game.

Export tracks (*.trk) files recorded by DCS World[]

DCS can record a track file for each of your flights. As a matter of fact, it is mandatory during multiplayer games.

The good thing about this is that you can, for example, disable Tacview exporter during your multiplayer flight, and then export the DCS *.trk file later, with the exporter enabled.

There are two downsides to this method:

  • It takes time to replay the track file
  • Track files are not reliable, and DCS replay can diverge from the original flight, especially if the mission is long.

Record local aircraft only[]

If you go in the special options of DCS World for Tacview, you will find an option to record only the local aircraft depending on the kind of flight you are doing.

Technically this means that the exporter will only record your aircraft data (via the Lua function LoGetSelfData() ). Which means there will be no impact on the frame rate (only one object is recorded), and you will still be able to analyze your own personal data such as performance, fuel consumption, landing, navigation...

There are two downsides of this method:

  • You cannot see any other object of the map
  • You cannot see your own weapons (they are not part of your aircraft!)

Record only on server and share the files via the cloud[]

A popular method on private dedicated servers is to let the server record the flight data (check the dedicated options in DCS special options for Tacview). Meanwhile clients will not record any data or will record only their own aircraft data.

The server recording path (which can be defined via Tacview main application settings menu), can be redirected to a folder which is automatically sync'd on a cloud service such as a Google Drive for example. That way players can download their flights after a mission.

The frame rate impact on the server is not relevant since servers already save a lot of CPU time by not rendering any 3D. As long as your server runs at something like 60 fps you should be perfectly fine.

There are two downsides of this method:

  • Since this could be used for cheating, is it recommended only for private servers
  • The server cannot record any advanced telemetry because it is available only via the cockpit of each player

So, what should I do?[]

Personally, when I play in VR with friends online, on a private server, we do the following:

  • The dedicated server is recording the mission
  • On my side I like to record my own data only (so I can still analyze my own aircraft performance data)
  • When it is time to debrief, we share the file generated by the server

That way I can still get maximum fps in VR, while enjoying a nice online debriefing after the mission with my friends.

Advertisement