Track replay is bugged...

[Flagrum]

Randomness ... if using the same seed, the "random" numbers would be the same. But I can imagine, that some modules use their own random number generators for certain things. Like some shaking in certain flight regimes. And those random numbers are outside of the scope of the Track file and the replay function.

 

And according to the butterfly effect, small changes can have huge impacts elsewhere. Like, you fly and your aircraft stalls a little, vibrates for a second. This changes the attitude of it for a very small amount. And starting from there, one hour later, you may end in completely different areas of the map ... if that one second shake was random and differet each time the track is played.

[Flagrum]

Of course, but obviously it is also different when you play it back.

If that is the case, then this is "just" a bug (_the_ bug?) of the replay mechanism.

 

And it is even developing different due to thermodynamics...

... i.e. the butterfly effect. :-)

[shagrat]

If that is the case, then this is "just" a bug (_the_ bug?) of the replay mechanism.

 

 

... i.e. the butterfly effect. :-)

If it was that simple, they would have fixed it since Black Shark 1 I guess...

[sobek]

The term seeding in that context was referring to procedural number generation, not a simple random number.

In a procedural generation the result of the "dynamic" system is the same everytime.

The dynamic weather is different everytime.

From what I understood it uses a start value (pressure) for each system, and from that point on it tries to equalize pressure between the isobaric system(s).

 

I think you have some things confused here.

 

The term seed is used to describe the state of a pseudorandom number generator. Every time the generator is "rolled", it generates a number from the seed via an algorithm, then modifies the seed with a different algorithm. The algorithms themselves are deterministic however, so if you know the seed, you can reproduce the pseudorandom numbers that the generator will yield with each subsequent roll.

 

The dynamic wheather is indeed different, but not because the generation process is non-deterministic but instead the starting condition is randomized (with a pseudorandom number generator, presumably).

[sobek]

If it was that simple, they would have fixed it since Black Shark 1 I guess...

 

That would have been somewhat acausal, given that the dynamic weather generator came around much later. ;)

[shagrat]

Yep, I'm wrong. They just need to store the random seed and track replay is fixed...

[sobek]

Yep, I'm wrong. They just need to store the random seed and track replay is fixed...

 

I didn't say that... :doh:

 

It certainly wouldn't hurt to incorporate that though. The problem with tracks breaking isn't exclusive to missions with dynamic weather however.

Edited January 4, 2017 by sobek

[PiedDroit]

I didn't say that... :doh:

 

It certainly wouldn't hurt to incorporate that though. The problem with tracks breaking isn't exclusive to missions with dynamic weather however.

Lol I realize I confused everyone with my question :D

It would not solve everything I agree, there are many variables like the version used, the presence of mods or different inputs that would make a replay behave differently. However I would expect it to run fine on the same setup it was recorded, if everything was stored in the track file.

 

Someone spoke about precision of inputs, that would be an issue only if the stored inputs are less accurate than the actual ones. For example if the sim runs with 64 bits accuracy but the track only stores 32 bits.

 

The way it's done doesn't allow splitting the track in bits or starting recording mid-air, which is what I'd like most...

[Frederf]

Consider how compressed video works. There is much too much data to specify what color every pixel is on every frame for an hour long video. Instead there is a known state and a small stream of "change data" which updates only what needs updating.

 

And this screws up occasionally as we've all seen compressed videos do. This is why videos are fault tolerant by the inclusion of key frames. They are definite fully-defined states injected every once in a while to keep the whole video honest.

 

If track files are based on approximate changes from a particular state it needs correction frames to combat number drift.

[cthulhu68]

Its a bummer when you pull off a miracle and cant relive the moment. This is the 2nd most amazing thing I've ever done in DCS. Luckily this one saved correctly. (a 1 shot takedown of 2 BTR's with rockets) about a minute or so in

 

The one that didn't save was a Tunguska launching at me, me fumbling with controls and finally shooting mav, about 50-60feet in front of me the sam goes for mav and explodes.

[sobek]

Consider how compressed video works. There is much too much data to specify what color every pixel is on every frame for an hour long video. Instead there is a known state and a small stream of "change data" which updates only what needs updating.

 

And this screws up occasionally as we've all seen compressed videos do. This is why videos are fault tolerant by the inclusion of key frames. They are definite fully-defined states injected every once in a while to keep the whole video honest.

 

If track files are based on approximate changes from a particular state it needs correction frames to combat number drift.

 

You don't need lossy compression for track files.

 

You have a few tens of max 32bit integer time series compared to 1920x1080=2073600 of 24(?)bit pixels per single video frame for full HD video.

 

I don't know what the actual problem is with playback, but that seems unlikely.

Edited January 4, 2017 by sobek

[Nate--IRL--]

You don't need lossy compression for track files.

 

You have a few tens of max 32bit integer time series compared to 1920x1080=2073600 of 32bit pixels per video frame for full HD video. If that doesn't strike you as a vastly different problem, i don't know what will.

 

I think his point was not the lossy compression but rather the use of "Key Frames" (full state world snapshots) to periodically correct for delta deviation in the playback.

 

Also these "Key Frames" might be a route toward the return of the much missed in mission Save feature.

 

Nate

[Flagrum]

The lossy compression aspect is not so important - the comparisation in general is not too bad: the amount of data would be way too much if each frame of a video would be stored as a complete bitmap. Therefore every x frames a full bitmap is stored and the frames in-between are derived from that key frame using only the changes since that frame.

 

The same is probably true for .TRK files: if each "tick" in the simulation would be stored as a complete image of all objects populating the map, the amount of storage and bandwidth would probably way too much to handle (without stuttering, etc.). Therefore in TRK files also only information relevant for getting from "frame n" to "frame n+1" are stored.

 

Storing "key frames" or sync points within the TRK every x frames/"ticks" - sounds like a good idea to me, but I have no clue if it is really done that way.

Edited January 4, 2017 by Flagrum
** sniped ... ;-D ***

[sobek]

I think his point was not the lossy compression but rather the use of "Key Frames" (full state world snapshots) to periodically correct for delta deviation in the playback.

 

That could potentially lead to dead entities reappearing, etc. It still begs the question why sometimes the simulation engine behaves non-deterministically during playback. Fixing those problems is the prudent solution. That's not to say that that is not a hard task (especially in MP, where this might actually be prohibitively hard).

Edited January 4, 2017 by sobek

[sobek]

The lossy compression aspect is not so important - the comparisation in general is not too bad: the amount of data would be way too much if each frame of a video would be stored as a complete bitmap. Therefore every x frames a full bitmap is stored and the frames in-between are derived from that key frame using only the changes since that frame.

 

The same is probably true for .TRK files: if each "tick" in the simulation would be stored as a complete image of all objects populating the map, the amount of storage and bandwidth would probably way too much to handle (without stuttering, etc.). Therefore in TRK files also only information relevant for getting from "frame n" to "frame n+1" are stored.

 

Storing "key frames" or sync points within the TRK every x frames/"ticks" - sounds like a good idea to me, but I have no clue if it is really done that way.

 

None of that is done. The trk system hinges on the deterministic nature of the sim. Same input-same output. A trk is simply a mission file (the initial positions of all entities) with the user input baked in. The rest is the simulation running by itself without any further interference.

 

The problem seems to be that under some circumstances, the deterministic behavior does not hold true. Anyways, i guess all this rambling defeats the purpose of the bug forum.

Edited January 4, 2017 by sobek

[Nate--IRL--]

That could potentially lead to dead entities reappearing, etc..

 

Not if the full world state at that time is taken. Imagine it as an automatic periodic save (probably not viable performance wise though).

 

It still begs the question why sometimes the simulation engine behaves non-deterministically during playback. Fixing those problems is the prudent solution..

 

Considering all the variables that are active in a given mission, it just takes one not to be recorded correctly, to induce a butterfly effect.

 

Track Playback has been an issue ever since Flanker 1, the amount of variables to be tracked has exploded since then. Also, updates are far far more frequent, it is impossible to expect playback compatibility between versions.

 

Anyways, i guess all this rambling defeats the purpose of the bug forum.

 

A rambling, but productive discussion. :)

 

Nate

Edited January 4, 2017 by Nate--IRL--

[sobek]

Not if the full world state at that time is taken. Imagine it as an automatic periodic save (probably not viable performance wise though).

 

Let me rephrase, that could lead to units dying (erroneously) and suddenly being resurrected (in the subsequent sync frame).

 

Considering all the variables that are active in a given mission, it just takes one not to be recorded correctly, to induce a butterfly effect.

 

Actually in SP, there aren't that many variables to be tracked. The only input to the system is the input from the HIDs, so a bunch of axis inputs and button clicks. The rest is "just" the sim engine doing what it does. I can hardly believe that this is an issue as trivial as recording user input, because in that case, ED would have long fixed it.

 

Track Playback has been an issue ever since Flanker 1, the amount of variables to be tracked has exploded since then. Also, updates are far far more frequent, it is impossible to expect playback compatibility between versions.

 

The thing with version incompatibility is practically a given with this system, that much is understandable. On the other hand, it must be possible to make the sim react the same twice to the perfectly same conditions. IIRC the simulation core is programmed to be real time in a very strict sense. My guess is that at least some of the breakage comes from core frames not meeting their deadline, but this is pure guesswork, as i don't know if that is even possible without the sim crashing.

 

 

A rambling, but productive discussion. :)

 

Dunno, i doubt anything we can dispense in this thread short of doing research on what breaks trk files brings the devs any closer to fixing this issue. :dunno:

Edited January 5, 2017 by sobek

[shagrat]

That would have been somewhat acausal, given that the dynamic weather generator came around much later. ;)

Turbulence, random, affects plane. As does the static weather if you have AFM/EFM, unless you have zero wind and no turbulence.

I am quite convinced the AFM/EFM calculates some "randomized" effects as soon as wind is present.

 

In addition every tweak to the Flight Model terrain elevation (to a point), basically any update/patch can break a track.

 

Still the track system in general should be kept, as they are pretty useful to troubleshoot, and usually short tracks with small amount of units, scripting automation etc. play good enough.

[Wright_GR1]

I dont know how to fix this but I just wanted to add that I have never had a track file go wrong. I believe you guys, plenty complain about it! It would be impossible for me to do my DCS videos I put on youtube without the replay function.

 

I use the fast forward function too, never gives me any probs.

[sobek]

Turbulence, random, affects plane. As does the static weather if you have AFM/EFM, unless you have zero wind and no turbulence.

I am quite convinced the AFM/EFM calculates some "randomized" effects as soon as wind is present.

 

Ok, but that would all the more speak for saving the seed of any pseudorandom number generators used in the sim to be able to reset them before track playback. Then it'd be deterministic again. You can't have real random processes on a computer (unless you sample a real source of randomness).

[shagrat]

Ok, but that would all the more speak for saving the seed of any pseudorandom number generators used in the sim to be able to reset them before track playback. Then it'd be deterministic again. You can't have real random processes on a computer (unless you sample a real source of randomness).

I am going out on a limb here, but I guess that would mean every 3rd party EFM needs to incorporate an export function for ANY random number in the system?

I doubt anyone is willing to waste developer time on that.

 

Maybe it is possible through the existing API, but it would still mean to implement function calls in every existing and future modules AFM/EFM.

 

Let's wait what happens after 2.5

 

I think this has a very low priority on the list.

[sobek]

I am going out on a limb here, but I guess that would mean every 3rd party EFM needs to incorporate an export function for ANY random number in the system?

 

No, not the random number.

 

You save the seed of the rng at simulation start.

 

At track replay, you reset the seed of the rng to the saved seed. After that it will put out the same pseudorandom series of numbers it did the first time. Of course the program execution flow must be absolutely identical to the first time.

 

But your other point is indeed valid. If EFM programmers use other sources of pseudorandomness, then this would once again be a possible cause for a track to break.

 

On the other hand, the randomness really should be in the atmospheric model, not in the EFM. The EFM should be deterministic. So maybe this isn't even a problem.

Edited January 5, 2017 by sobek

[Ironhand]

Turbulence, random, affects plane. As does the static weather if you have AFM/EFM, unless you have zero wind and no turbulence.

I am quite convinced the AFM/EFM calculates some "randomized" effects as soon as wind is present...

I don't think anything is randomized where the wind is concerned. I've set up a variety of weather patterns using Dynamic Weather and flown for most of an hour through varying wind speeds & directions and landed on the same point of the runway at journey's end during replay.

[shagrat]

I don't think anything is randomized where the wind is concerned. I've set up a variety of weather patterns using Dynamic Weather and flown for most of an hour through varying wind speeds & directions and landed on the same point of the runway at journey's end during replay.

That is interesting. From my experience with tracks, as soon as I had dynamic weather engaged it messed up replay.

 

P-51D especially, never even made it off the runway during replay. That was one of my first encounters, where that happened.

 

If you could replay an hour long track without the slightest derailment, I really wonder how so many people here experience these issues?

 

I can accept, that every little patch can and mostly will break tracks from earlier versions of DCS.

It seems logical, that weather/wind dynamics can influence the flight characteristics.

I can see how ASM with fluid system modeled etc. could affect engine performance, thus changes response to recorded inputs.

 

What is really strange, is if it behaves totally different (as in working flawless vs. causing weird results) between installations... You are sure it works flawlessly, in a reproducible way?

[sobek]

I don't think anything is randomized where the wind is concerned. I've set up a variety of weather patterns using Dynamic Weather and flown for most of an hour through varying wind speeds & directions and landed on the same point of the runway at journey's end during replay.

 

Was there any turbulence?