Torsten Dreyer a écrit : > I just commited this patch with some changes: > > The properties probe_elev_m[0..4] were uninitialized and used in the Run() > method before being initialized by a scan of the ground elevations. > The first scan was performed after one second, so for the first second the > probe_elev_m were used in an uninitialized state. > > I changed the timer behaviour to run the scan before the probe_elev_m values > are used. > > To check, if this solves (and not hides) the nan issue, i commented out the > line containing the isnan() check. > > Please report, if this works. > > Torsten > > that works here, no more nan, and now time to cross the alps in glider :).
btw is there a particular reason why an unitialized state variable is more often "nan" than on other OS and platform? or is my ram more subject to cosmic ray attack? (here with debian SID 32bits on athlon XP 2800+ single core at 1.8GHz, 2.5 G ram and nvidia 6200, gcc 4.3.3-5, kernel 2.6.26-1-686, SG, OSG Plib and FG all cvs or svn). here's a screen where i got unitialised probe-elev-m, where probe-elev-m[4] is the killer, all the nan in other fields just propagated along the calculs to freeze FG, starting by environment/ridge-lift-fps. jano ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
