Better .trk editor

[StarHopper]

Any chance we will ever get a better track editor? With rewind, pause, and fast forward? When you fly a 40 minute mission or so, and just want to see one part of it, its a real pain to get 20 minutes into the track, and then also not be able to rewind it.

[PeterP]

Hello,

Edit++(edited after it was moved to the "Wish-List"):

Drear Developers,

If you don't want to read through a pile of... - ...lets call them "smart thoughts".... jump directly to this post: http://forums.eagle.ru/showthread.php?p=1300091#post1300091

to get the point!

- but to get the full picture your are good advised to read the whole post- like it is and meant to be...

 

 

This are the functions you can use at the moment while in a replay:

 

accelerate time = Z+LCtrl

decelerate time = Z+LAlt

normal time = Z+LShift

Pause track = Pause/Brake

...and

take Control = when you hit ESC once and select it.

 

Rewind = Not possible right now.

...-and unlikely to happen... (Bucic proofed me wrong :) !! ...in some kind of way... its not a rewind -but it will serve the porpouse to go to specific point - and finally ad a "save" function if implemented !! :http://forums.eagle.ru/showthread.php?p=1300091#post1300091 )

 

Edit:

So I hope this answered your question why there in no "rewind"....if not/or you want to know more about the WHY - take a deep breath and sit down to read further.... :D

 

As so often in life: A simple question gets a simple answer , But it's sometimes very complicated to explain the why!

But I will try...;):

 

To give you a understanding why rewind doesn't work I first have to give you a insight how the track system works right now in DCS:

 

A track is nothing more than a remote controlled Mission.

The only difference to a user controlled fly is that every tiny input you have done is recorded and this inputs are replayed by the computer.

 

Every thing else isn't recorded -

!

- the AI/physics are calculated in real-time like it is done while flying a normal mission. And this works only in one time direction:Forward

 

Here are some thoughts/speculations from me why rewinding a track would recommend very huge resources and are hard to manage to do it properly :

 

To make it possible to rewind a track the engine would have to know where every object is in a exact time and what state it has... That means that all the calculations that are done from the engine have to be recorded ...

That would make the resource demands exorbitant.

 

A little example - you fire a bullet and after it ricochet from the ground it hits a Jeep...

No problem to replay this if the track runs forward... Because the DCS-Engine know where your nose was pointing at in the moment you fired the gun. Everything else is than calculated in real-time by the engine-physics.

 

But lets have look at it when we change the time direction:

The Jeep burns... than there was the impact... -no problem up to now, but now it starts to get complicate:

In the second of impact of the bullet, the engine need additional data that it doesn't have in a normal track (reminder- only your input is saved in a .trk file): The aspect from where the bullet was coming from , the acceleration and so on isn't recorded!

And the engine must also know how the bullet ricocheted to get exactly back into your gun-barrel (and decelerate it also - so you are not shooting yourself when the time-direction is changed ;) ).

 

So now lets scale this little example up to a battle with over 100 units....

 

...I hope you agree :

to make both time-directions possible in a track it would need a enormousness amount of data.

Data that is simply wiped out of the memory in a normal game play, because it will not be used again. The Track-system that is used from the DCS-Engine is happy to know

"what" happened(= A hit B with D),

and the engine forgets the

"why and how"(=A with V on x-y-z in state Gamma hit B with V on y-x-z in state Delta with D at x-y-z with V from x-y-z)

on small scale instantly

- (please re-read the last sentence again to understand fully...;) )... here is the version without the brackets:

The DCS-Engine is happy to know "what" happened

and the engine forgets the "why and how"

on small scale instantly.

- This is absolute sufficient to track everything and generate a usable De-Briefing.

 

- so this will save memory/CPU-cycles for going on in the simulation in real-time.

 

Scientific simulations do this (mirror the memory in every calculation cycle) but they run normally never in real-time and the used systems have a size of a building... - and it is not practical to do this in a real-time on a Home-PC in a complex simulation like DCS, because your system would be more busy to record why things happened than running the simulation and just let it happen... . (hope you get my point...)

 

I hope I could explain this very complex subject to you in a understandable (I'm German...) and easy to comprehended way why it is so hard to ad a rewind function

:).

So it is very,very unlikely that we will have a working real-time rewind button in the near future.

 

Edit:

A little off topic but worth mentioning in this context:

This underlies almost the same rules why it is also not possible in Real-Life : Rewind (or go back in time)

You only can determine how something happened when you observed it - and with observing I mean not only looking at it - I mean you have to know every state of every atom in a closed system when it happens through the whole time-line(to make it short: It's not possible to track very small scales - like atoms -, but it is doable to some degree on greater scale - like molecules. But you need all data of the starting-state - and all data of the end-state of your observed time-frame to determine it to 99,9 % why it is happened this way.)

 

Example- you enter a room and see a broken coffee-pot under the table... -your assumption is that it felt down -point (you are able to use algorithm or common theory's about how the physics work to recalculate what happened and make a theory about the thing you didn't have seen.).

But you can't say why or how...to 100%.

- you can make only a assumption how it happened, because you know how the physics work in this closed system.

But you will never be able to tell if the pot was in one piece as it felt off the table or - it was already broken in pieces before it felt down ... (-because you where not on the scene when IT happened... ... and there are infinity possibilities !! - to confuse you even more: on sub-atomic scales there a even more than infinity possibilities- two things can happened with on object at the same time and they both are true!! - ... but this is not the subject of this posting and it would go much more far beyond I want to convey here... )

 

You only would know and can tell exactly what happened if you have measured/observed it!

But there is a second aspect :

Measuring means also changing and interacting with this closed system... ....because you need energy to measure something - and this also results that you put energy in this "closed system" and change the system by doing this...-

and this simply means you change something and it is not a "closed system" any more...

....because you put yourself into this system...

So there is no possible way to see for you what happened if you wouldn't observed it...

-Point-

 

- that's why we will not be able to look back in time without the help of someone that was already there...

 

OK, -Ok!:) - I will stop here...;)

If you want to know more about this - goggle for "Schrödinger's cat","principle of conservation of energy" and "first sentence of thermodynamics".

 

But...

...the principles are the same in the game-engine of DCS.

You would need terabytes of data to make a track-recording replay in both time-directions and also rewrite parts of the entire game-engine to determine what happened before something happened. (...) - and than you couldn't be 100% sure that this is correct.

 

 

 

This only rely on my own assumptions and I would be very happy if someone can add more details or even better: Proof me wrong!;)

 

BTW: Welcome aboard- StarHopper !

Edited December 5, 2011 by PeterP
Lots of typos(and many still left..) and/or thoughts... and new ideas...

[Bucic]

A proposed solution

A robust (my favorite word) solution:

 

Fact: Currently tracks can be played fast forward using time compression without problems.

 

The simplest solution: Enable FFWD to a certain time (manual input)

Expected behavior: Track is being 'played' in maximum safe time acceleration with rendering disabled (blank screen or rough ETA value). At reaching the desired time rendering (display) is re-enabled.

 

Second solution: FFWD and RWD (<< and >>)

Expected behavior: Same as above but for RWD - track playback is being re-started and FWD-ed to the desired time. Display re-enabled same as in previous case.

 

This seems so robust to me that I could bet it can be done with scripting only (no code modifications).

[PeterP]

Thanks Bucic!!! -this is just for you:

-and just don't pay attention for the lines about love.... :D - but the lines about friends and help are true!

 

I had kind of idea also - but after my posting... I thought it is OK and enough for the moment...:D - and I also was light-years away to formulate it in a understandable way...

(and also a workmate came into my office...;))

...what you have written is also what I call a Robust(!) solution! Hat's off! ( from now on I want to use the term "robust" also more often - It just explains a "working thing" more appropriated than anything else! -thanks - ...have to rep some others before I can rep you again... )

But now let's come to something complete different and back on "track" again!:

A robust (my favorite word) solution:

 

Fact: Currently tracks can be played fast forward using time compression without problems.

 

The simplest solution: Enable FFWD to a certain time (manual input)

Expected behavior: Track is being 'played' in maximum safe time acceleration with rendering disabled (blank screen or rough ETA value). At reaching the desired time rendering (display) is re-enabled.

 

Second solution: FFWD and RWD (<< and >>)

Expected behavior: Same as above but for RWD - track playback is being re-started and FWD-ed to the desired time. Display re-enabled same as in previous case.

 

This seems so robust to me that I could bet it can be done with scripting only (no code modifications).

 

... I found out that the script you are talking of is already in the DCS-Engine... (as you maybe already found out... ;) )

But it can only be used when recording a track to a movie:

 

...and we "only" have to convert this to be usable while replaying a track .... to have a workaround (that you described) for the limitations of the engine I describe in post#2 to get a usable "save function".

Ok I will forward this to devs.

Did you ever got a reply ?! - if not I would open a thread in the "Wish-list".

 

Thanks again for your input and knowledge!

Edit:

Or - even Better:

Can a Moderator move this whole thread to the "wish-list" corner.

I thing "we" have a valid point here ! :)

Edited September 30, 2011 by PeterP

[PeterP]

The Mods did moved this thread to the "DCS: Wish List " corner and I got a positive reply from a "ED Team" member via PM.

:)

 

I have high hopes to se a "workaround" like Bucic described it for a "save mission" function on next patches, next-modules,...whatever....!

edit:

but you all have to know this doesn't have to mean anything!

 

 

...We will see...

---EVERYTHING IS SUBJECT TO CHANGE---

 

...and thanks to you all for your upcoming input!

Edited September 30, 2011 by PeterP
ideas -and so on... comeon!!

[StarHopper]

Well, if we can record the .trk, that will work. As long as Zoom Player or Media Player can play it back. I'll have to try it when I get my comp back.

[StarHopper]

Well, I see the problems with recording now. 1) It takes a lot of CPU with the game running. 2). Its just whatever you record.

 

I have also noticed there are a lot of problems with the .trk editor. Its seems to only record YOUR actions. Not sure about wingmen, but objects on the ground seem not to be recorded at all, as they all do their own thing, just like in normal game. So, in the end, you will notice you are shooting at things that were there during the recording, but are not there now during the .trk playback. Noticed that in Viper's HEI .trk from the HEI Penetration thread. Plus, I had to edit out the M2A1 because it kept killing the heli 10 seconds into the .trk.

 

Edit: Oops. Just saw Peter already said this. Oh, well. It would be nice to have a .trk recorder that recorded the actions of every object within say 10km. Otherwise, the tracks don't make much sense.

Edited October 7, 2011 by StarHopper