This is an ugly hack for automatic runway selection on startup based on
metar data. It's main intention is to make startup.nas obsolete and
to guarantee the same runway selection logic as used for AI traffic.
Calling presets-commit from startup.nas during the initialization
sequence caused occasional trouble and sometimes, the AI traffic
operated on the opposite runway.
The tag <initialize-to> can be used to control the value
of the output when the component is first enabled. This
controls initialization of the output property and the current
value for internal computation
Valid values are
<initialize-to>input</initialize-to>
set the output-property to the input value
<initialize-to>output</initialize-to>
set the output-property to the output value
<initialize-to>none</initialize-to>
ignore input and output value
_dialog_props holds SGSharedPtrs (pointers managed by reference counters).
Explicitly casting the object to an unmanaged SGPropertyNode* and deleting it
may cause heap corruption, since the following assignment "_dialog_props[..] = ..."
also tries to delete the (already deleted) object.
The automatic runway selection code in startup.nas depends
on a valid metar before /sim/signals/nasal-dir-initialized
is fired. If the METAR arrives after that signal, no automatic
runway selection is performed. This patch waits for a METAR
on the first update() loop of the subsystem.
Signature of Predictor::configure must match AnalogComponent::configure,
otherwise the inherited method isn't overridden.
=> predictor couldn't be configured.
=> speed predictor rules in "generic-autopilot-helper.xml" weren't working.
"nav-loc" and "has_gs" properties were not updated when nav receiver was rebooted.
Shutting down the nav receiver clears all nav outputs (including "nav-loc" and "has_gs").
=> When nav receiver is powered again, all outputs must be updated.
=> "nav-loc" and "has_gs" are only updated when active nav station changes.
=> old nav station must be cleared on shutdown to enforce update on nav reboot...
