Track replays constantly do not work properly...

[Ballinger French]

Hi, I've experienced the same phenomenon over and over in DCS with both the older and newer versions of the A-10 series in regard to track replays.    Specifically, sometimes they work perfectly, whilst an equal number of times they function corruptly.    With corrupt experiences, the replay will show an aircraft attempting to target vehicles that don't exist, ignoring the actual targets attacked and destroyed during real-time missions.    Additionally, the flight path of the aircraft will very frequently be non-nonsensical, with my aircraft rolling inverted and crashing into the ground instead of replaying a level attack run to targets.   

 

I've experienced this for years now and just assumed track replays were buggy and unreliable, but I wanted to query other users on here to see if they experience the same kind of behavior.  

 

Thank you.   

Edited January 13, 2021 by Ballinger French

[Foka]

Just a DCS things...

[Yurgon]

My experience was that replays were sometimes good, sometimes bad when I recorded them on my very old PC, where the CPU and possibly the I/O was bottlenecked. With a newer PC, they started to work fine almost all the time, and I haven't had any problems in recent times, though I admit that I only record very short tracks for specific purposes nowadays, and not 2 hour long tracks to relive an earlier flight, as I did on my very old PC.

 

Since tracks are actually a replay of all recorded inputs into a mission, you can probably imagine that the slightest mistake during the recording, or during the replay, might throw the replay off the tracks.

 

I assume that a kind of snapshot system that saves the full state of the mission every couple of time-units would improve track reliability, but would blow up track sizes and require a lot more I/O, potentially degrading the actual game performance.

 

Fast forwarding during a mission or during track replay drastically increases the risk of replays going bad.

 

Video producers who use replays to create great looking videos, but who have problems with framerates, also sometimes play tracks at half speed or so to increase DCS performance, and then speed the whole thing back up during video editing.

[Foka]

17 minutes ago, Yurgon said:

I assume that a kind of snapshot system that saves the full state of the mission every couple of time-units would improve track reliability, but would blow up track sizes and require a lot more I/O, potentially degrading the actual game performance.

 

Well, we have TacView, which records all telemetric data of all objects in the mission. If they connect both systems, and add to TacView information about liveries of the planes, etc. and made it into a replay system it might work.

[Ballinger French]

28 minutes ago, Yurgon said:

My experience was that replays were sometimes good, sometimes bad when I recorded them on my very old PC, where the CPU and possibly the I/O was bottlenecked. With a newer PC, they started to work fine almost all the time, and I haven't had any problems in recent times, though I admit that I only record very short tracks for specific purposes nowadays, and not 2 hour long tracks to relive an earlier flight, as I did on my very old PC.

 

Since tracks are actually a replay of all recorded inputs into a mission, you can probably imagine that the slightest mistake during the recording, or during the replay, might throw the replay off the tracks.

 

I assume that a kind of snapshot system that saves the full state of the mission every couple of time-units would improve track reliability, but would blow up track sizes and require a lot more I/O, potentially degrading the actual game performance.

 

Fast forwarding during a mission or during track replay drastically increases the risk of replays going bad.

 

Video producers who use replays to create great looking videos, but who have problems with framerates, also sometimes play tracks at half speed or so to increase DCS performance, and then speed the whole thing back up during video editing.

You may be on to something here.   I'm using pretty old hardware by today's standards.   

1 hour ago, Foka said:

Just a DCS things...

Yes, after doing some research on the topic, MANY ppl have had the same issue going back several years.    Arggggh.    How else can one enjoy the new BRRRRTTT sound without using replay?  

[Andurula]

After having a lot of issues early on with track files I have come to understand that the  harder my computer is working the worse the track file is.  Flying over the desert in the Persian gulf my track files are perfect.  The harder my computer works to keep up with the graphics, the more likely a control input will fail to be recorded resulting in a bad track file.    Flying over Haifa on the new Syrian map my track files are an absolute mess.

 

Tips for better track files are, 1.) pick areas with low ground details on the map and missions with few units to control, keep your graphic settings manageable obviously. 2.)  Never start on the ground in the parking area.  A slight error recording a control input will mean you will never see your aircraft taxi accurately enough to make it to the runway. 3.) If you want to record a video off of your track files, better to make several short track files rather than one long one.  That way an error recording an input early on does not corrupt everything that happens afterwards. 

 

Of course you could spend a lot of money on a top of the line computer which would also solve the problem.  People with these sort of computers have been known to say, "there is no problem with track files, they work fine"...

[Yurgon]

1 hour ago, Foka said:

Well, we have TacView, which records all telemetric data of all objects in the mission. If they connect both systems, and add to TacView information about liveries of the planes, etc. and made it into a replay system it might work.

 

That would certainly be interesting. Especially if there was a synergy effect. Right now, I believe just installing TacView easily eats up 10 FPS in every mission. Buddies with various types of bottlenecks have had to remove TacView until they could solve the problem (sometimes just waiting for a DCS patch, sometimes throwing more hardware at the problem).

 

Losing FPS to a better DCS recording, and losing more FPS to TacView in parallel would be bad, but right now, TacView is waaaaay too valuable to me not to use it on every mission. So if there was a way those two would share the same kind of data pipeline and work together instead of in parallel, that might be a big performance boost (except probably for those users who don't use TacView and who never record tracks, which I figure is probably by far the largest part of the player base ).

[shagrat]

One thing to keep in mind is, that a track does record initial environment setup, settings and most importantly for the player/client the controls input. Replay is actually the same mission starting then feeding those recorded inputs into the simulation. Any kind of update to the flight model, the use of dynamic weather, changes to environmental behavior, etc. can and often will cause the recorded inputs to generate issues when replayed after those changes.

Any hickup or missed input, either during recording, or replay (often caused by time acceleration) are likely to break the replay.

The reason we still have and use the tracks is, that when used to record short tracks of bugs and issues it is helpful to spot things like switches missed during startup, procedures gone wrong or even help ED devs to quickly debug issues. It can help to create videos and review missions to some extent, but it is not intended as an in-game video capture of sorts.

If you want a small video clip from external view or a nice "remembrance" of a spectacular fight/bomb run, try to run the replay directly, don't accelerate time and use a normal video capture to gather material.

[Dawgboy]

@shagrat  the order of these are hosed, so you can read from bottom up for my posts today.  Sorry and thanks.

12 minutes ago, Dawgboy said:

 

Respectfully, I think "hickup" is more likely the cause, if "hickup"="ED hasn't fixed a glitch in the REPLAY system"

 

 

In the 2020 DCS World manual, this isn't a stated reason, but should be mentioned given the forum's priority for TRK inclusion a proof-of-bug.  The same document references the REPLAY function as a debriefing aid, not bug support, although the latter is certainly a noble effort.  

 

 

If it's true that spurious inputs and time acceleration cause the REPLAY to malfunction, this should be stated in the manual, so folks don't do it, at least until the REPLAY function is bulletproof, no pun intended.  However, my testing shows neither of these altered the errors I saw in my TRK file versus the Tacview ACMI file, which the latter was reality as my wingie and I flew it.  If we are using this to debug the full functionality of each module, it seems the TRK files are a limited clue into what's happening until it's fixed to render an accurate, fully detailed reenactment of the mission.  Each TRK file, with a user testimony, can be used to determine where the REPLAY functionality fails, however. 

 

My position on the matter is, if Tacview can capture an accurate metadata rendering of the mission, then ED can also make REPLAY work properly.  I think the better option would be to have Tacview's metadata drive the REPLAY rendering on playback, and ditch whatever's being used within DCS to log the inaccurate/incomplete (I've seen both) metadata.  This would include ensuring it doesn't suffer with busy terrain or combined arms activities.  

 

EXAMPLE: 

Yesterday, Syria MP with a Hornet driver, doing a North-South valley sweep, testing recent Hornet A2A changes, latest Open Beta.  I want to say I've seen this problem, tho, with previous versions of v2.5 Stable.  Anyway, I fired an AIM-9X in what was a picture-perfect HOB JHMCS shot off my left quadrant, low.  The missile snaked down to one of the Mi-26 practice targets, and exploded on the helo, causing enough damage to stream some type of fluid and smoke.  Both my wingie and I saw it live.  I was going back into the REPLAY to film both the F1/cockpit view and F2/own external view as a training clip for our flying squad.  The 9:55 point in the TRK file showed my shot going straight off the rail and into the terrain in my aircraft's flight direction, not down and to the left as I and the Tacview ACMI witnessed.

Following the guidance above, I tried it with acceleration and without, and the latter had NO HOTAS or any other input during REPLAY other than to swivel/zoom the view with the mouse.  Both replays were equally defective renderings, with the Tacview the only accurate recording of the event. My sim PC is beefy.

 

This REPLAY defect is NOT_NOT optimal when the stated intent for the REPLAY function is debriefing.  I have seen this elsewhere during A2A engagements against Flanker/Fulcrum.  Thus, I agree with a previous author stating Tacview replay is necessary for post-mission debriefing.  One missing metadata capture was the 9X seeker head's lock on various targets during the live mission, with the TRK file showing the seeker aimed straight forward.  This may be the culprit, a place to investigate and/or state this is a known issue; however, I've seen it with AIM-120 when I witness a live kill and the TRK file doesn't.  

 

For my example above, I have attached the TRK file here, and I will attach other artifacts below (ACMI and pix), given I've max'd the attached-file-size limit on this post.

 

If there is another bug report for this, please move this to the right spot and/or reference it.  I'd be interested in the roadmap fix (what and when), when ED determines the way forward.  

Thanks.

Here is the Tacview ACMI file for the 9X launch I referenced.  The image below shows the targets below and to the left, with my 9X straight off the rail, not snaking to target, and heading off into the terrain.

Tacview-20210622-070520-DCS-MinakhNOsa19sTRIMMED.zip.acmi

Edited June 23, 2021 by Dawgboy

[Dawgboy]

This shows the impact point in the terrain in front of my Viper.

Edited June 23, 2021 by Dawgboy

[Dawgboy]

Respectfully, I think "hickup" is more likely the cause, if "hickup"="ED hasn't fixed a glitch in the REPLAY system"

 

 

In the 2020 DCS World manual, bug reporting isn't a stated reason, but should be mentioned given the forum's priority for TRK inclusion a proof-of-bug.  The same document references the REPLAY function as a debriefing aid, not bug support, although the latter is certainly a noble effort.  

 

 

If it's true that spurious inputs and time acceleration cause the REPLAY to malfunction, this should be stated in the manual, so folks don't do it, at least until the REPLAY function is bulletproof, no pun intended.  However, my testing shows neither of these altered the errors I saw in my TRK file versus the Tacview ACMI file, which the latter was reality as my wingie and I flew it.  If we are using this to debug the full functionality of each module, it seems the TRK files are a limited clue into what's happening until it's fixed to render an accurate, fully detailed reenactment of the mission.  Each TRK file, with a user testimony, can be used to determine where the REPLAY functionality fails, however. 

 

My position on the matter is, if Tacview can capture an accurate metadata rendering of the mission, then ED can also make REPLAY work properly.  I think the better option would be to have Tacview's metadata drive the REPLAY rendering on playback, and ditch whatever's being used within DCS to log the inaccurate/incomplete (I've seen both) metadata.  This would include ensuring it doesn't suffer with busy terrain or combined arms activities.  

 

EXAMPLE:

DCS World Open Beta 2.7.1, latest patch.

 

Yesterday, Syria MP with a Hornet driver, doing a North-South valley sweep, testing recent Hornet A2A changes, latest Open Beta.  I want to say I've seen this problem, tho, with previous versions of v2.5 Stable.  Anyway, I fired an AIM-9X in what was a picture-perfect HOB JHMCS shot off my left quadrant, low.  The missile snaked down to one of the Mi-26 practice targets, and exploded on the helo, causing enough damage to stream some type of fluid and smoke.  Both my wingie and I saw it live.  I was going back into the REPLAY to film both the F1/cockpit view and F2/own external view as a training clip for our flying squad.  The 9:55 point in the TRK file showed my shot going straight off the rail and into the terrain in my aircraft's flight direction, not down and to the left as I and the Tacview ACMI witnessed.

Following the guidance above, I tried it with acceleration and without, and the latter had NO HOTAS or any other input during REPLAY other than to swivel/zoom the view with the mouse.  Both replays were equally defective renderings, with the Tacview the only accurate recording of the event. My sim PC is beefy.

 

This REPLAY defect is NOT_NOT optimal when the stated intent for the REPLAY function is debriefing.  I have seen this elsewhere during A2A engagements against Flanker/Fulcrum.  Thus, I agree with a previous author stating Tacview replay is necessary for post-mission debriefing.  One missing metadata capture was the 9X seeker head's lock on various targets during the live mission, with the TRK file showing the seeker aimed straight forward.  This may be the culprit, a place to investigate and/or state this is a known issue; however, I've seen it with AIM-120 when I witness a live kill and the TRK file doesn't.  

 

For my example above, I have attached the TRK file here, and I will attach other artifacts below (ACMI and pix), given I've max'd the attached-file-size limit on this post.

 

If there is another bug report for this, please move this to the right spot and/or reference it.  I'd be interested in the roadmap fix (what and when), when ED determines the way forward.  

Thanks.

20210622TEST-HOB-Seeker_NotTracking.trk

Edited June 24, 2021 by Dawgboy