This is necessary on macOS where DBus is typically installed using
Homebrew, and hence we need additional linker flags to find the
library. Using the PkgConfig::DBUS imported target handles all this
transparently, but then we need to define an imported target for
Windows to work.
Due to e43fe82094 models in AI scenarios were
being searched down the AI/Aircraft and Aircraft paths, where in fact
they are by default a full path from FGDATA.
This fixes the problem by setting DATA_ONLY as the search order.
Other search orders can be set in the scenario file by setting
the search-order tag to "DATA_ONLY", "PREFER_AI", "PREFER_DATA"
Based on the dew point temperature supplied by FG, JSBSim updates the atmosphere density and computes all the usual parameters (RH, vapor pressure, saturated vapor pressure, etc.)
The mass fraction of water per unit of air mass is capped according to the record high from ISA 1976 standard atmosphere. As a consequence, at very high altitudes, air is always extremely dry (approx. 30 ppm i.e. 30 parts per million) whatever the conditions at sea level.
Fix for https://sourceforge.net/p/flightgear/codetickets/2125/
Previously, selecting a non-pushback parking position from the l
auncher that did not have a ground network resulted in the
aircraft being placed in the center of the airport.
This resolves the problem by creating a default segment simply
moving forward 2m.
According to Pfeffer's report[1] and many other messages on the
Internet, joyGetDevCaps() can return the (so far) undocumented value
165, which some say is JOYERR_PARMS. Since this is a valid return code
for joyGetPosEx() (not joyGetDevCaps()!), handle a few return codes from
that function too, and don't throw an exception when joyGetDevCaps()'s
return value is not one of the documented ones (we simply can't trust
its documentation).
[1] https://sourceforge.net/p/flightgear/mailman/message/36657149/
Since asserts can be compiled as no-ops, throw an exception rather than
doing assert(false), in case the code passed to
joyGetDevCaps_errorString() is not one of the expected values.
Every code path that causes a joystick to report notWorking() should now
have an associated error message logged with class 'input' at level
'debug' or higher.
If joyGetNumDevs() > INT_MAX, casting it to an 'int' leads to undefined
behavior. On the other hand, after the 'ident >= 0' test succeeded, it
is perfectly safe to use static_cast<unsigned int>(ident), since 'ident'
is of type 'int'. Then we get to compare two unsigned ints, which is
well defined.
Since PLIBjs uses joyGetDevCaps()[1] on Windows and this function
accepts joystick ids from 0 to 15 (-1 being special), setting
MAX_JOYSTICKS to 16 ensures that FGJoystickInput::init() can scan all
joysticks that joyGetDevCaps() is able to report about.
[1] https://docs.microsoft.com/en-us/previous-versions/dd757105(v%3Dvs.85)
JSBSim was not checking the tag names inside <test> and <condition> statements and this has led to abusive use of tags unsupported by JSBSim such as <and> and <or>. The problem is that JSBSim was not interpreting the <or> statement as the user meant it: JSBSim interpreted it as <test logic="AND"> while the user obviously meant <test logic="OR">. As a result JSBSim silently swallowed the tag and gave results which were not was the user expected without any obvious indication about what was going wrong.
As a result, this commit implements stricter syntax checking and rejects illegal tags within <test> and <condition> statements.
This commit also introduces stricter checking on XML elements which allow either a real value or a property name to be used. JSBSim now rejects the statements where the property name is specified inside a <property> statement. For example, the follwoing statement is rejected:
<clipto>
<min> <property> /fdm/jsbsim/some/property </property> </min>
...
The correct syntax being
<clipto>
<min> /fdm/jsbsim/some/property </min>
- When FGDATA_SRC_DIR isn't explicitly set by the user, set it to
${PROJECT_SOURCE_DIR}/../fgdata if this is a directory.
- When TRANSLATIONS_SRC_DIR isn't explicitly set by the user, look for
translations in ${FGDATA_SRC_DIR}/Translations instead of
${PROJECT_SOURCE_DIR}/../fgdata/Translations (i.e., honor the setting
of FGDATA_SRC_DIR for the sake of translation lookup).
This fixes the problem explained in [1] and [2].
[1] https://sourceforge.net/p/flightgear/mailman/message/36645499/
[2] b2274fbbed/
Base class handles some common instrument features, such as the
serviceable node and electrical supply. The electrical supply node
and minimum voltage to operate can now be set in the configuration
via <power-supply>/path/to/output/volts</> and <minimum-supply-volts>