[KNOWN ISSUE] Replay is BROKEN

Hi

Has anyone had this issue? When I run a replay of a multiplayer mission in 2.5 the track starts out from when the mission started even though I was not on the server at that time. For example if I join a server, and the server has the sun up at 12 o'clock high when I join and it is noon, then when I replay the track it starts playing at that missions start time when the sun is rising and no one is even on the server including myself. It replays the track more like it is loading up the mission, then re-rendering what happened during my flight. My tracks save and replay fine for Tacview, this is just in the DCS replay, I have also disabled recording for Tacview from with in DCS and the replays are still the same. I have a lot of cool video that should be able to be re-rendered and captured in these tracks so I would love to get a fix for this.

The problem here is that when you see a bug, you are asked to provide a track...well, if the method of providing evidence of a bug, is itself bugged, what's the point? I have a nVidia card that uses its own video capture (ShadowPlay)...I had a problem I wanted checked into...I submitted the ShadowPlay video of the two minutes of recorded time within the sim that had the problem...ED wanted a track instead...I did have the track that the problem occured on saved but warned them, that the track was VERY long and I thought it was unreliable as I have seen these track corruptions before...anyway, I submitted the track and never got confirmation from ED..I went back to watch the TRK file and, of course, it had me ploughing into a bunch of parked planes on the carrier deck...so why would they confirm it? Pointless

Well, if you got a few minutes, I could give you my track and you could play it...perhaps you can use the "speed up" function... it's in the following link https://forums.eagle.ru/showthread.php?t=217942

I'll check it out shortly. Is the track made in the latest version?

I believe so...are these TRK files dated? I posted the file the same day it happened...or you could check the referred post date...thanks...oh, btw take a look at the YT linked videos...the second one was the ending of the trk file that you'll be looking at...also, when I watch my trk files, I always watch them without interference as this happened with the A10C way back when...the only thing I might do is use the speed increaser (fast forward). If using functions during playback contribute to a player "breaking" the replay, then by all means please have ED warn the consumers so you don't miss an opportunity to squash bugs...I see occasional bug reports with "MISSING TRACK FILE"...well, if the players are "breaking them" I can see why they're missing. The problem I was trying to have investigated was not limited to my experience...others have offered similar instances...if there's anything else you need (my hardware, etc.), please feel free to ask...thanks again

Time acceleration is the most popular "playback breaker" (after the obvious things like different game version or dynamic weather), so that's the very last thing you should use while playing tracks, actually.

Time acceleration is the most popular "playback breaker" (after the obvious things like different game version or dynamic weather), so that's the very last thing you should use while playing tracks, actually.

Yeah, I saw that coming

submit

Not playback as played originally.

-First su-27 AI fly above Soganlug- take control for seconds (take control change GEAR STATE!!!)

-First su-27 AI second landing attempt to Soganlug, on rear wheels take control --> explosion underground in real play, in replay ditch, pilot dies in both cases

-Second su-27 AI activate and land to Tbilisi, on 3 wheels mid runway take control, then

explosion underground in real play, in replay su-27 simply fall out of the sky

2,5,2,20601_takecontrol_su27_fails.trk

Replay inaccuracy points directly at player a/c.

Just for further information, my Yak-52 replays appear to function fine, even with 2x time compression, as of Update 9 on the Open Beta. On previous versions they never worked. Spitfire is still broken as ever. It only correctly records throttle inputs and canopy open/closed. I had one do a 360 right hand turn during taxi, when I only ever turned LEFT.

EDIT For the sake of experimentation, try deleting fxo and metashaders2 folders before replaying a track. That seems to greatly affect my Yak-52 tracks.

Time acceleration is the most popular "playback breaker" (after the obvious things like different game version or dynamic weather), so that's the very last thing you should use while playing tracks, actually.

Well if this is in fact the case, then really what is the point? Who has hours to sit around and wait and see if a track works when there is no rewind capability either. Image, trying to make a recording of a flight when you have to play it back at regular speed. Half the time it will be hours before you reach the part you wanted to record. Also, if this is true, then how come if I play a track and that track happens to work, then I can run time acceleration all I want on that track and it continues to work just fine. However, other tracks that I have never accelerated don't work and never will. It is so random.

Ever since I fly DCS I have never used Track Replay for obvious reasons.

They should make a deal with TacView and get that tied to DCS by default.

From what i understand, it will never work and can never work due to the

dynamic freedom the code has. What's good for flying is bad for reproducing, too many turns you can and do miss down the road and before you can say ABC your track goes south. So why bother with it from either side of the table, just dump it.

I do see the point of trk files for error reporting, that is then a thing to solve first before you dump the feature.

my 2 cents about that feature

The problem with TacView is that it's only good for engagements or aerobatics. There's no way to analyze your landings or carrier traps with its oversimplified display, and you can forget about machinima cinematics.

ED Track Replay and TacView are using two different methods for recording.

Track Replay record user inputs only. While replaying, It runs the mission as if your are playing and inject the user's input again. It is more like an Autopilot.

The TacView record the parameters of everything with a certain resolution. Maybe 60fps.

Most games that have a recording feature. They record the parameters of everything same as TacView.

ED went on a different way to record the user input.

ED Track Replay and TacView are using two different methods for recording.

 

Track Replay record user inputs only. While replaying, It runs the mission as if your are playing and inject the user's input again. It is more like an Autopilot.

 

The TacView record the parameters of everything with a certain resolution. Maybe 60fps.

 

Most games that have a recording feature. They record the parameters of everything same as TacView.

 

ED went on a different way to record the user input.

Yeah, whatever...it's the worst replay I've ever seen...so how can bugs be fixed when the proof that they exist is predicated on a corrupt recording system...maybe not intended this way, but just plain stupid

It hasn’t worked properly since lomac. Don’t hold your breath.

It hasn’t worked properly since lomac. Don’t hold your breath.

Have enough people complained about it? And what's their(ED) reply? I mean, as I stated earlier in this thread, I have a simple program that is FREE (I can remember having to pay for these types of "In-game" recording apps), provided by nVidia (Shadowplay)...so if this app is free, then the tech must be well known and common to do it. Yet the thinking behind what we have here, is downright primitive and incompetent...all Shadowplay does is to create a mp4 A/V file....how secret is that protocol?

Replays are useless 90% of the time.