David Megginson wrote:
Yes, it needs to be cleaned up and properly documented. The idea is that you can have an environment manager that sets the values under /environment as you fly. The hard-coded manager right now uses the /environment/config values; I assume (though I haven't checked) that the METAR support uses its own environment manager and disables the current one -- in that case, the values under /environment/config would be ignored.

If, on the other hand, the METAR support is not a manager itself but simply a way of initializing the current manager, then disregard what I just wrote; in that case, the values under /environment/config are significant.

I believe it is setup as a way to initialize the current manager ... you might want to take a look at the way it is set up. If the person working on this didn't fully understand your design/intent here, they may not have quite got it right. They seem to have derived an FGMetarEnvironmentCtrl class but are just using it to initialize the default environment manager values.


In a METAR, the altimeter setting is adjusted to sea level, while the temperature is the actual temperature at station elevation. Use the properties temperature-degC and pressure-sea-level-degC (wherever appropriate in the tree under /environment) and things should take care of themselves.

But this assumes that the aircraft is properly initialized at ground level at the station id location when the properties are set.


It could very well be that the station location is different than the aircraft initialization location and I'm not sure I want to put my money on weather or not the aircraft is properly initialized or the current tile is even loaded (and thus ground elevation known) by the time the metar is fetched and initialized.

However, it's pretty easy to look up the altitude of an airport given it's id, so I have added code to do that. And I've extended one of the built in commands to set oat to honor an altitude if specified, rather than just taking the current altitude.

I'll try and check in my changes shortly.

Curt.
--
Curtis Olson   Intelligent Vehicles Lab         FlightGear Project
Twin Cities    [EMAIL PROTECTED]                  [EMAIL PROTECTED]
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org


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

Reply via email to