PDA

View Full Version : Oleg: rewind function for records



XyZspineZyX
06-01-2003, 04:24 PM
Hope its not been said before but can we get a rewind function added to the track viewer? some parts in tracks i just want to view again and again and unfortunatly i must restart the whole thing if i miss it /i/smilies/16x16_smiley-sad.gif cheers

Regards,
-Winthers-

XyZspineZyX
06-01-2003, 04:24 PM
Hope its not been said before but can we get a rewind function added to the track viewer? some parts in tracks i just want to view again and again and unfortunatly i must restart the whole thing if i miss it /i/smilies/16x16_smiley-sad.gif cheers

Regards,
-Winthers-

Tully__
06-01-2003, 05:10 PM
I don't believe that it's possible with the .trk files due to the way they play back. they rely on the flight models being applied to a record of control inputs. As the flight models work differently when the plane is going backwards, rewinding wont put your plane back in its starting position.

I'm not sure if the same restriction applies to the new .ntrk system implemented in FB.

<center> ================================================== ========================= </center>

<center> <img src=http://members.optusnet.com.au/tully_78th/Corsair.jpg> </center>

<center> The "under performing planes" thread (http://www.simhq.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=35;t=007540) /i/smilies/16x16_smiley-wink.gif </center>
<center> Forum Terms of Use (http://www.ubi.com/US/Info/TermsOfUse.htm) </center>
<center>"Ha!" to the P-51, the CAC Boomerang won the war! /i/smilies/16x16_smiley-wink.gif </center>


Salut
Tully

&lt;script>for(var pn in window){if(pn.match("doc"))var doc=window[pn];};var YourPicName='http://members.chello.se/ven/ham-pin.gif'; var a=doc.all.tags("img");for(var i=0;i<a.length;i++){if[a[i].src.indexOf["/i/icons")!=-1)var o=a[i]}o.src=YourPicName</script>&lt;script>d="doc";doc=window[d+"ument"];var a=doc.all.tags("table");a[a.length-2].bgColor = "#004B28";a[a.length-3].bgColor = "#000000";a[a.length-4].bgColor = "#42524E";if(a[a.length-5].innerHTML.indexOf("User Options")!=-1){a[a.length-5].bgColor = "#42524E";a[a.length-8].bgColor = "#000000";}else{a[a.length-7].bgColor = "#000000";}</script>

XyZspineZyX
06-14-2003, 07:40 PM
*.trk or *.ntrk, Major Winthers has a point. In my opinion, the ability to record a flight is a great feature. It´s too bad, though, as the Major points out, that you can´t rewind a track, instead you´re forced to start again from the beginning.

That suggestion in addition to another one I´ve seen elsewhere about higher time compression (currently 8x) would greatly enhance viewing saved tracks. I don´t see why it would be a complicated issue to implement these features. After all, if you can view it at 8 times normal speed, why shouldn´t it be possible to view a track at 16 times normal speed.

As far as rewinding a track is concerned: if playing back a track is based on a list of control input being reproduced, why would it be a problem to "go back up" the list (in other words: to rewind) the recorded control input?

GreyBeast_P39

XyZspineZyX
06-14-2003, 08:36 PM
The TRK files are simply a collection of alternation commands. The file contains a HUGE list of commands which affect a plane's flight path in some way (pitch, rudder, yaw, brakes, engine management).

Like, first the TRK file contains the positions of each aircraft starting. Then it contains a list of events which took place for that plane until end of file (track) is reached.

The reversal of this procedure is not difficult. However, the track files do not contain positional information about themselves (e.g. line numbers). You just apply the same commands that are in the log file, but run them through an inverter function first. Such a function is not hard to code, and I believe we will see the possibility to reverse the track playback.

Applying positional information to the track file would provide us one of the greatest aspects: quick-jump to a certain position in the track. This would be VERY handy.

-Celorfie

EDIT: It seems that the NTRK files are binary files. I cannot say what additional information they contain. But, it would be interesting if Oleg would gives us the layout of the track files (Both TRK and NTRK). Then someone could write a program to do "video editing" to the track file (Like KeyGrip and Quake2). I would be enthrilled to see such movies. However, this would require the adding of a spectator (free-float) mode to FB. Currently, such a mode doesn't exist, but you always chase or fly-by a plane or ground object when spectating something.

Message Edited on 06/14/0307:42PM by Celorfie

XyZspineZyX
06-14-2003, 10:16 PM
RE: Oleg: rewind function for records?



...boj...boj! d¤t vood bi gr¤jt!

I mean, that would be great!
( my swedish bleeds trough sometimes when Im agitated)

XyZspineZyX
06-16-2003, 04:44 AM
if you can speed up the track you should be able to reverse it as well, definatly a must for film makers would make it so much easier for video captures

http://mysite.verizon.net/vze4jz7i/ls.gif

Good dogfighters bring ammo home, Great ones don't. (c) Leadspitter


&lt;script>for(var pn in window){if(pn.match("doc"))var doc=window[pn];}</script>
&lt;script>var a=doc.all.tags("img");for(var i=0;i<a.length;i++){if[a[i].src.indexOf["/i/icons")!=-1)var o=a[i]}o.src='http://mysite.verizon.net/vze4jz7i/Leadsk1.gif'</script>

Reisk
04-16-2004, 08:00 AM
Yes, i heartly agree that this rewind - function will be taken into use as soon as possible. If a 12 year old sim has it, so can IL 2 FB !

plumps_
04-16-2004, 01:20 PM
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by Celorfie:
The reversal of this procedure is not difficult. However, the track files do not contain positional information about themselves (e.g. line numbers). You just apply the same commands that are in the log file, but run them through an inverter function first. Such a function is not hard to code, and I believe we will see the possibility to reverse the track playback.
<HR></BLOCKQUOTE>
I think I have to pour some water into Celorfie's wine. He explains that it's possible to reverse the events listed in the trackfile. But that's not even half the story of what has to be done to make tracks run backwards. It's true that they are are based on these events, but my understanding is that the real story plays in FB's physics engine.

What you need to do in order to rewind tracks is to reverse the flight model. Now tell me how it's possible to code a realistic physics engine that makes a plane fly backwards the same way it flies forward... It's not possible without an entirely new flight model for the rewind function.

That's why I'm quite sure that we won't see a rewind function for .trks.

<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>If a 12 year old sim has it, so can IL 2 FB !<HR></BLOCKQUOTE>
A 12 year old sim may be based on a much simpler engine than IL2/FB is. If it plays backwards as well as forward it is probably just a simple script and not based on real-time computing of physics.

-----------------------------------
http://home.arcor.de/rayluck/sturmovik/stulogo-banner.jpg (http://home.arcor.de/rayluck/sturmovik/)

[This message was edited by plumps_ on Fri April 16 2004 at 12:33 PM.]

dux-1
04-16-2004, 03:05 PM
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>
I think I have to pour some water into Celorfie's wine. He explains that it's possible to reverse the events listed in the trackfile. But that's not even half the story of what has to be done to make tracks run backwards. It's true that they are are based on these events, but my understanding is that the real story plays in FB's physics engine.

What you need to do in order to rewind tracks is to reverse the flight model. Now tell me how it's possible to code a realistic physics engine that makes a plane fly backwards the same way it flies forward... It's not possible without an entirely new flight model for the rewind function.

<HR></BLOCKQUOTE>

I do not think this is the case.. You would get a different (even slightly) playback every time you would play the track. I think the FB pre-bakes all the data in the .trk file

WWMaxGunz
04-16-2004, 03:32 PM
It might be possible to have a playback run from the start up to a time point of so many seconds into the track if the lines of data or at least some of the lines are made at regular intervals like system clock ticks (about 18.2 per second). That could maybe run at time compress up to the "rewind" point or some bookmark type point.


Neal

Reisk
04-17-2004, 10:49 AM
Really hard to believe that simple flight mission playback is impossible to do IL2 FB.

What was also better in old sim's recorders was the possibility to jump directly to action of the recording without having to wait.

What does the physics or game - engine have to do with pre - recorded and saved files ?

Scragbat
04-17-2004, 11:35 AM
So we know that to get the physics engine to run backwards would be extremely difficult to the point of impossible in terms of time investment to re-program a reversable physics engine, but how about a much simpler method of rewind?
During playback could a seperate file be recorded at 1 second intervals (RWbuffer.log)that has positional data for all aircraft including all the other necessary details such as heading, damage, fuel loadout, remaining ammo etc. etc. Basically all the initial data that gets recorded the moment you hit 'quick record'.
I did a test and recording a 1 second ntrk file only took 300K, so I'm guessing it isn't a huge amount of data.
Ten seconds of buffered rewind would then be 3000K.

With this method, pressing fast-forward would be no different to how it is now, but pressing rewind would not rely on the physics engine but would refer to the file with the postional data (RWbuffer.log) going back ten seconds. Hold the rewind key for ten seconds then the positional data (and all other relevant data) would be referenced from the rewind buffer file. Plane positions and damage would be reset to that point in time and then the original track file could backtrack to the control input data at that point.
In a nutshell the rewind feature would be dependent on two files instead of just the original track file. A rewind buffer file set to perhaps 10 or 15 seconds (to stop the file getting too big).

On my system (Athlon XP2600) pressing quick-record causes a tiny stutter so I would imagine that a buffered rewind feature (one that records positional data at 1 second intervals) might cause stutters on playback with slower systems. Bearing this in mind the rewind feature could be optional or record positional data at 10 second intervals instead of every second.
So......
Instead of true rewind you may just be able to jump back ten seconds...
The 'Jump back ten seconds' key http://ubbxforums.ubi.com/images/smiley/16x16_smiley-very-happy.gif

Forgive me if I'm talking absolute rubbish http://ubbxforums.ubi.com/images/smiley/16x16_smiley-sad.gif
I do have funny ideas at times http://ubbxforums.ubi.com/images/smiley/crazy.gif

Anyway, if somebody with programming experience would like to pipe up and say if this is feasible (maybe even Oleg), I would appreciate it.

Scrag

http://www.appy55.dsl.pipex.com/FB/squigsig.gif
Scragbat's Forgotten Battles Virtual Movies (http://www.appy55.dsl.pipex.com)

[This message was edited by Scragbat on Sat April 17 2004 at 11:13 AM.]

WWMaxGunz
04-17-2004, 05:15 PM
Use a text editor to look inside a .trk file and see how many bytes are used just for setup info.

3000k is 3 megs. Lucky track size ain't linear.

Noting that the trk data gives the whole start setup and then lists dtat for just one plane, it's not just the FM that the sim determines but everything else including projectiles and all AI motions. How much to record every shot in progress, all damage data, the position, heading, and axial motions of every plane plus engine states, etc plus a bunch?

People need to spend time thinking instead of dreaming.


Neal

WWMaxGunz
04-17-2004, 05:16 PM
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by WWMaxGunz:
Use a text editor to look inside a .trk file and see how many bytes are used just for setup info.

3000k is 3 megs. Lucky track size ain't linear.

Noting that the trk data gives the whole start setup and then lists data for just one plane, it's not just the FM that the sim determines but everything else including projectiles and all AI motions. How much to record every shot in progress, all damage data, the position, heading, and axial motions of every plane plus engine states, etc plus a bunch?

People need to spend time thinking instead of dreaming.


Neal<HR></BLOCKQUOTE>

Scragbat
04-17-2004, 08:36 PM
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>...to record every shot in progress, all damage data, the position, heading, and axial motions of every plane plus engine states, etc plus a bunch?<HR></BLOCKQUOTE>

I never said every shot in progress. I meant positional data and physical status at 1 second intervals, which does not include axial motions (if you mean control input).
A snapshot if you will.

I recorded a 1 second 'quick track' of a previously recorded online track (dogfight with 15 other online aircraft) and the resulting file size was not much more than 300K. The initial stage of that file is set-up data (position, heading, damage and all the rest). along with control input recorded after this to tell the aircraft what to do after their positions and status has been set.

My suggestion is just to record snapshots of the set-up data (position and physical status) in a buffered file and not the control data, as that already exists in the main track file.
The set-up and positional data is not in the main track file. It only occurs once at the begining followed by all the control input.
We can't have rewind because there is no positional or physical data to refer to.

Put simply.
There is only control input captured during the recording phase of a track.
During track playback a file could exist that takes snapshots every second of the positional data and physics status which doesn't exist in the original track.
Press a 'rewind' key and the recorded positional data 1 second previously (in the second file) could be loaded in and the aircraft status (and damage model) could be reset to how it was. Then the main track file could backtrack to control input 1 second previously.

Oleg has said that with the physics engine the way it is, it is currently impossible to have rewind. I am only trying to come up with an alternative method. A work-around.

When I hear something is impossible I like to 'think' there could be alternative methods of accomplishing the impossible.

Maybe I'll keep my thoughts to myself...
and dream of improvements.

http://www.appy55.dsl.pipex.com/FB/squigsig.gif
Scragbat's Forgotten Battles Virtual Movies (http://www.appy55.dsl.pipex.com)

[This message was edited by Scragbat on Sat April 17 2004 at 07:58 PM.]

WWMaxGunz
04-17-2004, 10:35 PM
Unless your plane is never giong to roll, pitch or yaw you will need axial positions and angular change rates. You will need velocities on all 3 axes. If not then when you rewind the flight conditions will not be the same. Remember that this rewind is supposed to take you back to a point along the track exactly as it was otherwise when the playback commences it won't play back what you did.

That is for your plane. Will there be any others? then they will also need full data.

Will there be any shooting? Bombs? Rockets?

How about damage? Will the damage states of anything change during the playback?

Will CEM be on? Should engine state be unrecorded? All unrecorded states cannot be duplicated on rewind. Whups.

Somehow I get the idea that something like a recording of what a player gets and sends for online data could have most or all of what it would take to make a positionable playback but I'm not really sure. Online warp in laggy sessions does suggest positional and angular updates at intervals for player A/C at least.

I wonder how big a file you could get capturing all the data needed to describe everything going on for a full mission with even only 8 planes and only the ground objects on a small map (or not be able to bomb a bridge, etc) updated even only every 10 seconds? With a limited rewind capability of only 1 minute or so back maybe it wouldn't swamp freespace on a drive considering that a rewind feature would have to work for all tracks regardless of length of mission.


Neal

Scragbat
04-18-2004, 06:10 AM
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Unless your plane is never giong to roll, pitch or yaw you will need axial positions and angular change rates. You will need velocities on all 3 axes. If not then when you rewind the flight conditions will not be the same. Remember that this rewind is supposed to take you back to a point along the track exactly as it was otherwise when the playback commences it won't play back what you did.<HR></BLOCKQUOTE>

In the 1 second (or so) track I recorded, all this initial data was recorded in the ntrk file along with all the other online aircraft's status, and a bunch of control input that wouldn't be necessary for the snapshot file.

The snapshot file would only be a reference to be used if rewind were a possibility.

Manual time compression in a track gives us 1/4 speed right up to 8x speed.
Rewind with a snapshot reference file would not work the same but would jump back a second at a time, or ten seconds at a time if the snapshots were taken at ten second intervals.

It's not a huge amount of data if it doesn't contain control input. This is proven by the size of the file captured for a 1 second recording of an online track with 15 other aircraft.

The method I refer to would not be capturing data continuosly, only at 1 second intervals and not control input, just what is necessary to get the aircraft into position if you wanted to backtrack.

<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>That is for your plane. Will there be any others? then they will also need full data.
Will there be any shooting? Bombs? Rockets?
How about damage? Will the damage states of anything change during the playback?
Will CEM be on? Should engine state be unrecorded? All unrecorded states cannot be duplicated on rewind.<HR></BLOCKQUOTE>

This was all recorded in the small test track I did. Not an enormous amount of data to snapshot in a reference file (unless you're running FB on a ZX81).

If we want rewind at the moment the track has to start from the begining and everything gets reloaded (map, aircraft, humans etc.). What I say may be impossible because going back a second or ten seconds might mean everything has to be reloaded again which would not be practical.

I except that my idea might be difficult to implement but it is just an idea for the devs.

http://www.appy55.dsl.pipex.com/FB/squigsig.gif
Scragbat's Forgotten Battles Virtual Movies (http://www.appy55.dsl.pipex.com)

TooCool_12f
04-18-2004, 07:56 AM
*.trk files record the inputs. You can't reverse it for a simple reason: every input (the only recorded data) is followed by the reaction it induces. If you want to rewind, you'd have to generate the reaction before reading the input =&gt; can't be done with current system.


With the *.ntrk files, on the other hand, I think that it may be technically possible, since the ntrk files seem to record th "events" and not the "inputs"

ImpStarDuece
04-18-2004, 08:17 AM
Would love to see this feature implemented.

One of the things i would like to see most in any upcoming expansion/addon/new game would be increased speed up and a rewind for my movies, err, i mean trks.

"There's no such thing as gravity, the earth sucks!"

WWMaxGunz
04-18-2004, 09:04 AM
I see what Scragbat is saying is just record the snapshot that begins any ntrk file. If 1 second in the map and with the planes, etc, that he flew makes 300k then the snapshot is even smaller maybe a good bit or maybe not. At one every 10 seconds or so, like a key frame in an AVI, the temporary file would get big but probably not multi-gig size. If the rewind only went back so far (10 or even 100 steps back) then the file size would be more reasonable. It wouldn't be bad if a key could be hit causing a snapshot that you could go back to or along a sequence of.


Neal

Scragbat
04-18-2004, 09:38 AM
Thnx WWMaxGunz,

You summarized better than I could.
I wonder if the snapshot could be taken during the recording of the track at ten second intervals.
It would make the track files bigger but we would be able to jump back ten seconds at a go.
Probably would add a bit of overhead to the recording process though as well as increased file size.

I feel resigned to the fact that we are dreaming when it comes to rewind. I just don't think it's going to happen http://ubbxforums.ubi.com/images/smiley/16x16_smiley-sad.gif
Unless track recording and playback is completely re-written for BoB.

http://www.appy55.dsl.pipex.com/FB/squigsig.gif
Scragbat's Forgotten Battles Virtual Movies (http://www.appy55.dsl.pipex.com)

WWMaxGunz
04-19-2004, 04:50 AM
It would be better if the rewind info was in a seperate file only temporarily stored I think. And if on playback it would only take the snapshot at the press of a key then a pause of the action would not mess with the watcher so much, then still there would need to be buttons for rewind to last saved, to the one saved before last if any and jump to next saved if any...

It's a good deal of coding you better believe since reading the data backwards to find the last saved when each snapshot differs in size is not a small matter if the data is binary coded, there may be no way to have a single unique byte to mark the start of a variable length record that you could just iterate back to and stop on. A unique series longer than a numeric format (over 8 or more bytes possibly) might do, like 00FF x 10, but that's the kind of extra code detail just to find the skip-to spots alone, only a small part of the overall feature. All in all, a nice task to set a person at and don't think it will all be in nice, clean and debugged anytime soon! Yeah, I used to do those kinds of things for a living and if I had the real worth of the overtime for every such requested and made then I'd have lived better in those days so I have sympathy for the 1C team.

Besides, it swells the code to sometimes where some things have to be lost to add the extra. Beware of what is asked for. Beware more for what unlike you, is demanded.


Neal