Change fgcommand to take an optional property tree root element.
This fixes the animation bindings to use the defined property tree root - to support multiplayer (or other) model that can bind to the correct part of the property tree.
Requires a corresponding fix in sg to allow the command methods to take an optional root parameter.
What this means is that when inside someone else's multiplayer model (e.g. backseat, or co-pilot), the multipalyer (AI) model will correctly modify properties inside the correct part of the property tree inside (/ai), rather than modifying the properties inside the same part of the tree as the non-ai model.
This means that a properly setup model will operate within it's own space in the property tree; and permit more generic multiplayer code to be written.
This is probably responsible for some of the pollution of the root property tree with MP aircraft properties.
Modify startup sequence, so position can be modified late in the startup process, right before the scenery load starts. This allows two ugly hacks to move to a permanent, less hacky location. If other position init modes required similar late evaluation in the future, this can be accommodated now.
This is a somewhat high-risk change - I've tested both carrier starts and runway-selection based on realwx METAR, but please look out for other position-init issues and test before / after this patch.
New commands request-metar and clear-metar will bind metar reports to an arbitrary property tree path. E.g:
fgcommand("request-metar", var n = props.Node.new({ "path": "/foo/mymetar", "station":"LOWI"}));
- initialize uninitialized properties
- use prefix instead of postfix increments
- reduce visibility of variables
- use empty() instead of size() == 0 for vector and string
- pass string by reference, not by value
Untieing needs to be done prior to the destruction of the object which
aggregated the TiedPropertyList. So the TiedPropertyLists destructor can't
untie the properties automatically (and it doesn't). So, do some manual
clean-up.
Catching loader thread on subsystem destruction is too late, since it
depends on other subsystems (which are destroyed earlier).
=> Need to stop & join thread during subsystem shutdown.
Also changed loader sleep logic - to avoid excessive delays (up to
30 seconds) on shutdown.
(Issues mostly happened when running offline with realwx enabled.)
This patch enables multiple MetarProperties instances tied to the
property tree. For each node's value of /environment/realwx/metar
one MetarProperties instance is created and tied to the property
tree named there. (See FGDATA/Environment/environment.xml for details)
At least one instance will be created to provice backward compatibility
to the existing live-data weather system. This instance (tied to
/environment/metar) fetches a METAR for the nearest airport at a regular
schedule. All other instances fetch a report for airports named in the
property station-id. It re-reads the report every 15 minutes, the
remaining time until the next fetch will be scheduled is in the property
time-to-live. This property can be written to, to extend the live of
this report or schedule an immediate reload by setting it's value to zero.
This patch also provides magnetic variation for the station's location.
If "Live data" was disabled in any way in the global-weather dialog
and reenabled later, the next metar fetch occoured only after up
to 15 minutes after the report expired. This patch triggers triggers
an immediate fetch of a metar after enabling live data.
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.
This is the initial commit for a reworked environment controller.
The main intention is to decouple the individual modules like
metar fetch, metar properties, environment interpolation etc.
to make it easier for other weather module developers to modify
environment settings.
As a side effect, the dialogs for weather-scenario, weather-conditions,
clouds and precipitations have been merged into a single dialog