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>
On this code path, AppKit uses exit, rather than letting main run as
normal. We handle most things via C++ destructors, which do run, but
Qt is happier if we clean it up explicitly.
According to the discussion around [1], using the system CppUnit library
is rarely useful but likely to cause problems (due to possible
incompatibilities between versions); that is, unless people doing so
really know what they are doing. For this reason, this commit changes
the CMake config logic as follows: the system CppUnit library is now
only used when explicitly asked for with -DSYSTEM_CPPUNIT=ON on the
CMake command line.
[1] https://sourceforge.net/p/flightgear/mailman/message/36636483/
- Fixed the scripts end time computation
- Fixed nested tests in switches
- Simplifications to the computation of the aerodynamics angles alpha & beta
- Account for the contact transition in the gear compression speed
- Fixed docs in FGTank
- simgear::strutils::readNonNegativeInt<unsigned int>() is better than
std::stoul() at detecting and reporting erroneous input (for one, it
checks that the given string *represents* an integer that fits in the
specified type, as opposed to just "starts with digits").
- The format version is now an unsigned int (just because it's largely
enough and simgear::strutils::readNonNegativeInt<unsigned long, 10>()
isn't instantiated for now).
- The format version is now printed to the log (it was already for
apt.dat files, but not for nav.dat files).
Instead of doing an illegal memory access (to fields[0]), properly
report the problem when the line that is supposed to contain the format
version of a nav.dat file is empty.
