#869 IN-AIR FG CRASH in 2.8 stable

[Anonymous]

Originally created by: al.lowe... (code.google.com)@gmail.com

*What steps will reproduce the problem?*
1.--in-air
--lon=-123.2915
--lat=49.3832
--heading=127
--altitude=2918
2. set this up in launcher

3. run fg

System should start in the air, albeit this is a bit low altitude, it should still work. First time, starting the run took far too long at close to 15 seconds, which brought aircraft too close to the surface and we ended up crashing.

Second time, system folded, crashed, aircraft didn't even appear on the screen. Should start up and allow one to continue the flight.

*Any output in the console (black window)?*
Yes:  http://pastebin.com/tZ9EjjFD

*What FlightGear version are you using (when using GIT version, please
mention date)?*

FG 2.8 release. Not GIT.

*What operating system and graphics card?*

kubuntu 12.04, Nvidia GEFORCE 9500 card.

*Please provide any additional information below or as attachment (Avoid
expiring external links, such as to imageshack/pastebin/...).* See attached file; same content as pastebin above.

[Anonymous]

Originally posted by: wonco...@googlemail.com

Even to day, only very few aircraft in FG can be reliably started in-air or reset at runtime, especially the more complex aircraft with lots of Nasal code lack support for proper re-initialization according to the wiki:

http://wiki.flightgear.org/FDM_engine_feature_standardization
http://wiki.flightgear.org/FlightGear_Sessions

According to your logs, the error got triggered when you tried to use the b1900d on multiplayer, right?

It seems that the error propagates from then on to Nasal space, where getprop() statements are not defaulted to 0.00 obviously - so that they return a NaN apparently?

So you could probably try changing the affected Nasal scripts to ensure that getprop() statements always default to 0.00, see this tutorial: http://flightgear.org/forums/viewtopic.php?f=30&t=8483&p=83806&hilit=nan+nasal#p83806

Apart from that, you will need to see if changing some of your settings has a positive effect or not, such as disabling multiplayer or changing the aircraft.

Overall, the real problem is that initialization and re-initialization are not well-supported concepts in FG , so that subsystems like the FDM (and Nasal code) usually cause such errors whenever the simulator needs to be reset to some pre-defined state.

There are only very few aircraft which seem to deal with this properly - usually developed by long-time FG core developers, such as the bo105.

What is really needed is a clear interface of events (property signals) so that event handlers can be implemented which deal with events like "re-position", "reset", "reload" etc - not just in Nasal space, but also in FDM/C++ space.

It is obvious that lots of code in FG always makes very specific assumptions, such as:
- there's only a single aircraft
- aircraft needs to be manually started or via a scripted "autostart" function
- aircraft is usually positioned on ground
- the initial sim state may never be fully reset
- the type of aircraft may never change at run time
etc

[Anonymous]

Originally posted by: wonco...@googlemail.com

To override the getprop() function and re-implement it such that it always defaults return values to 0.0, add this to the top of systems.nas:

var getprop=func(p) globals["getprop"](p) or 0.00;

[Anonymous]

Originally posted by: wonco...@googlemail.com

Actually, at a closer look, it does seem a little confusing that the Nasal callbacks with the getprop(FDM_PROPERTY) calls are all invoked via the "fdm-initialized" signal - which would suggest that the FDM (yasim) doesn't seem to provide sane defaults for --in-air starts for the various FDM-properties, such as /velocities/* and /orientation/* here, even though the "fdm-initialized" property is set already ?

In other words, it would be interesting to see if this could be solved, just by postponing the fdm-initialized signal such that it only occurs after initializing all FDM properties?

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

Unrealted to Nasal (ignore comments above), but an issue with YASim propeller aircraft, see issue 178. YASim FDM won't stabilize when started "in-air" or with a speed > 0.
The visible Nasal errors are subsequent errors caused by the FDM going wild (computation running into NaN).

Mergedinto: 178
Status: Duplicate

[Anonymous]

Originally posted by: wonco...@googlemail.com

> (ignore comments above),

This, sir, is exactly how to stop people from trying to help here.

Like I said in comment #3:
"which would suggest that the FDM (yasim) doesn't seem to provide sane defaults for --in-air starts for the various FDM-properties, such as /velocities/* and /orientation/* here, even though the "fdm-initialized" property is set already ?"

Which would seem to be in line with your diagnosis, and your merging with issue 178?

Again, sorry for trying to help here...