Treat passing nil as clearing the speed / altitude restriction for
the leg. Also default the second arg to ‘at’, so calling these
methods with a single numerical arg is permitted.
Allows creating a new, inactive by empty Flightplan from Nasal. Can
also be used to load a flightplan:
var fp1 = createFlightplan();
var fp2 = createFlightplan("p3.xml");
Rewrite the position-init code for carrier starts, to precisely wait
on the carrier model being loaded, before proceeding with FDM init.
This allows the FDM to see the correct carrier model in the ground
cache, and hence avoids starting in the water.
To implement this, the CheckSceneryVisitor is used to force the carrier
model to be loaded while the splash-screen is visible.
In some testing, JSBsim sometimes passed extremely large values into
this function (larger than the radius of the earth). This causes
every tile on the planet to be scheduled if using the standard STG
terrain, effectively blocking startup.
This code allows us a chance to catch this case via logging, but does
not fix the underlying issues.
The problem is that the two aren't functionally equivalent; the Nasal version would fail silently - whereas the new C++ version gave a runtime error.
The immediate fix is therefore to simply remove the runtime error.
The bug fix is:
- if (!log.output) {
+ if ( !(*log.output) ) {
(i.e., testing the sg_ofstream instance instead of its address) and then
ensuring that the corresponding Log instance is removed from _logs and
destroyed.
The "destroy" part is made automatic by using std::unique_ptr instead of
raw pointers. This allows to simplify several areas of the code.
Don't provide custom definitions for the constructor and destructor of
FGLogger anymore, now that they don't need to do anything: IIRC, this
allows compilers to do some optimizations according to the C++ standard.
Since the paths of files overwritten by FGLogger come from the property
tree[1], they must be validated before we decide to write to these
files.
[1] Except for the "empty" case, which uses the default name
'fg_log.csv'. This file is deemed acceptable to overwrite in the
current directory, as the name is completely fixed and clearly
FG-specific.
Call fgInitAllowedPaths() right after Options::processOptions() (which,
among other things, determines $FG_ROOT and processes
--allow-nasal-read). This way, fgInitAllowedPaths() can be used in much
more code, such as when initializing subsystems.
Improve performance of Nasal properties access
by implementing the setValues/setChildren props.nas
functions in C++. Naive implementation effectively
copying the Nasal versions verbatim.
However, on a test suite writing 1000 Canvas paths,
results in a 50% reduction in runtime, and significant
reductions in memory occupancy.
On a much larger task (5500 paths) results in a 30%
reduction, probably due to Nasal GC.
Use base 26 numbering with letter-only digits for resource indices in
the C++ files generated by fgrcc. This is needed because, for instance,
'resource10' appears not to be a valid C++ variable name, mpfff...
Translations/en_US/FlightGear-nonQt.xlf is for a proper English
translation, where for instance "found %n airport(s)" would have two
plural forms, "found %n airport" and "found %n airports" (most
non-plural strings can be taken verbatim from the default translation,
and at this point there is no plural form at all yet).
As they are registered here, the files will have virtual paths such as:
/Translations/de/FlightGear-nonQt.xlf
/Translations/en_US/FlightGear-nonQt.xlf
etc.
for the EmbeddedResourceManager ('/' being the default virtual prefix).
This reduces the log noise in release builds, relating to AI ground-nets
with incomplete data, especially the commonly occurring ‘gate XYZ
doesn’t seem to have any routes associated with it’ message.
https://sourceforge.net/p/flightgear/codetickets/1974/
Updating the value takes immediately, as it did in 2017.1 and prior.
Additionally, passing —download-dir on the command-line is detected
and handled specially; the UI option is disabled, and no changes are
made to the value passed in. (The launcher does not override the value
with any value it has saved)
using --addon=/foo/bar does
* add /foo/bar/config.xml as propertyfile
* add /foo/bar to aircraft_paths to provide read-access
* sets property /addons/addon[n]/path = "/foo/bar"
* addons get initialized from addons.nas in FGDATA/Nasal
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.
Ground-bit is set manually (via the transponder GND knob position) or
automatically using a property referenced in instrumentation.xml.
Aircraft will only transmit these new properties when using the
multiplayer v2 protocol.
This adds console and message-box warnings, based upon aircraft
declaring the minimum FG version they support. A follow-up commit
will extend the launcher UI to warn the user about this in a nicer
way.
This is a headless mode, designed to be invoked from an installer, not
used directly by users. It doesn’t touch the ‘normal’ installation, but
rather removes the other files FG typically creates or downloads.
When building with MSVC, use the CMAKE_MSVCIDE_RUN_PATH variable to
prepend ${MSVC_3RDPARTY_ROOT}/${MSVC_3RDPARTY_DIR}/bin to the PATH in
order to (hopefully) allow fgrcc to find the libraries it needs. We may
need to add something similar for SimGear---will see.
The use of CMAKE_MSVCIDE_RUN_PATH and other ways to address this problem
are discussed at
<https://stackoverflow.com/questions/28533012/how-to-set-runtime-path-for-cmake-custom-command-on-windows>.
