Enhancements suggested by Nikolai Verner-Christensen - support loading
scenarios from {FG_HOME}/Scenarios, {aircraft-dir}/Scenarios and
{add-on}/Scenarios.
Additionally, allow passing the path to a scenario file to
—ai-scenario, eg —ai-scenario=/home/jmt/FGFS/my-test-scenario.xml
When a scenario defines a carrier, and —carrier is used to request a
carrier start, we now auto-load the corresponding scenario, to give
a nicer user experience.
- pass texture cache control properties to simgear
- /sim/rendering/texture-cache/cache-enabled
- /sim/rendering/texture-cache/compress-transparent
- /sim/rendering/texture-cache/compress-solid
- /sim/rendering/texture-cache/compress
- support --texture-cache-dir command line option
- set max reported supported texture size during splashscreen.
The add-on framework now uses the following files in each add-on
directory:
- addon-config.xml (previously: config.xml)
- addon-main.nas (previously: main.nas)
This is consistent with the addon-metadata.xml file that is already part
of the interface between FG core and add-ons. The goal is to make it
clearer, when browsing an add-on directory, which files belong to the
"FG core <-> add-on" interface and which files belong to the add-on
proper. This will be beneficial also when more files are added to the
"FG core <-> add-on" interface, such as possibly addon-events.xml in the
future.
This change is incompatible, thus it is the right time to do *before*
2018.2.1 is out, especially considering that this upcoming release
already has incompatible changes in the add-on API, namely the
requirement of the addon-metadata.xml file and the type of the argument
passed to each add-on's main() function. We'll try harder not to break
compatibility in the add-on API once 2018.2.1 is out. For now, it is
still a good time to try to get the API as clean as possible.
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
Doing the option processing in Options::parseOption() has drawbacks:
- doesn't work well upon reset;
- doesn't work in the built-in launcher Additional Settings box.
Options::processOptions() is invoked both upon reset after the property
tree has been reset, and by the built-in launcher to process options
given in the Additional Settings box. This is not the case of
Options::parseOption() which is better for... parsing. :-)
Also use SGPath::fromLocal8Bit() to decode the path argument of --addon.
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
Print an error message and exit if --{enable,disable}-enhanced-lighting
or --adf are used (those deprecated options will be removed in a future
version of FlightGear).
The options.cxx code is not ready to handle recursive use of --config
(for config files). Instead of failing in an ugly way, abort with a
clear error message in such situations. See discussion at
<https://sourceforge.net/p/flightgear/mailman/message/35838852/>.
Note: it *is* possible to load XML PropertyList files from config files,
so --config is not entirely "banned" from config files.
+ add missing include
Before SimGear commit a962c90b30f36575d01162b64471fa77473237a0,
SGPath::pathListSep was a char in static memory that was not necessarily
followed by '\0'. As a consequence, using &SGPath::pathListSep as a
C-style string could result in a string containing the correct separator
*plus* whatever followed in memory until the first null byte...
SimGear commit a962c90b30 changes this situation by making
SGPath::pathListSep an array of two const chars: the path list separator
followed by a '\0'.
This commit simply adapts FlightGear to this change, which fixes a
couple of bugs where the separator was used, mainly unneeded NavCache
rebuilds due to the "apt.dat", "fix.dat" and "nav.dat" properties in the
SQLite database containing the correct paths separated by a possibly
incorrect separator string (there was no alteration of the cache
contents as far as I can tell, since the db property is only used to
check if the lists of apt.dat, fix.dat and nav.dat files have changed).
- Rename fatalMessageBox() to fatalMessageBoxWithoutExit(). This should
prevent the kind of bug that prompted this set of changes: someone
calling fatalMessageBox(), assuming the program would stop at that
point, whereas in reality it did not.
- Add new function fatalMessageBoxThenExit(). This is not vital of
course, but allows one to spare one line here and there and to apply
the DRY principle for such fatal exits.
- Replace every existing call to fatalMessageBox() with one or the other
of the two new functions. Improve formatting along the way. This
fixes a few bugs of the kind explained above.
Compile a useful subset of FG as a shared library, and add two basic
uses of this to exercise some Flightplan / RoutePath / navaid
functions.
The test framework can/will be expanded incrementally from here, this
is just a starting point.
As part of this, add the ability to distinguish default vs explicit
airport selection via a new /sim/presets/airport-requested flag. This
enables us to more cleanly handle different combinations of startup,
especially the case where the user requests an airport but no runway
(wants auto selection), ensuring we don’t look for the default airport’s
runway (from location-presets.xml) in that case.
- Declare 'datTypeStr' and 'defaultDatFile' as public member variables
of NavDataCache ('defaultDatFile' is not *required* for this commit,
it just seems to make sense to treat both members the same way/keep
them together in the source code).
- New keys under "navigation data" in the JSON report: "fix.dat files"
and "nav.dat files".
Make a single Cmake value to expose the build type to code, and use
this to default a run-time ‘developer-mode’ property, which can be
over-ridden from the command line.
Use this to drive the different warning levels. Policies subject to
review, especially whether nightly builds should default to
developer mode or not.
This change is the logical counterpart of SimGear's change from commit
79f869a7f32910197be72b21f6489fbbba02c836 that moved the following files
from simgear/misc to simgear/io/iostreams:
gzcontainerfile.cxx
gzcontainerfile.hxx
gzfstream.cxx (formerly zfstream.cxx)
gzfstream.hxx (formerly zfstream.hxx)
sgstream.cxx
sgstream.hxx
sgstream_test.cxx
Each argument creates another log file, in the directory named. Symbolic
value ‘desktop’ creates logs on the user’s desktop.
Needs corresponding SimGear commit to build
Requires FGData commit: 0565eaab10a5d466cd485766b17d1870936a0a57
(which actually renames the file).
Also disables the preferences-load command since I don’t believe it
would actually be safe to reload the defaults without doing a simulator
reset (aircraft -set.xml values would be overwritten, for example)
As discussed on the devel list, only require the major+minor versions
of FG+SG+data to match by default. If we encounter a situation on
a release branch where stronger checks are needed, it’s easy to
restore.
Essentially, adapt two places where options.xml was supposed to be found
in $FG_ROOT (in one of these, the comment was already incorrect way
before the recent change moving options.xml out of FGData).
$FG_INSTALL_PREFIX represents the FlightGear installation prefix, such
as /usr, /usr/local or /opt/FlightGear on Unix systems. Copying the
--help output and translated strings there avoids having to write to
$FG_ROOT when 'make install' (or some OS-dependent equivalent) is run
from the FlightGear build directory---that would be ugly when $FG_ROOT
points to the FGData Git repository.
In FGLocale::FGLocale(), Translations/locale.xml is loaded using
readProperties() and fatalMessageBox() (in case an error is
encountered). Note that it couldn't be loaded via fgLoadProps() in the
current state, because this function relies on guiErrorMessage() when an
error is encountered, which calls mkDialog(), which itself does
globals->get_subsystem("gui"). This last call can't be done from
FGGlobals' constructor---where the 'globals' pointer is still
NULL---hence the need for a different mechanism not relying on
FGGlobals.
For consistency, and also because it provides a better user experience[1],
load options.xml using the same method instead of with fgLoadProps().
[1] I.e., in case of an error, the user gets to see a graphical popup
window with an explanatory message before FG exits, assuming he is
either on Windows, or on Mac, or has Qt support built in FG, as
opposed to only an SG_LOG() call [because when options.xml is
loaded, guiErrorMessage() used by fgLoadProps() can't use the 'gui'
subsystem].
