Hi Peter,
I haven't had a chance to look at this closely, but maybe I can offer a
small bit of insight.
We recognized that to record hours of high resolution flight data would blow
up the memory footprint of FlightGear on any PC. So we went for a balance
...
We record the most recent 60 seconds of data at full resolution, then the
previous "n" minutes (I forget the exact number) is recorded at 1 second
intervals. And then I think we go even further back recording at an even
sparser interval. This way you get something as far back as you like, and
you get high detail if you replay the last 60 seconds.
Somewhere along the line a bug got introduced which I unfortunately haven't
had a chance to dig into ... it's been there for a long time now.
Originally, the recorder got turned off during the replay. Now the recorder
continues to record while you replay ... so you are recording the replay as
you replay it and you sort of end up with a recursive infinite loop. This
actually has a nice feature that when you replay a flight, it loops for ever
until you quit the replay, but know that each time through you are replaying
a recording of the previous replay, and losing resolution each time through
the cycle. So that's a bug, it needs to be fixed, I haven't had a chance to
dig into it.
The problem with this particular bug is that because you are recording as
you replay, you never actually get to see that 60 seconds of highly detailed
data (assuming you replay more than 60 seconds which most people probably
do.) So we are missing out on all the subtle nuances of your landing when
you replay your landing for instance.
One other thing. The data structure that is recorded is the FGNativeFDM
structure defined in src/Network/native_fdm.hxx. You do bring up a good
question: what values should be recorded every frame? Given that aircraft
designers can make up their own properties and drive them with nasal or
other means, we can't know in advance a fixed set of property names that
cover every situation.
So for the replay system we decided to go with a fixed, pre-defined binary
structure ... and then you do live with a few replay warts if you are
viewing an aircraft that uses "non-standard" properties ... and that's not a
knock on the aircraft designer ... some airplanes have more than 4 engines,
the AN-225 has like 185 landing gear assemblies, many aircraft have unique
control systems and control surfaces ... and we can't take 20 minutes worth
of snapshots of the entire property tree @ 60hz ... not on my PC anyway.
So the 60 second marker you mention is interesting ... that could correspond
with the system that records the most recent 60 seconds at a high data rate.
There could be some boundary logic there that didn't take every possible
situation into consideration.
Best regards,
Curt.
On Tue, Mar 16, 2010 at 9:29 PM, Peter Brown wrote:
> As I have not been able to find any doc's or forum topics expounding on it,
> could someone explain a few things to me about Instant Replay?
>
> First off, what parameters are logged by it, or what defines if a parameter
> is logged by it? ie, thrust reverser use do not replay, but flaps do.
> This doesn't seem to be by model builder choice (?), unless Instant Replay
> is tied into multi-player parameters?
>
> Secondly, in using it to test a few modifications, I found this
> sort-of-an-issue. I say sort-of, for it would be rare for someone to find
> it. Took me 2 years.
> - If you start FG, and attempt to use Instant Replay with the
> default 90 second timeframe in _less than 60 seconds Sim time_, FG will
> crash with a CullVisitor~nan nan nan error.
> - And so, if you start FG and set the replay time for a shorter
> period than sim time, it will work.
> ....makes sense, other than it shouldn't crash FG.
> But, if you wait for the Sim clock in the property browser to reach
> 60 seconds, you can enter _ANY_ duration into the replay time menu (200
> seconds for example), and the replay function will simply drop you back at
> the spawn location until the clock counts down to your spawn and movement
> time.
>
> So, why won't it do that under 60 seconds?
>
> I only found the issue since I was attempting to see what I could make work
> in replay. So, it's not really an issue, but thought I'd pass it along. If
> someone can fill me in on the first question about what is or can be tied
> into the replay function for aircraft parameters, that would be great.
>
> Thanks,
> Peter
>
> ref: tested senario in 2 aircraft and the mibs, to ensure consistency.
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
