Add better airway support, fix various issues with VIA, and add
parsing / generation of ICAO route strings. Also fix the
serialisation of flight-plans with airway enroute segments, so these
can be restored correctly.
Upcoming flight-planning changes want to use the perf computation code
in route-path, so move it to a public class, and implement some of the
missing functionality, especially correct GS computation for altitude.
Since the subsystem manager tracks group state, it now binds/inits
automatically. This means groups which create subsystems during init
no longer need to manually bind() them.
- I think I've fixed a long standing problem with clicks traveling through windows and bringing the dialog window underneath to the foreground.
- Added /sim/gui/dialogs/current-dialog that contains the name of the currently active (in front) dialog window.
- Changed dialog-open to bring a dialog to the front if it is already open.
Aircraft can now set a /sim/model/fallback-model-index property that is transmitted over the MP network.
Receiving clients use this as an index into AI/Aircraft/fallback_models.xml to determine a model to use if the model path (/sim/model/path) cannot be found under Aircraft or AI/Aircraft. This allows aircraft developers to identify a suitable fallback model to be used for those who do not have their aircraft installed.
As this code has significant bit-rot and requires a lot of work to compile and
run again, it is currently deactivated.
The test also writes to the files "/Users/jmt/Desktop/airways.kml" and
"/Users/jmt/Desktop/procedures.kml" and would need to be modified to write to a
temporary directory and the file contents reread and checked by the test.
The extractBits(), signExtend(), and writeBits() functions of the anonymous
namespace in Input/FGHIDEventInput.cxx have been shifted out of the namespace
and are now exposed via the header. This is needed as
<Input/FGHIDEventInput.cxx> cannot be imported within the CppUnit
infrastructure, as it is already built into the run_test_suite binary.
These include Scenery/{maptest.cxx, test.cxx} and Time/{test_event.c, ttest.c,
win32test.c}. These files, essentially untouched since added in 1999, are not
useful for conversion for the test suite.
The HistoryPopup was caching its contents rather early, and we failed
to tell the model when its underlying data updated. Connect that
through so the history model refreshes also.
https://sourceforge.net/p/flightgear/codetickets/2036/
- Trim reports, FGOutputFG and sockets messages now respond to the debug level
- Channels : fix for incorrect time steps caused by execrate
- Improved configuration error detection in FGSwitch with respect to late bound
- Fixed the ordre in which the components of the p-factor moment are reported in CSV output files.
- Now all the sea level properties from the standard atmosphere are updated along with the other atmosphere properties.
- The properties propulsion/start_cmd and propulsion/cutoff_cmd are now read/write (they were read only before).
Mickael Danilov reported that one cannot send brake commands to /fdm/jsbsim/fcs/{right,left}-brake-cmd-norm since FG overwrites them with /autopilot/autobrake/* properties.
A new property /fdm/jsbsim/systems/override-fg-brake-properties has been added which is set ot false by default to keep the legacy behavior. When set to true, the properties /fdm/jsbsim/fcs/{right,left}-brake-cmd-norm can be modified by the user and will ignore the setting from FlightGear.
Use The Qt 5.6 Shortcut item, but via a conditional file so
we don’t touch the base Qt requirement. (This means no shortcuts
when using Qt 5.4 or 5.5, oh well)
- Air density now takes humidity into account.
- The protocol of input sockets is no longer case sensitive
- Late bounded properties are now cached for better performance.
Allow setting of various secondary location args without
knocking out the main ones. The user arg values still override, but
this allows selecting a runway (for example) and manually setting
altitude / heading / offset if desired.
Categorise arguments to ensure user-specified ones take precedence
over values set by the launcher.
When any positional arg is set, exclude all positional ones from being
set at all, to prevent strange interactions.
This simplifies the launcher's rendering since the widget-based
code is gone, various things get hooked up as a result. Styling
fixes everywhere as well.
Menubar on Linux/Windows needs to be re-added.
* Removed the IAS dependency to the Pitot tube angle (real Pitot tube are less sensitive to AoA than was simulated)
* Removed the class FGUDPOutputSocket which was redundant with FGOutputSocket
* Added a new type of functions "template" which are intended to prevent duplication of functions. For now, they are available to compute output values and script notifications.
* Aerodynamics forces can now be specified in stability axes.
* Density altitude and pressure altitude are computed according to ISA standard atmosphere 1976.
New properties:
* Flight path angle (gamma) in degrees
- fdm/jsbsim/flight-path/gamma-deg
* Aerodynamics forces in stability axes
- fdm/jsbsim/forces/fsx-aero-lbs
- fdm/jsbsim/forces/fsy-aero-lbs
- fdm/jsbsim/forces/fsz-aero-lbs
* Aerodynamics moments in stability axes
- moments/roll-stab-aero-lbsft
- moments/pitch-stab-aero-lbsft
- moments/yaw-stab-aero-lbsft
* Pause JSBSim
- fdm/jsbsim/simulation/pause
* Fixed multiple bugs.
Display a warning when the user tries to set arguments in additional
settings which the launcher will also set / conflict with. Blacklist
is still evolving, and we don’t actually prevent the user from running,
since maybe they are doing something special
At a basic level, the implementation supports two levels of LoD:
FAR from /sim/rendering/static-lod/ai-range-bare to /sim/rendering/static-lod/ai-range-detailed.
NEAR from /sim/rendering/static-lod/ai-range-detailed to 0.
(First of many digressions: If /sim/rendering/static-lod/ai-range-mode-pixel=true then instead of measuring LOD distance in meters, the size of the object in pixels is used, so the ranges are different)
The models that are loaded for FAR and NEAR depend on a combination of the availability of a model in /AI/AIrcraft/ and FG_AIRCRAFT directories.
If /sim/rendering/static-lod/ai-range-detailed=false then an AI aircraft will be used in preference for both NEAR and FAR.
If /sim/rendering/static-lod/ai-range-detailed=true then an AI aircraft will be used for FAR, and an FG_AIRCRAFT for NEAR.
Obviously if only an AI or a FG_AIRCRAFT model are available, that will be used for the entire NEAR+FAR range.
Change delay to 15 seconds; and alert that there is a delay.
The 15 second delay should be sufficient to allow the compressor to finish processing; and in anycase this is running in a thread and therefore shouldn't freeze the whole sim for the delay period.
/sim/multiplay/use-detailed-models can be used to set whether
we will prefer models from Aircraft/ (true) or from AI/ (false).
Default (set in defaults.xml in fgdata) is true.
Fixes a perf issue when opening and closing dialogs which uses
bindings, reported by Michael Danilov - huge thanks for his help
in tracking this down.
This bug was caused by the SGBinding ‘don’t delete properties’ change,
since the PUI code was copying nodes to work-around that problem. With
SGBinding fixed, the copying caused huge numbers of nodes under
/sim/bindings/gui
When releasing the RMB over a PUI dialog, we no longer get stuck in
drag mode due to the buttons map getting out of state. This is slightly
ugly work-around, better fix to follow hopefully (needs better OSG
integration)
Make the policy of using models in FGData/AI more flexible, with the
option to prefer normal data sources. Keep the existing behaviour for
everything except multiplayer aircraft, where we now prefer the data
model (presumably, an installed aircraft) over the AI one.
bool[42] and bool[72] used to have two bits (i.e. transmitted twice). This was not harmful just wasteful.
Mapped the first of the duplicated bits of each of these to new bools at the end of the list. These two properties will not be compatible with pre 2018.2.
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.