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.
- PTT will now use whatever channel is selected; non zero simply means PTT active.
- The volume as set in the comm[]/radio will now be used as a factor on the FGComm volume
PTT now uses an int channel number (0 means not pressed, 1 = comm radio 1 (index [0]),etc...)
/comm-radio-selected is the default comm channel to use. This should usually be the same as will be set by PTT into /controls/radios/comm-ptt
However PTT will switch the FG comm inbound and outbound frequency to whichever radio was PTT'd.
New properties also set in multi-player to indicate the transmission frequency and normalised power (currently just set to 1.0)
13001(int) : sim/multiplay/comm-transmit-frequency-hz
13002(short-norm) : sim/multiplay/comm-transmit-power-norm
