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"}));
- Only render the canvas if something has actually changed
(Currently checked by looking for modified properties).
- Only write bounding box to property tree if it has been
recalculated (until now this happened every frame).
Low spin or switched off gyros result in the indicator being stuck.
When the gyros are repowered, the indication doesn't jump to the correct
indication, but keeps the current error.
so they can instantly adjust to the changed environment.
(Not fully working yet, since some environment settings, like environemnt
pressure/temperature, still changes slowly after a sim reset - instead of
immediately jumping to the new setting. Also, METAR sometimes arrives too
late...).
In advance of converting the Map and NavDisplay to use the canvas, expose the full route-path vector for each flight plan leg, as a vector on the leg. Use leg.path() to get this.
E.g.:
var fp = flightplan();
for (var i=0; i<fp.getPlanSize(); i += 1)
{
var leg = fp.getWP(i);
debug.dump(leg.path());
}
Break some subsystem dependencies, by explicitly using properties to read the primary position, orientation and velocities. (Instead of directly accessing the primary model placement). This means a couple more globals can die.
Keep distro packagers happy by having the option to use the system's sqlite library instead of our bundled version. Set SYSTEM_SQLITE=1 when running cmake to use the system one.
Cache the parsed navigation and airport data in a binary file to reduce
startup times and memory consumption (since only referenced FGPositioned
elements are held in memory).
Data will be reimported when the mod-time of any input file is changed.
If a global file is changed (nav.dat, awy.dat, apt.dat, etc), the cache
will be completely rebuilt, which takes approximately 30 seconds on
moderate hardware. (Future work may reduce this).
Various classes derive from SubsystemGroup, but extend the init behaviour. Fix those for the incremental init scheme, generally by forcing their init to be atomic. Can convert them to be truly incremental in the future if it's needed, but probably not.
Currently if a SGPropertyNode is removed from the property tree
only for this single node a childRemoved event is triggered. So
if we just check for a specific child to be removed, we will never
be notified. This commit manually triggers the event recursively
for all children but this should probably go directly into simgear.
Separate other init functions from position init, since they are unrelated, and made fg_init.cxx very complex. Next step will be brining some sanity to the position init logic :)
(Requires latest SimGear!)
Break fgInitSubsystems into several phases - subsystem creation, then binding and then init. Run init over multiple main-loop iterations so the application stays responsive to GUI/OS events during init.
There should be no behaviour changes due to this, except that during init Windows and OS-X should no longer show the beach ball / 'application not responding feedback', hopefully.
Remove various hacks and make magvar work like a normal subsystem, as part of the environment manager. Fix the remaining users of the globals->get_mag accessor, and hence kill off the global pointer.
