The typo was introduced in 7e607b8403 from July
2016. The result was a series of alert messages such as:
savexml: writing to 'Path "/flightgear/home/.fgfs/runtime-jetways/0.xml"' denied
(unauthorized directory - authorization no longer follows symlinks)
This allows the sources and headers in src/Main/ to be used by other targets.
They are grouped into the new "Main" flightgear component via the macro in the
FlightGearComponent CMake module. The bootstrap.cxx file with its main function
has been separated out into a separate variable MAIN_SOURCE for use by the fgfs
binary.
All these files have therefore been removed from the test_suite CMakeLists.txt
file, as they are added via FG_SOURCES and FG_HEADERS. The MSVC grouping code
also does not need to deal with the now deleted separate SOURCE and HEADER
variables for these files.
This is for simplifying the main src/Main/CMakeLists.txt file and allowing the
code to be shared with the test suite.
The generated source and header files have also been removed from the main
source list and placed in the CMake module as the global variables
EMBEDDED_RESOURCE_SOURCES and EMBEDDED_RESOURCE_HEADERS.
New methods Addon::createStorageDir() and Addon::getStoragePath() with
corresponding Nasal bindings in the addons.Addon ghost:
createStorageDir() method (returns the dir, doesn't fail if it already
exists)
storagePath read-only attribute to get the dir
The directory reserved for each add-on is
$FG_HOME/Export/Addons/ADDON_ID, but please use the above methods (or
the corresponding C++ ones) to avoid hardcoding such paths in your code.
Also create directory $FG_HOME/Export/Addons in fgInitConfig() as a way
of reserving the namespace, in order to prevent future failures in case
someone would have the strange idea to create it as a file...
If an add-on has a file named addon-menubar-items.xml in its base
directory, load it and add its items to the FG menubar.
Logically, fgStartNewReset() should call
flightgear::addons::AddonManager::instance()->addAddonMenusToFGMenubar()
in order to re-add the items, however doing so would cause the
add-on-specific menus to be added one more time on every reset, because
for some reason, commit 45ea8b5daa added
the PRESERVE attribute to /sim/menubar (apparently to preserve the state
of menu entries upon reset?).
Note: the addon-menubar-items.xml files are reloaded during reset,
however the menu bar doesn't reflect this, since adding the
reloaded items to the menu bar in fgStartNewReset() would cause
the add-on-specific menus to appear several times in the menu bar,
as explained above.
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.
If running with the launcher, and FG-home is read-only, show a warning
to the user, since this is probably a surprise to them.
(In non-launcher mode we don’t show the box, since it’s more likely to
be an intentional duplicate launch)
This makes it possible to look up files from add-on directories using
for instance FGGlobals::resolve_resource_path(), passing a string such
as "[addon=ADDON_ID]relative/path" as explained in the previous commit.
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/
Several checks were off by one, resulting in a segfault when only one
parameter was missing.
Also improve error messages, giving details about what is expected.
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.
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.
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.
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.
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>.
