Track replay is bugged...

Tracks have been a random mess for quite a while now. Sometimes they work... but only sometimes. And there is no reproducible pattern. What annoys me most is that we don't get any statement from ED.

Tracks have been a random mess for quite a while now. Sometimes they work... but only sometimes. And there is no reproducible pattern. What annoys me most is that we don't get any statement from ED.

The response I got was it is done in the manner that it is, is for debugging purposes. They replay all the inputs but this doesn't always give the actual replay if one little slight input is lost or not interpreted exactly as it did during the live play. And when that happens, replay is garbage.

My response was then don't advertise it as a replay function. Leave it as debug and create a replay function that works. It would be relatively easy to do because they can use the same method as 3rd Party's like Tacview use. Which I have never had a problem with.

Does anyone know if the tracks still have play back issues? I want to post a few tracks but it's kind of senseless if they are still broken.

The problem with this is two fold for me. I'm not into posting everything I do for them to exploit, and....It doesn't matter anyway because you can only record on the new software if Gforce recognizes your software as a game that they support. And well..... They do not support DCS. So I'm back to having no recording ability. That is unless E.D has found a fix for the tracks.

I hope I clearly understood what you are writing here. I didn't know about Shadowplay not supporting DCS, but I didn't get this: "Until this last update, you could use the Nvidia software "Shadowplay" to record tracks, but they have seen fit to toss it and instead have you record tracks that go directly to some online deal."

I have come to the point where I think E.D. is not interested in fixing this master bug, which weakens the overall experience of this software dramatically (I started out with LockON 1.0, this had never been an issue). I am really not happy (just to not say angry) about this issue. One module after the other is published, but the basic software has obvious fundamental problems.

Can someone give ideas and experiences in recording tracks using external programs, which actually work satisfactory?

The response I got was it is done in the manner that it is, is for debugging purposes. They replay all the inputs but this doesn't always give the actual replay if one little slight input is lost or not interpreted exactly as it did during the live play. And when that happens, replay is garbage.

....

Considering it as true that inputs are recorded:

If you apply the same input as recorded in a "new mission" (during the replay), but have weather phenomena like thermals and winds which have a certain randomness, you would NEVER land at the same place and attitude ... which is 100% logically.

They - in my opinion - have to re-program their recording functions in direction "tac-view" (save location, attitude, speed, weight factors, drag factors, weather factors). This is most probably the point where things get really complicate for them.

But a statement would be nice, though!

It's really disturbing that with all the info about the upcoming 2.5 version absolutely nothing has been mentioned about finally fixing the totally unusable replay system.

 

It's a missed opportunity to reliable replay flights with the brand new high quality graphics.

 

Without a fixed replay system I'm definitely not going to buy any new module.

 

Can you imagine how much one is missing if you can't reply a perfect F/A-18 trap or a perfect Yak-52 aerobatic sequence?

I share the frustration about the lack of communication around this important issue. It has been working on and off but often when I really wanted to use it, it showed me a sequence that began correctly and then at some point invented action that had never happened this way like it showed me steeply climbing and shooting lots of holes into the air, and then crashing into the deck. Recently I have used it with the Bf-109 and it worked. But I don't know what the status is for other planes, and even for the Bf-109 it might be broken again after the next update.

Before my retirement I was an implementation leader for a large piece of a major Enterprise Ressource Program, and we had to develop new solutions and even before these solutions went live we had organized testing by key users, and the test results were captured in large spreadsheets and discussed with the developers. And every issue got a resolution which could be "nice to have", "new feature request", "low priority bug", high priority bug", "showstopper etc". Each of these categories was clearly defined, and a new solution would not go live as long as it had high-priority bugs. Progress in bug fixing was regularly communicated by reviewing the updated issue tracking spreadsheet which was usually maintained on sharepoint so it had online visibility. Obviously, this process was also used for issues found after go-live which is always possible due to the complexity of the software and its environment.

Such a process requires discipline of course and you cannot have every user be involved directly; they talk to the key users who very often will be able to show them that they simply did something wrong. But the updated issue tracking is always visible to the stakeholders.

Such a process does not eliminate conflicts but it enables a rational resolution, maintains user satisfaction and helps to establish the right priorities in addressing issues. I am somewhat disappointed about the apparent lack of a transparently managed process for DCS World.

If that process were established I would be happy to contribute.

The track replay system makes life a nightmare for YT video makers.

Being able to reliably record sequences to then replay and film would be a godsend.

I share the frustration about the lack of communication around this important issue. It has been working on and off but often when I really wanted to use it, it showed me a sequence that began correctly and then at some point invented action that had never happened this way like it showed me steeply climbing and shooting lots of holes into the air, and then crashing into the deck. Recently I have used it with the Bf-109 and it worked. But I don't know what the status is for other planes, and even for the Bf-109 it might be broken again after the next update.

Before my retirement I was an implementation leader for a large piece of a major Enterprise Ressource Program, and we had to develop new solutions and even before these solutions went live we had organized testing by key users, and the test results were captured in large spreadsheets and discussed with the developers. And every issue got a resolution which could be "nice to have", "new feature request", "low priority bug", high priority bug", "showstopper etc". Each of these categories was clearly defined, and a new solution would not go live as long as it had high-priority bugs. Progress in bug fixing was regularly communicated by reviewing the updated issue tracking spreadsheet which was usually maintained on sharepoint so it had online visibility. Obviously, this process was also used for issues found after go-live which is always possible due to the complexity of the software and its environment.

Such a process requires discipline of course and you cannot have every user be involved directly; they talk to the key users who very often will be able to show them that they simply did something wrong. But the updated issue tracking is always visible to the stakeholders.

 

Such a process does not eliminate conflicts but it enables a rational resolution, maintains user satisfaction and helps to establish the right priorities in addressing issues. I am somewhat disappointed about the apparent lack of a transparently managed process for DCS World.

If that process were established I would be happy to contribute.

First let's clarify what a track is. It "records" your control inputs to the module you are flying and stores the original Mission file (.miz) with these inputs as a Track file (.trk)

Now on replay it starts the Mission (not even 100% sure it records the random triggers results?) and replicates the exact inputs you did when playing the mission the first time.

Now A) any change to the environment model in DCS or(!) the FlightModel of the module, will most certainly invalidate older track files as the inputs can't produce the same results, anymore. Imagine pulling the stick 5 degrees and the nose go up by 7 degrees, after FM change the plane generates a tad bit more lift, so you get 8-10 degrees and stall, thus crashes on start. End of replay...

The other aspect B) is randomized weather/environment. As soon as weather parameters change (dynamic weather) it may start with the same seed and generates the intitial weather system, but from then forth it can develop differently. Now if density, temperature and wind changes dynamically, but the "recorded" input stays the same... Weird flying!

The longer a track runs, or if you use time compression (!) it may have glitches, miss inputs, further degrading the replay.

So why does ED not simply remove this, if it isn't "reliable"?

First of all, it helps a lot in debugging or helping others. A short track recorded around a problem someone has with firing Mavericks or flying a certain maneuver, can be "watched and analyzed" by others if there was no update/patch. That means a few days you can usually use the track and especially if it is a short "recording" it can show what switches the guy is using ("You forgot to switch Master Arm on"), what he does on the controls ("You need to pull less than 3G and ease on the stick before rolling out ") and even for pre-recording a good attack run to make a video scene from different angles, it usually does a good job, if you don't wait for the next update to break it.

Finally ED internally can debug track files and analyze a lot more than we can, which helps in finding bugs, development and testing.

So if you need a nice video to show on YouTube or want to record your latest formation flying, a track is not the first choice. Simply look into things like Shadowplay, Fraps, or any other screen recording software.

The track may help you in reshooting some nice effect shots, but it isn't a reliable archive of movie recordings. It never was, and it can't by design.

Just want to mention that wind of any amount (even the minimum allowed in the ME) seems to keep TRK files from playing back correctly. So if you are flying a mission with wind, the results will most likely be problematic.

I share the frustration about the lack of communication around this important issue. [snip]

It's important for you, but not for everyone.

I don't use tracks often, so I don't think it's an important issue. I'm going to hazard a guess I'm in the majority too.

Just food for thought.

It would be nice for it to be fixed though.

Two major problems make it difficult to use "Tracks" as "Video-Recordings".

 

First let's clarify what a track is. It "records" your control inputs to the module you are flying and stores the original Mission file (.miz) with these inputs as a Track file (.trk)

Now on replay it starts the Mission (not even 100% sure it records the random triggers results?) and replicates the exact inputs you did when playing the mission the first time.

 

Now A) any change to the environment model in DCS or(!) the FlightModel of the module, will most certainly invalidate older track files as the inputs can't produce the same results, anymore. Imagine pulling the stick 5 degrees and the nose go up by 7 degrees, after FM change the plane generates a tad bit more lift, so you get 8-10 degrees and stall, thus crashes on start. End of replay...

 

The other aspect B) is randomized weather/environment. As soon as weather parameters change (dynamic weather) it may start with the same seed and generates the intitial weather system, but from then forth it can develop differently. Now if density, temperature and wind changes dynamically, but the "recorded" input stays the same... Weird flying!

 

The longer a track runs, or if you use time compression (!) it may have glitches, miss inputs, further degrading the replay.

 

So why does ED not simply remove this, if it isn't "reliable"?

 

First of all, it helps a lot in debugging or helping others. A short track recorded around a problem someone has with firing Mavericks or flying a certain maneuver, can be "watched and analyzed" by others if there was no update/patch. That means a few days you can usually use the track and especially if it is a short "recording" it can show what switches the guy is using ("You forgot to switch Master Arm on"), what he does on the controls ("You need to pull less than 3G and ease on the stick before rolling out ") and even for pre-recording a good attack run to make a video scene from different angles, it usually does a good job, if you don't wait for the next update to break it.

 

Finally ED internally can debug track files and analyze a lot more than we can, which helps in finding bugs, development and testing.

 

So if you need a nice video to show on YouTube or want to record your latest formation flying, a track is not the first choice. Simply look into things like Shadowplay, Fraps, or any other screen recording software.

The track may help you in reshooting some nice effect shots, but it isn't a reliable archive of movie recordings. It never was, and it can't by design.

I wonder why IL-2 doesn't have this issue with recording? TC

Like why does an Orange taste so different than an apple! Both are fruit, both are round, mostly same size, so they should taste similar?

 

Again, it's a useless, unreliable tool.

It is useless for what YOU want to do with it.

Like I said before, it does a pretty good job at internal debugging and helping the community to help others.

It just doesn't work as a Video Recording tool, so you may just want to press WIN+G and use Windows 10 video game screen capture for that, or any of a dozen tools build for that purpose.

Two major problems make it difficult to use "Tracks" as "Video-Recordings".

 

First let's clarify what a track is. It "records" your control inputs to the module you are flying and stores the original Mission file (.miz) with these inputs as a Track file (.trk)

Now on replay it starts the Mission (not even 100% sure it records the random triggers results?) and replicates the exact inputs you did when playing the mission the first time.

 

Now A) any change to the environment model in DCS or(!) the FlightModel of the module, will most certainly invalidate older track files as the inputs can't produce the same results, anymore. Imagine pulling the stick 5 degrees and the nose go up by 7 degrees, after FM change the plane generates a tad bit more lift, so you get 8-10 degrees and stall, thus crashes on start. End of replay...

I replay tracks generally just after the end of the mission, and if I want to create a video it's right then. So FM changes would not have affected me.

And I have had a lot of tracks from missions with rather long duration which were absolutely correct.

But it's good input so I know that FM changes can falsify the track; so there is no point in keeping old tracks on the disk.

...I'm going to hazard a guess I'm in the majority too.

That's pure conjecture and you have no statistical basis for what you are saying.

But maybe ED should run a poll on the subject, and if there is a strong majority of users who don't care, then maybe the tracks should be limited to a debug tool for ED. While some of us would be sad, at least we would no longer fret about wrong tracks.

...maybe the tracks should be limited to a debug tool for ED...

:) Hell. I use it to "debug" my flying all the time.

If it can't even replay a straight line during takeoff? Seriously?

Seriously! The track provides control actions and system response which can be used in automated debugging and finding issues for ED (stick movement triggered wrong pressure build-up in hydraulics modeling), as well as finding simple "pressed the wrong button" issues by the community, given the track is short and focused on the issue.

Why should I use an external tool which reduces DCS performance even more?

Because you want a video recording for archiving, not a recording of your control inputs.

Modern screen capture shouldn't have much impact on DCS, as they will use a different CPU core and if output is stored to a separate hdd/ssd won't even interfere with preloading.

If you need tactical analysis I recommend TacView. It is a DCS plug-in (Mod) that records object movements and events, for engagement analysis. It provides a lot of valuable data from height, speeds course to G-forces, target aspect and LOS...

That's pure conjecture and you have no statistical basis for what you are saying.

But maybe ED should run a poll on the subject, and if there is a strong majority of users who don't care, then maybe the tracks should be limited to a debug tool for ED. While some of us would be sad, at least we would no longer fret about wrong tracks.

Maybe ED should name it track-debugger and make clear what it can/can't do, to prevent wrong expectations, but I wouldn't be happy to see it gone, just as only a few people use it.

What do we kill next? Any "majority" ever used the "Aerobatics" in the Mission Editor? Or maybe we remove the least used Vehicles and AI planes, as well?

:(

...

Maybe ED should name it track-debugger and make clear what it can/can't do, to prevent wrong expectations, but I wouldn't be happy to see it gone, just as only a few people use it...

I, for one, would miss it, if it were gone. It may have warts but I still find it useful for improving my skills.

Apparently you still don't understand the problem. During the track replay it's obvious that the control actions and system response don't always match and this doesn't make any sense when troubleshooting!

 

Furthermore how do want to re-create a problem during flight if your plane crashes already during takeoff?

 

Sorry, in its present form it's simply a buggy, unreliable and hence useless feature.

ED uses it together with their debugger and they can extract a lot of infos from the track, we can't.

What it can't provide is a 100% correct playback of your combat missions if you put in weather (as it is dynamic by nature) and if you have a lot of objects to track, as this often causes glitches.

As well, you need to be aware, that any update (weekly) can break older tracks.

If you understand the limitations it is a useful tool nonetheless.

Edit I'm not saying it has to be useful for you,but it is for others.

I understand the limitations Shagrat pointed out, but that's probably not the biggest part of the problem. I just completed an experiment using a furball mission involving 12 Bf-109 including myself, 12 P-51, and 4 Smerch MLRS.

I had the dynamic weather practically disabled.

I played the mission twice, and both times it lasted nearly 17 minutes.

First run: Had hits on 2 P-51 and when all P-51 were downed I destroyed the 4 MLRS and that was the end of the mission. I saved the track and replayed it.

It looked about right until the point where I hit the first P-51. After that, my flight maneuvers looked strange and I never hit the second P-51. I flew towards the MLRS location but instead of flying towards one of the Smerchs I flew about 100 m left of the correct flight path and slammed right into a gentle slope. End of show.

Second run: Had several hits on one P-51 and when the AI Bf-109 had finished their work with the 12 P-51 I destroyed the 4 MLRS.

I saved the track and then clicked on "Watch Track" (i.e. not watching the saved one yet). What I saw was exactly what I remembered and in the final phase I flew correctly to the 4 smerchs and it took me 6 runs to destroy them. There was no deviation from the original flight path at all.

Next I replayed the saved track and that showed exactly the same thing: absolutely correct.

So there is obviously a software bug that does not "bite" all the time.

If ED could just fix that bug, I would be happy to use the tracks, understanding their limitations. What I and probably some other members complain about is the gross malfunction I experienced with the first recorded track, and not the slight deviations that might be caused by dynamic weather; and I totally understand and accept that old tracks may be affected by flight model changes.

I agree with bbrz when he says that in its present form it's buggy and unreliable. But I do not agree that it's useless because when that strange bug does not bite it works well and I use it quite often. I just want us to get rid of that random bug.

That's pure conjecture and you have no statistical basis for what you are saying.

But maybe ED should run a poll on the subject, and if there is a strong majority of users who don't care, then maybe the tracks should be limited to a debug tool for ED. While some of us would be sad, at least we would no longer fret about wrong tracks.

Well, er, yes, of course it's conjecture, that's why I specifically said it was a guess... but probably not an outlier considering the very limited number of people complaining about tracks being wonky compared to other subjects.

Either way, you missed my point with my post.

You think it's very important. ED clearly think different, or agree but cannot put the resources to fixing it at the moment because other things are more important.

The net result is the same.

Personally, I'd pick this fight up again when 2.5 is out the door.

Just wondering...

Shagrat says that ED use the tracks for debugging, and they extract a lot of info from the tracks. Debugging, for a software company, is mission-critical. They could not live with a mission-critical tool that has a better than 10% probability of producing garbage.

So maybe the bug that produces complete garbage in the replay sometimes is in the replay software and not in the software that records the track. If that's so then the replay software should be fixed and a lot of people would be happier.

I mentioned in another recent thread that it's very disappointing that tracks are still inaccurate in the newest 1.5.8.x. I guess I understand all the reasons why this is the case, but was curious just how far back in the "Flanker" timeline that this was an issue. It seemed to me that in the early days, track recordings were solid.

I tested FC2 and even simple, short missions (perfectly lined up 5Km away from carrier landing, perfectly lined up runway rocket attack, etc) played back wrong. Even without time compression or unusual weather, same thing. Sometimes the exact same track played back correctly once and then incorrectly the next try...maddening.

I tested LOMAC 1.0.2 and the replays were solid and always correct. I even tried my best to break them recording a carrier landing mission. I began about 20Km away and flew a crazy side to side, up and down zig-zag pattern with extreme control inputs, finally lining up and landing with 5Km to go. On track playback I used extreme time compression and constant view and pan adjustments...still a perfect landing every time.

Before LOMAC, I also flew Flanker 2.5 and the original DOS version and while I can't test them now, I don't recall any track inaccuracies...

I guess a question is, when did other long time Flanker pilots first notice track playback problems? For me it appears they were introduced with Flaming Cliffs. While others may not use tracks much, for me they're a major part of my enjoyment of flying (The IL-2 ntrk system is an example of how things should work). I really wish the team would sort this out or introduce a new track recording system that reliably works. As others have mentioned, I won't be investing in further modules until the long standing issues with track recording are corrected :(

Don't get me wrong, DCS is an amazing achievement, but if the track recorder is really just a debugging tool then it shouldn't be presented as anything more. If a track recorder is considered a DCS feature, then it needs to work properly :smilewink:

...

 

I guess a question is, when did other long time Flanker pilots first notice track playback problems?...

Playback issues were present in FC1.5. And began creeping in prior to that, I believe.

Just wondering...

Shagrat says that ED use the tracks for debugging, and they extract a lot of info from the tracks. Debugging, for a software company, is mission-critical. They could not live with a mission-critical tool that has a better than 10% probability of producing garbage.

So maybe the bug that produces complete garbage in the replay sometimes is in the replay software and not in the software that records the track. If that's so then the replay software should be fixed and a lot of people would be happier.

The "replay" system starts the mission again and routes your recorded control inputs into the module, any features inside the module that perform "random" or dynamic behaviour, e.g. fluid modeling in hydraulics, "realistic" performance degradation of the engine (like in the MiG-21) in theory can mess it up during replay.

Weather and environment, anything that is different in the Mission on replay is an issue.

I found that after a couple of minutes most replays diverge from the original a bit more or less, but sometimes it works flawless for a long time.

I fear there is no generic "bug" to fix. Most likely we have issues with the modules reacting realistically to inputs. So we either need to nerf down the dynamic modeling and weather/environment or we need to record ALL this dynamic stuff from the module and world in parallel... Hmmm, could we combine TacView with track recordings to achieve an ingame replay from a TacView file? :book: Just thinking...

l... Hmmm, could we combine TacView with track recordings to achieve an ingame replay from a TacView file? :book: Just thinking...

Interesting! I had the same thought.