FGData Merge Request #45: Remove inappropriate 'deadband' attribute from joystick.PropertyScaleAxis (merged)

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).</dead-band></binding></dead-band>

This commit removes the 'deadband' attribute from joystick.PropertyScaleAxis, since it has nothing to do there IMHO.

Note that non-null dead bands are still mishandled by FlightGear on Linux because of a Linux-specific plib bug (https://sourceforge.net/p/plib/bugs/47/), but this is unrelated to this commit. Applying this commit will remove confusion as to where the <dead-band> node should be created in order to be effective.</dead-band>

Thanks. :-)

[Florent Rougon]

Note: before the commit, bindings created by the joystick-config dialog under $FG_HOME/Input/Joysticks look like:

<axis>
<desc type="string">Aileron</desc>
<binding>
property-scale
<property type="string">/controls/flight/aileron</property>
<dead-band type="double">0</dead-band>
<factor type="double">1</factor>
<offset type="double">0</offset>
</binding>
</axis>

If you merge the commit, you'll get this instead:

<axis>
<desc type="string">Aileron</desc>
<binding>
property-scale
<property type="string">/controls/flight/aileron</property>
<factor type="double">1</factor>
<offset type="double">0</offset>
</binding>
</axis>

which is more conformant to property-scale's "signature" AFAICT.

As a next possible improvement to the joystick.PropertyScaleAxis code, I wonder if using 1.0 (resp. 0.0) as default value for 'factor' (resp. 'offset') instead of 1 (resp. 0) would be more efficient, since the node type is double. What do you think?

Regards

[James Turner]

Can you resubmit this now the first patch is merged?

Also, I woudl suggest we import the 'JS' code from PLIB into FlightGear, as I did previously with the 'net' module. This would allow is to fix bugs directly since there will never be a PLIB release. Would you agree with this idea?

[Florent Rougon]

Hmmm, I refreshed the web pages, I did 'git pull' on 'next', but I don't see the merge yet. But I think it should not be necessary unless the SF merge code is a bit dumb, since your merge normally didn't change my commit 5bcf58c7d65b613428280a967211aed14ad7633f from https://sourceforge.net/p/flightgear/fgdata/merge-requests/44/ . I'll gladly resubmit the request if you're sure it is necessary, though.

Concerning importing plib's joystick code into FG, it seems to be the only way to fix such bugs short of switching to a different library (but since people don't seem to be ready to have Qt as a mandatory dependency...), so yes, I think such a change would be positive. (as you probably noticed, the bug I linked to has a patch ready to apply that I have been using since at least 6 months without any problem)

Thanks

[James Turner]

Okay this all seems very reasonable to me! I'll try to merge the commit above, hopefully SF works it out. And in the next few days I'll import PLIB-JS module into flightgear/src/Input/, on a branch so as not to affect the iminent release. Then you can patch and test and we can merge once the release is done.

[Florent Rougon]

Sounds great, thank you! The two merges seem to have gone fine, too, I have them now in my 'next'. :-)