Handle the standard windows-3rd-party setup (used by fgmeta) with no
extra options, and also handle the slightly odd setup we use on Jenkins.
Try to tolerate all permutations of setting MSVC_3RDPARTY_ROOT to
different places in the hierarchy.
We no longer try to guess Boost_INCLUDEDIR by looking at parent dirs of
MSVC_3RDPARTY_ROOT, since this seemed kind of bad to me. Let’s try
it and see.
- fgfs --language=fr-FR now works as expected for the launcher (also with
--language=fr_FR as before): the value added by option --language to
the _languages member of FGLocale is normalized in "underscore" style
(e.g., fr_FR).
- Add-on translations must now use a hyphen in their property node names
in addon-metadata.xml (talking about children of <localized>): i.e.,
use for instance <fr-FR> there, not <fr_FR>. An exception
(addons::errors::error_loading_metadata_file) is thrown if one of
these nodes has a name containing an underscore.
Allow add-ons to define an FGData subdir, and support multiple —data=
command line arguments, to avoid the need to modify FG_ROOT (which might
be read-only). Allow additional data paths to be either higher or lower
priority than FG_ROOT, so that add-ons cannot replace files in FG_ROOT.
Suggested on the tracker, keep log files around longer. Currently we
keep the previous ten files.
Note we still don’t log for secondary running copies, since this would
violate the ‘only one copy can write to FGHome’ principle.
https://sourceforge.net/p/flightgear/codetickets/2243/
This avoids crashing when using Qt : we cannot call exit() safely since
QGuiApplication won’t shut down correctly. Instead throw a special
marker object and catch this in boostrap.
For an instance of this, see:
https://sourceforge.net/p/flightgear/codetickets/2070/
Was being shown before locale was selected, so always using default
translation. Fixed by deferring the dialog, and also added an assert
for debug builds, if trying to access translated string too early.
Ensure /orientation/heading-magnetic-deg, etc have a type of double
immediately. Showed up as a bug in the SenecaII, since the property
is created but has NIL value until the first update() call.
Re-work how position-init and ATC-manager work together to do
parking assignment and fallback (when the parking is unavailable).
Improve the logic for the reposition case, and teach ATC-manager about
reposition explicitly.
When the parking is unavailable, explicitly fall back to best-runway
selection in finalizePosition.
Add many additional position-init tests, to cover all of this.
Add translation macros for the text of the lock-file warning dialog,
and update the default text after some discussion on the devel list.
Also allow quiting the app, as an alternative option.
See ticket:
https://sourceforge.net/p/flightgear/codetickets/2133/
Give the user a chance to intervene, if we select read-only mode.
Offer a button to clear the lock file if it’s stale, and start in
read-write mode.
This is still evolving, but want to get some feedback on it.
Takes special values "FLOLS" and "abeam" to set up
aligned for final approach or at the 180 for the carrier flight
deck. Or alternatively a catapult or parking position.
Support for --carrier-abeam option, which places the aircraft
at the end of a downwind opposite the FLOLS.
Add launcher support for above.
Add carrier display for launcher showing position relative to
carrier.
making the build between Simgear and Flightgear consistent.
- Fix an issue with lib/lib64 path between CentOS/RedHat distributions
and Debian derived distributions.
- Fix a compilation issue with HLA in the Flightgear code.
Allow selecting carriers from scenarios, and starting at either a
parking position, or a distance offset from the FLOLS (effectively
a crude ‘on-final’)
Extend the —carrier startup option to accept a runway ident of FLOLS,
in conjunction with the existing —offset-distance argument.
Previous implementation wasn’t correct, use a better one now. In the
case of a non-clean exit we will leave a stale .pid file in FG_HOME,
but we clear stale files on the next launch.
Still not complete, but now we set the command line args to be UTF-8 on
Windows, we can strip out more of the ‘local 8-bit’ places (which
screw up, generally).
Refactor to break circular references.
New custom target generates the resource files.
FGFS and Test_Suite targets declare a dependency to the generated files.
This prevents the changing of the logstream priority as set by the test suite
permanently to "alert" during the execution of tests. Setting a default value
of SG_ALERT is not required as this is the simgear logstream default anyway.
This is a clean up commit prior to the subsystem API standardisation to simplify
the diffs. It includes all SGSubsystem and SGSubsystemGroup derived classes.
Using Emesary Global Transmitter the following events are notified
* Frame Begin
* Frame End
* Mainloop started
* Mainloop stopped
This integrates with the background threaded Nasal Garbage collection (simgear:nasal/cppbind/NasalEmesaryInterface.hxx) and is also controlled by the properties as follows
* /sim/nasal-gc-threaded (true) - use background threaded GC
* /sim/nasal-gc-threaded-wait (false) - at the start of the frame wait for the previous GC thread to complete.
I initially thought that the wait at the start of the frame would be necessary; however in 100 or so hours of flight without the await for completion at the start of frame no threading problems (or any other problems) were shown; so nasal-gc-threaded-wait is defaulted to false which gives a slight boost in performance.
So what this does is to it removes the GC pause of 10-20ms every 4 seconds (test using the F-15). This change doesn't really give much extra performance per frame because normally GC is only performed when needed.
Neither Torsten nor I can recall why we continued to hard-code this,
so make it dynamic for now. When we remember why we hard-code it,
we can add a BigComment from future-James to future-future-James about
why not to do this again :)
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.
When an explicit aircraft-dir is set, check this location before
checking installed packages. This allows setting —aircraft and
-aircraft-dir to correctly take precedence over a package.
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.
