If all bools in a block are 0 the block would never be transmitted, i.e. fix a bug whereby each block of 0..30 used to need at least one true value to transmit the block.
This should help with a white-screen in the launcher Gijs reported,
due to our Optimus selection symbol interacting weirdly with the
dynamic OpenGL detection in Qt
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.
This required many time related include files, functions, and variables to be
tested for via CMake, and converted to macros via #cmakedefine, so that they
would be automatically set for the test-mktime.cxx file.
Since the new _storagePath data member internally contains the add-on
id, changing _id after _storagePath has been initialized would make both
data members inconsistent. As changing the add-on id is probably not a
very useful operation, the simplest way to prevent such an inconsistency
from happening is to make Addon's _id data member const (as is already
the case for _storagePath), and thus remove Addon::setId().
Consequently, remove the Addon default constructor too, since add-ons
with an empty id would be ill-formed and couldn't be changed (_id being
const now). This leaves us with one Addon constructor:
Addon(std::string id, AddonVersion version = AddonVersion(),
SGPath basePath = SGPath(), std::string minFGVersionRequired = "",
std::string maxFGVersionRequired = "",
SGPropertyNode* addonNode = nullptr);
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...
It is the call to exit that causes FG to lock up and become a zombie.
Alternative is to throw an exception, i.e.:
throw sg_error(std::string("YASim SOLUTION FAILURE:") + a->getFailureMsg(););
This adds the fix for non converging aircraft. Henning has performed a thorough analysis of all of FGAddon and other repositories and there are a few models that fail, however there have always been a few that fail - but with this patch this situation is improving.
As for aircraft, an add-on can now add its custom dialogs in
$addon_dir/gui/dialogs. This commit makes NewGUI consider this directory
as a dialog-providing one for each registered add-on.
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.
Preparation for work on the synchronisation and lag prediction filters that jano has underway - firstly by adding a property to indicate the mode of the clock being used. Pre 2018.1 will be mode 0.
Automatic selection in the launcher is disabled for now, since
it needs more testing before release, but the basic UI for selection
is straightforward enough to throw in.
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.
Prevent FDM-derived properties being sent at full speed (120Hz) which
overloads telnet connections. Instead track dirty properties and
send them at the protocol’s update rate (which is presumably what
the user expects)
the current timestamp used in mp protocol and in AImultiplayer is not a good one:
it can pause, or even change speed if we change warp value.
we want it to be used for network protocol lag and jitter estimation, and
a time flowing linearly on both side is needed, here's a first introduction
of this timestamp relates to real elapsed time.
here it's initialised to the system clock, then follow the monotonic clock.
in future improvement, it will allow time synchronisation betwen mp players,
to have a very good close formation flight experience.
The "Airbus" callouts ("2500", "hundred above", "retard") are not issued
by the original mk-viii unit, but adding support helps with better
simulation for Airbus a/c. The new callouts are disabled by default, and
are enabled by a specific setting of the GPWS "category-4" configuration
value (see Wiki).
- /sim/multiplay/transmit-filter-property-base can now filter based on property index; or have the previous mode of transmitting only generics by setting to 1.
- Move emesary MP bridge property base index to 12000 - to allow filtering of all except these (to reduce packet size).
- Modify global_mouseInput in init() and in shutdown(), because *these*
are the places where FGMouseInput is enabled or disabled.
- reinit() does shutdown() followed by init().
Note: the commented-out block starting with "FIXME: memory leak" that is
removed here was just an outdated comment, because SGBindingList
is an std::vector<SGBinding_ptr>, where SGBinding_ptr is a smart
pointer type (SGSharedPtr<SGBinding>). In other words, there was
no leak in this place---at least, not recently.
Create the FGMouseInputPrivate instance in FGMouseInput::init() instead
of in FGMouseInput's constructor. This will allow straightforward
implementation of reinit() via shutdown() and init().
Also get rid of the 'initialized' bool, since bool(d) is now equivalent
(d being the std::unique_ptr<FGMouseInputPrivate> data member of
FGMouseInput).
Using std::vector<mouse_mode> instead of std::unique_ptr<mouse_mode[]>
would have been possible of course, but a bit more awkward as
vector<>::size() returns an std::size_t but all the "adjacent" code is
based on the 'int' type.
Octal escape sequences can be as short as 2 bytes (\0, ..., \7),
therefore they allow one to generate shorter files than hex escapes, for
the same resource contents. The line lengths won't be as even, but this
is purely cosmetic, virtually no one will ever read the resource data
string literals, so this is quite a negligible drawback compared to the
advantage of using less space in the Git repository every time resource
files are committed.
These files were originally included for special trim routines. But these routines are no longer maintained in JSBSim and have already been partially removed from FlightGear.
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)
The previous priority was PRIORITY_NORMAL, which happens to be higher
than PRIORITY_DEFAULT. Even though the add-on resource provider should
be quite fast at rejecting resource paths that don't start with
'[addon=', I currently can't see any reason that justifies to give it a
higher priority than other paths added to the simgear::ResourceManager
with addBasePath(..., PRIORITY_DEFAULT).
This is another place where the add-on code uses regexps, and so far I
had forgotten to add the fallback code for compilers that don't support
<regex> as per the C++11 standard.
This method takes a string such as "this/is/a/relative/path" and returns
"[addon=ADDON_ID]this/is/a/relative/path", substituting the add-on
identifier for ADDON_ID.
This way, add-on authors don't even have to know the special syntax
'[addon=ADDON_ID]relative/path' used for add-on-specific resource paths,
and don't need to hardcode their add-on identifier inside each such path
either.
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.
A resource can be specified with the syntax:
[addon=ADDON_ID]relative/path
Such a resource corresponds to the file $addon_base_path/relative/path
for the specific add-on whose identifier is ADDON_ID.
If the particular add-on isn't registered, looking up such a resource
throws sg_exception.
Replace the previously-written manual calls to "new SomeClass(...)" with
their equivalent using
flightgear::addons::shared_ptr_traits<>::makeStrongRef(). This way, when
SomeClassRef is changed from SGSharedPtr<SomeClass> to
std::shared_ptr<SomeClass>, these calls will magically use
std::make_shared<SomeClass>(...) instead of the "new SomeClass(...)"
call.
Change the arrestor wire handling as follows;
- expose property to indicate when arrestor wire has been snagged: /fdm/jsbsim/systems/hook/arrestor-wire-engaged-hook
- add property to allow the model to request that the wire is released: /fdm/jsbsim/systems/hook/tailhook-release-cmd. This permits an overspeed approach to catch the wire and then drop it.
Jean Pellotier, 2018-01-02 : we don't want interpolation for integer values, they are mostly used
for non linearly changing values (e.g. transponder etc ...)
ref: https://sourceforge.net/p/flightgear/codetickets/1885/
(everything described here lives in the namespace flightgear::addons)
New classes: Author, Maintainer, and Contact. Author and Maintainer
derive from Contact. For each contact, the following can be defined in
addon-metadata.xml: name, email, and url. See [1] for details about the
syntax and usage policy. Nasal bindings have been updated accordingly,
there are three new ghosts: addons.Contact, addons.Author and
addons.Maintainer.
The enum class UrlType has two new members: author and maintainer. The
Addon::getUrls() method has a new signature:
std::multimap<UrlType, QualifiedUrl> getUrls() const;
because non-empty 'url' fields for authors and maintainers contribute to
the result, and there can be an arbitrary number of authors and an
arbitrary number of maintainers defined for a given add-on---therefore,
std::map can't be used anymore.
Finally, QualifiedUrl has a new field (detail) which stores the author
name (resp. maintainer name) when the QualifiedUrl type is
UrlType::author (resp. UrlType::maintainer). Currently, this 'detail'
field is not used for other URL types, but this could be changed if
desired.
[1] https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
flightgear::addons::shared_ptr_traits allows one to easily switch for
instance from an SGSharedPtr<T> to an std::shared_ptr<T> for "all" uses
of a particular T, and automatically have std::make_shared<T>(...) used
instead of SGSharedPtr<T>(new T(...)) when creating a shared instance of
T. This is interesting because std::make_shared<T>() allocates all
needed memory as one block, whereas std::shared_ptr<T>(new T(args...))
would perform at least two allocations (one for the object T and one for
the control block of the shared pointer).
This is done via static methods (one for each kind of smart pointer):
shared_ptr_traits<SGSharedPtr<T>>::makeStrongRef()
shared_ptr_traits<std::shared_ptr<T>>::makeStrongRef()
that forward their arguments in the same way as std::make_shared<T>().
Normally, <regex> should be available and working in any compliant C++11
implementation, however at least g++ 4.8[1] lies about its C++11
compliance: its <regex> is utterly unusable, see [2] and [3] for
details.
This requires SimGear commit ab1e2d49abdf5b1aca9035a51d9d73d687f0eba7,
for the HAVE_WORKING_STD_REGEX preprocessor symbol.
[1] Which appears to be (precisely 4.8.5) the version shipped in
CentOS 7, and used on FlightGear's current Jenkins installation.
[2] https://stackoverflow.com/a/12665408/4756009
[3] https://sourceforge.net/p/flightgear/mailman/message/36170781/
Changes to test_AddonManagement.cxx:
- in testAddonVersionSuffix(), fgtest::initTestGlobals() was called
with the wrong test name (not used anyway, but might be in the
future);
- in testAddon():
* rename variable 'm' to 'addon' ('m' used to stand for the old
class name AddonMetadata);
* call fgtest::initTestGlobals() and fgtest::shutdownTestGlobals()
(not technically needed, but cleaner).
- The Emesary MP bridge can use any string property; however it seems sensible to separate the properties out into a distinct block.
- There is a now a type property for each bridge. This is to allow the bridge to identify its type based on what it can transfer based on function. This will allow rapid filtering of unrequired notifications within the bridge (NYI)
QualifiedUrl is essentially a pair containing an enum value
(addons::UrlType::homePage, addons::UrlType::download, etc.) and an
std::string for the URL per se, with adequate getters and setters.
Addon::getUrls() is for people who wish to process all non-empty URLs
occurring as part of the add-on metadata in batch.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36159711/
- Parsing of the addon-metadata.xml file is now handled by a new static
method of Addon:
static Addon fromAddonDir(const SGPath& addonPath);
This method will be reusable to gather all add-on metadata from a set
of add-on directories (just call the method once per add-on). This
change also simplifies AddonManager::registerAddonMetadata().
- New supported fields:
authors
maintainers
license/{designation,file,url}
url/{home-page,download,support,code-repository}
tags
See
https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
for documentation on these fields.
Mailing-list discussion:
around https://sourceforge.net/p/flightgear/mailman/message/36155660/
refactoring of FGFDM parser
replace old helpers with lib functions from <cstring>
remove typecast that kills 'const'
add some comments and clarify variable names
These methods were removed by mistake in commit 0dbb0dff9, which broke
code that relies on them (e.g., FMSDelegate.currentWaypointChanged() in
$FG_ROOT/Nasal/route_manager.nas).
Also remove 'waypointPrototype' from NasalPositioned.cxx, since it is
not used anymore.
Note: the methods can't be easily re-enabled by means of
'waypointPrototype', because for FPLeg ghosts, 'waypointPrototype'
was emulated as a parent class before this commit, and thus when
querying an FPLeg ghost for its 'airport', 'runway' or 'navaid'
member, the corresponding data member returned by
waypointCommonGetMember() would be found by legGhostGetMember()
*before* parent classes are searched. This commit prevents this
from happening by returning 'airport', 'runway' and 'navaid' as
member functions *directly* in legGhostGetMember(), before
waypointCommonGetMember() is queried as a fallback.
Thanks to Eric van den Berg for the bug report.
Move the format-version node inside /meta. It's not compatible of
course, but since the stuff this is breaking is only 2 or 3 days old,
let's go for it for nicer code and file format.
Sorry if you had already written an addon-metadata.xml file of your
own. In this case, just replace:
<format-version type="int">1</format-version>
with:
<meta>
<file-type type="string">FlightGear add-on metadata</file-type>
<format-version type="int">1</format-version>
</meta>
This should fix the following compilation error and other similar ones:
converting to ‘std::tuple<flightgear::AddonVersionSuffixPrereleaseType,
int, bool, int>’ from initializer list would use explicit constructor
‘constexpr std::tuple< <template-parameter-1-1> >::tuple(_UElements&&
...)
According to <https://stackoverflow.com/a/32084829/4756009>, the change
wouldn't be needed in C++14 (and it built fine with my g++) but we use
C++11.
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/
The Garmin protocol implementation really is an NMEA protocol with a few
extra messages. Instead of duplicating the code, introduce the NMEA protocol
as a base class, which is reused for the Garmin class. The input/output
has not changed at all (and it maintains the FG-specific quirks, like our
NMEA class using LF-only linefeeds, while the Garmin protocol uses
CR-LF linefeeds.
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.
