This follows from http://thread.gmane.org/gmane.games.flightgear.devel/78650 and
resolves the sign bug https://sourceforge.net/p/flightgear/codetickets/1778/ .
Combined with a matching change to the flightgear repository, this changes the
HUD formats from the current set of 3 (note that the text in brackets is not
shown in the HUD preferences PUI dialog, but is show here for reference):
0) Decimal degrees (37.618890N -122.375000W)
1) Degrees, minutes (37*37.133N -122*22.500W)
2) Degrees, minutes, seconds (37*37 08.0 N -122*22 30.0 W)
to (here the text in brackets is shown in the PUI dialog):
0) DDD format (37.618890N 122.375000W)
1) DMM format (37*37.133'N 122*22.500'W)
2) DMS format (37*37'08.0"N 122*22'30.0"W)
3) Signed DDD format (37.618890 -122.375000)
4) Signed DMM format (37*37.133' -122*22.500')
5) Signed DMS format (37*37'08.0" -122*22'30.0")
6) Zero padded DDD (51.477500N 000.461389W)
7) Zero padded DMM (51*28.650'N 000*27.683'W)
8) Zero padded DMS (51*28'39.0"N 000*27'41.0"W)
9) Trinity House Navigation (51* 28'.650N 000* 27'.683W)
From https://github.com/Juanvvc/c172p-detailed/ release/2016.1
commit 3f33b88bb015a8ee685ab3178932d16d6e072410
A big Thank-You to the c172p-detailed team for their ongoing work.
Add valid ranges for day based on selected month and year taking into account leap years.
With this change it should no longer be possible to enter an invalid date.
Added combobox for the month (using name).
Added sliders for all date components (year is between 1971 and 2037 to avoid invalid values in time_t).
Relabelled easing, added a bit of layout context with some ruling.
- make t/T action press and hold, with some acceleration factor and
clamping to a maximum rate. (Avoids confusing latching-mode of
previous system(
- show the local time of day while adjusting.
Values are based on some experimentation, feedback welcome on the
mailing list.
- left/right top of stick buttons cycles views, instead of aileron
trim, since I judge this to be a more commonly used feature. But
maybe this will cause a conversation.
- adjust sensitivity of the hat view-direction control, was unusably
fast for me.
Chris:
This patch switches the rudder listening to the right property. The one being used now seems to be obsolete for a long time. Additionally it needs to change polarity to operate properly.
- Since joystick.PropertyScaleAxis instances have a 'prop' attribute
indicating the property name, it seems logical to have
joystick.PropertyScaleAxis.parse() set this attribute based on the
property name in its argument ('p').
- This commit also tries to improve readability by using a 'bindingNode'
variable instead of repeatedly calling 'p.getNode("binding", 1)'.
- Commit 5bcf58c7d6 forgot to set the
'inverted' attribute when there was no 'factor' node in the argument's
'binding' node. Fix this.
- Also copy the argument's 'factor' value to the 'factor' instance
attribute for consistency, since joystick.PropertyScaleAxis instances
have such an attribute initialized in the constructor.
As far as I can tell, the dead-band setting belongs to <axis> nodes, not
to <binding> nodes using property-scale. This can be seen in
do_property_scale()'s definition (flightgear/src/Main/fg_commands.cxx)
as well as in fgdata/Docs/README.Joystick.html.
joystick.PropertyScaleAxis creates <dead-band> nodes as children of
<binding> nodes in generated joystick binding files under
$FG_HOME/Input/Joysticks which, AFAICT, are completely useless and thus
confusing. The <dead-band> nodes should be created at a different level
to be effective (cf. FGJoystickInput::postinit() in
flightgear/src/Input/FGJoystickInput.cxx).
This commit removes the 'deadband' attribute from
joystick.PropertyScaleAxis, since it has nothing to do there IMHO.
As can be seen in do_property_scale()'s definition in
flightgear/src/Main/fg_commands.cxx, property-scale rightfully uses a
default factor of 1.0. However, if a joystick axis' property-scale
binding has no 'factor' node defined, and one opens the joystick
configuration dialog, then PropertyScaleAxis.parse() creates an empty
'factor' node that implicitely gets a value of 0. This method is called
by joystick.readConfig() when the joystick-config dialog is opened. This
has the effect of rendering the corresponding joystick axis inoperant.
How to reproduce the bug:
- take a joystick such as the SAITEK CYBORG 3D USB, with its default
binding file from
fgdata/Input/Joysticks/Saitek/Cyborg-Gold-3d-USB.xml (this file uses
property-scale for the aileron, with no explicitely defined factor);
- start FlightGear; move the joystick left or right while looking at
the plane wings -> the ailerons move, it works fine;
- now, open the joystick-config dialog and do the same test -> the
ailerons don't move anymore and the 'Aileron' value at the bottom of
the dialog stays at 0 (0.0 or -0.0...). Just opening the dialog to
test the joystick has "corrupted" its setup! This is very confusing
for users.
This fix corrects the problem by avoiding the apparently unneeded
creation of an empty 'factor' node when there is none inside the
<binding>. An alternative would be to create a 'factor' node with value
1.0. In any case, if someone later expands the joystick-config dialog to
allow modification of property-scale's factor, he should make sure to
use a default value of 1.0!
