I have _probably_ found at least one reason for this bug.
I was able to constantly create a FPE when running fgfs --enable-fpe
and /sim/traffic-manager/enabled=true
I was able to locate the offending code in FGAISchedule::update when the new
position of some AI aircraft was calculated by
Hi,
On Sunday 14 June 2009 10:48:03 Durk Talsma wrote:
/home/durk/src/OpenSceneGraph/src/osg/PositionAttitudeTransform.cpp:63 #1
0x7fbf16244187 in osg::Transform::computeBound (this=0x9d1d3b0) at
Well the PositionAttitudeTransform is used now for everything having a
SGModelPlacement. May
Folks,
Here's a rather long overdue follow-up to my own previous mail.
On Tuesday 26 May 2009 22:37:45 I wrote:
Thanks for your suggestions. I've been trying to track this down, but don't
have anything firm yet. My current working hypothesis is that a stack
corruption may be feeding bad data
Hi Tim,
On Wednesday 20 May 2009 10:06:18 Tim Moore wrote:
It may be helpful to dump the scene graph to a file (from the debug menu)
once you're getting the NaN error. Hopefully the offending matrix will
be printed with NaNs instead of valid coordinates.
Tim
I've added an --enable-fpe
Tim Moore wrote:
Durk Talsma wrote:
On Friday 15 May 2009 20:31:17 Durk Talsma wrote:
While trying to trap bad data in this the popMatrix function, I just
noticed that a bad transformation matrix is already set up relatively
early in the process, only a few levels deep at the stack. I
On Wed, May 20, 2009 at 6:06 PM, Tim Moore timo...@redhat.com wrote:
Tim Moore wrote:
Durk Talsma wrote:
On Friday 15 May 2009 20:31:17 Durk Talsma wrote:
While trying to trap bad data in this the popMatrix function, I just
noticed that a bad transformation matrix is already set up
On Thu, May 21, 2009 at 12:55 AM, George Patterson
george.patter...@gmail.com wrote:
On Wed, May 20, 2009 at 6:06 PM, Tim Moore timo...@redhat.com wrote:
Tim Moore wrote:
Durk Talsma wrote:
On Friday 15 May 2009 20:31:17 Durk Talsma wrote:
While trying to trap bad data in this the popMatrix
Heiko Schulz wrote:
I think the pa24-250 is another user of this. Does this aircrafts
also cause this NaN-errors?
Hi Heiko,
The pa24-250 uses Aircraft/Instruments-3d/comp/comp.xml.
Regards,
Dave P.
--
Crystal
Hi All,
Thanks to a report by regular Forum poster MD-TERP (a.k.a. Rob), we found a
way to trigger the infamous NaN warning in a rather reliable manner. Following
up on this lead, I modified OpenSceneGraph so that it deliberately segfaults
when the warning message is triggered (I know, I could
Here is a quick thought (not having thought this all the way through.)
Originally we only queried the altitude of a single point beneath out
aircraft. As we've move forward, we now have created a cache of local
triangles and can query the altitude of each wheel and contact point. But
also we
Hi,
interesting to see that a small instruments can make such big troubles.
What me wonders: Aircraft/Instruments-3d/mag-compass.xml isn't only used by the
c172p than by other aircrafts as well. I think the pa24-250 is another user of
this. Does this aircrafts also cause this NaN-errors?
I
Hi,
On Friday 15 May 2009 20:10:01 Heiko Schulz wrote:
Hi,
interesting to see that a small instruments can make such big troubles.
What me wonders: Aircraft/Instruments-3d/mag-compass.xml isn't only used by
the c172p than by other aircrafts as well. I think the pa24-250 is another
user of
Seems my first answer failed with the c172p.ac attached..
I removed some double vertices on the interior-object, and I hope this was the
cause for the trouble.
You will find the improved here:
http://gitorious.org/c172p
command: git clone git://gitorious.org/c172p/mainline.git
Regards
HHS
I'm not sure about this, but my estimate is that the trouble doesnt arise
when the mag-compass is part of the user aircraft, but only when it's part
of the exterior world, i.e. when part of an AI aircraft. Also, it's
possible that the instrument by itself may be okay, but triggers an error
in
14 matches
Mail list logo
