TouchTrigger.touchHash fails assertion when using joysticks

[Markil3]

I was running some tests with using joysticks on Android (wireless Xbox 360 gamepads, specifically, courtesy of Microsoft's official receiver and an OTG cable on Android 9, specifically), and connecting the gamepad or pressing some buttons (usually up on the dpad) appear to cause the assertion in com.jme3.input.controls.TouchTrigger.touchHash to fail. I suspect that this is due to the gamepad sending signals that touchHash didn't anticipate.

[stephengold]

Thank you for reporting this issue.

In order to properly address the issue, more information might be needed, such as the value of keyCode that triggered the assertion. Too bad the assertion doesn't provide that detail...

[Markil3]

All we probably need is to add some code to log which value threw the error (likely by adding a try-catch within the touchTrigger, and then throwing an additional RunTimeException that provides extra details in the log). It isn't particularly easy for me, since I can either connect my phone to my computer via USB, or connect the gamepads, but not both. This will probably involve me either logging to a file on the phone or trying to debug it over WiFi. I'll try to do it if I have time next week, but I figured I would at least open an issue with what information I already have.

[stephengold]

I'll add the logging code.

[stephengold]

I added details to the assert in the "master" branch: 30f79f2

Status: awaiting more information from @Markil3 .

[Markil3]

Right! back from holidays, and I've finally figured out what is going on.
Based on my testing, it appears that it is just the dpad up button that causes this error, sending a hash of 1006. This also occurs when I first connect the gamepad, but I have noticed that several buttons seem to get triggered when connecting to an android in general, so I think that it is a little beyond JME's control.

[Markil3]

I added some more logging code to find the hashes, and I found that, although the game sees the DPAD buttons as a pair of axes, the DPAD will generate touch hashes just like buttons (the other axes don't do this). However, the DPAD buttons will always send a touch hash of 0, with the exception of DPAD_UP, which sends 1006 (0x3ee).
Here is a record of all the hashes I get:

Legend: Hash - 0xHexadecimalHash(0xHexadecimalOutputHash)
KEYCODE_BUTTON_THUMBL: 106 - 0x6a(0xfedcbb02)
KEYCODE_BUTTON_THUMBR: 107 - 0x6b(0xfedcbb03)
KEYCODE_BUTTON_A: 23 - 0x17(0xfedcbaaf)
KEYCODE_BUTTON_B: 97 - 0x61(0xfedcbaf9)
KEYCODE_BUTTON_X: 99 - 0x63(0xfedcbafb)
KEYCODE_BUTTON_Y: 100 - 0x64(0xfedcbafc)
KEYCODE_BUTTON_L1: 102 - 0x66(0xfedcbafe)
KEYCODE_BUTTON_R1: 103 - 0x67(0xfedcbaff)
KEYCODE_BUTTON_START: 108 - 0x6c(0xfedcbb04)
KEYCODE_BUTTON_SELECT: 109 - 0x6d(0xfedcbb05)
KEYCODE_BUTTON_MODE: 110 - 0x6e(0xfedcbb06)

AXIS_X (up): 
AXIS_X (down): 
AXIS_Y (up): 
AXIS_Y (down): 
AXIS_Z (up): 
AXIS_Z (down): 
AXIS_RX (up): 
AXIS_RX (down): 
AXIS_RY (up): 
AXIS_RY (down): 
AXIS_RZ (up): 
AXIS_RZ (down): 
AXIS_HAT_X (up): 0 - 0x0(0xfedcba98)
AXIS_HAT_X (down): 0 - 0x0(0xfedcba98)
AXIS_HAT_Y (up): 1006 - 0x3ee(0xfedcbe86)
AXIS_HAT_Y (down): 0 - 0x0(0xfedcba98)

I'm wondering if this may just be a quirk with my specific gamepad (my Xbox 360 remotes have never worked very well with Android 9), but I don't ever remember seeing another app crash like this one does.

[stephengold]

Even with the details added, the assert isn't very helpful. It gives no hint why the original coder assumed keyCode would never be 1006. If some other routine relies on that assumption, I don't know why or where that would be.

Perhaps we should just delete the assert.

[Markil3]

If I remember correctly, @pspeed42 did a lot of work on the Joystick API. Perhaps he might know something?
Honestly, though, even if the gamepad is being wonky, I don't see the point of it either.

[pspeed42]

I used the assert keyword for the first time in my own code only recently. You can bet that if there is an assert in JME code that I was not the one that did it. (At least for a while.)

I'd have to look at the git blame to see where this line came from but my suspicion is that it predates the move to gradle and predates the move to git. If not, someone might gain some insight... but if so, that's fair game for removal as far as I'm concerned. (I personally don't have time at the moment to drill through git blame on this.)

[stephengold]

I tracked down the commit that added the assert: 8955f71

It was more than 9 years ago, by @kimxilxyong --- no longer active in the JMonkeyEngine project, but still on Github.

[stephengold]

I'm going to remove the assert.

[stephengold]

Resolved in "master" branch at 3305928.