On Freitag, 2. April 2004 05:47, Jim Wilson wrote:
> Earlier we had a report of a reset issue on the list. It appears that the
> problem only affects a couple JSBSim aircraft...the c172 (all of them) and
> the 737. Everything else seems to trim fine.
Others don't work too. The A320 for example ends upside down too.
> The issue appears to be due to a difference between how the FDM is
> initialized on startup and how it is initialized on restart. On startup
> the FDM initialization is delayed until a tile is loaded for the startup
> location, giving an accurate ground elevation value (test for gound_elev >
> -9990). This test is not possible during the reinit phase, because we're
> only passing through the reinitialize routine once.
>
> The more I look at the workarounds we have been accumulating for making
> flightgear initialize and reinitialize the more I realize that we may be
> frequently taking the wrong approach to solving such issues. We are
> failing to build self-sufficient and self-protecting subsystems.
:)
Hmm, I am not very familiar with the way flightgear interfaces with a FDM.
What I can tell now is that JSBSim has a problem with it's timestepping method
during reinitialization. But Jon and me are working on this.
But this is not the whole problem. Doing this right is not sufficient.
> Which is why I'm calling this a JSBSim bug. If the altitude is < -9990
> and/or the ground_elelvation is < -9990, would it be possible for JSBSim
> to not ground trim and instead go for a coffee or freeze or whatever it
> needs to do while the scenery system gets wound up?
>
> In other words, rather than try and find another bandaid, what I would
> like to do is remove the elevation test from following code in main.cxx and
> let the fdm take care of itself:
I am not shure what happens here. But it appears to me that either
FGInterface::update(double) or FGInterface::init() is called while the
environment (ground level, etc ...) containes senseless data, true?
So, for the coffee question, I think that this could be done.
But you told about self-sufficient and self-protecting subsystems. I don't
think that this goal could be achieved when code, which in effect tests
for an error condition of the tile loader, which is something orthogonal to
flightdynamics, is moved into a FDM.
Just call FGInterface::init() when the FDM has *all* data required for
initialization. The same goes for FGInterface::update(double), it should not
be called when the FDM sees screwed up environment data ...
Or, in other words, why should a FDM need to know that groundlevels below
-9990ft are an error condition of the tile loader?
Greetings
Mathias
--
Mathias FrÃhlich, email: [EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
