"Curtis L. Olson" <[EMAIL PROTECTED]> said:

> I've fixed a couple problems in timing where an int was used to count
> microseconds ... I sat down and figured it out before, but this gives
> you somewhere in the neighborhood of 30 minutes depending on if you
> are using a signed or unsigend int.  When this rolls over, you get a
> huge delta t passed to routines.  This in the past has cuased things
> like the instrument panel not updating it's text for 30 minutes, or
> navaid lookups failing after 30 minutes.
> 
> What you describe sounds suspiciously like the same sort of thing.
> 
> We should probably take a look at what units the dt is passed in, or
> if a time difference is calculated someplace, what limiting
> intermediate structures might the calculations be passed through.
> This is an insidious bug because you can test things for a few minutes
> and they work fine, but try a long cross country flight and things
> start to break or blow up.
> 

Yes, it is weird though.  What you describe is was what I first thought, but
I'm following the data from the calling functions in Main, through the
specific FDM (YASim), to the flight.cxx function.  Delta time is the same
exact value in Main and YASim::update(), but in FGInterface::_calc_multiloop
it is suddenly a different value.  Normally only off a small amount, but in
the case of the 747 at KBGR it is off 3700.  Everything looks defined properly
(double dt) and the values are initialized.  It almost seems like a compiler
issue.

That's why I'm wondering if other folks see something similar.   Looking at
the Simpsons, the delta_time_sec in "Main" should be the same as dt in
_calc_multiloop, even if it isn't calculated correctly.  And it isn't.

Best,

Jim

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to