Gamepad Support in Mudlet

Vessil

I'm looking for any feedback I can get on what sort of functionality people want as I'm implementing gamepad support on the development branch of Mudlet(meaning it'll make its way to an actual release hopefully not too far in the future).

From my similar thread on the Mudlet forums(http://forums.mudlet.org/viewtopic.php?f=7&t=16661&sid=354acd5a0dcc7bfa364946e7fdcd6b12):
"Since Qt 5.8 has implemented a powerful and easy to implement way to read gamepad events, I'm going to implement gamepad support in Mudlet in a release that will hopefully be pretty soon after 3.0's first stable release. I've got an event based element to it working already(so you can just attach functions to buttonPress, buttonRelease, and axisMove events in your own scripts). I'm hoping to also slightly expand the existing "Keys" system so that it can detect button presses and the like, and I'm looking for feedback from people that would potentially use it.

Any suggestions about functionality you'd need to make a gamepad based system? Ideas about possible uses that people might get out of this system so I have some use cases to think about? Questions?"

One particular place I'm thinking it will find use is as an alternative to automation in making bashing more bearable(and less repetitive-strain-injury inducing).

Ahmet

Mkay so.

Absolute base functionality:

Support for default controller buttons/triggers
Support for up to eight directions for thumbsticks, plus stick buttons (if using this, shouldn't trigger until at least 30-50% of max to prevent up-right from triggering up and then up-right, etc)

Things that would be nice:

Functions for retrieving precise thumbstick positions
Customisable thresholds for thumbstick keys
Support for analog triggers
Functions for controller vibration (where supported)
Option to use certain buttons (bumpers, maybe? or customisable) as modifiers instead of keys.
Function calls for whether or not a button is currently pressed (may already exist? not sure)

Will add other things if I can remember any of the other issues I came across in setting mine up.

Ahmet

Maybe a built-in method for  setting up gamepad profiles, but this is easy enough to script already that it shouldn't be an issue.

Vessil

Thanks for the feedback, @Ahmet

What I have working so far is events being fired for sysGamepadButtonPress, sysGamepadButtonRelease, sysGamepadConnected, sysGamepadDisconnected, and sysGamepadAxisMove. All of them provide you with deviceId, the ones involving a button or axis return a number indicating which one. buttonPress also indicates either 1 for binary switches like buttons, or a number between 0-1 to indicate how pressed they are. axisMove also indicates how far in one direction or the other on a range from -1 to 1.

I'm going to add in functions that let you poll specific gamepads to see their button/axis states etc, but I'll probably get into that later, after we figure out how to integrate it all into the Keys system.

All of the functionality you mentioned besides vibration(which isn't doable until Qt adds that functionality to QGamepad, which seems fairly likely to me since QGamepad is still in an almost developer's preview sort of state) is doable at the moment with enough of your own Lua code, so now I'm going to be focusing on what the Keys UI integration part looks like. That's what I'm mostly concerned with.

There is some limit after certain functionality will be available through the events but not the Keys system, I just have to find where that limit is. It might be difficult(and definitely will require adding additional UI elements) to allow you to set up a binding for when a key is released. The L2 and R2 buttons have ranges of motion, do I treat it as a press after a specific hard-coded threshold, or do I make the system and UI more complicated and allow the user to decide where that threshold is? How do I determine when it counts as having been released, and should that be dynamic(and complicate things more) or static? Should I only make simple axis-detection that fires when you pass a specific threshold in a certain cardinal direction, or should I clutter up the Keys screen with ways to customize that as well?

Lots of stuff I don't know the best answer for yet, which is why I appreciate feedback.

(Also, as a note to anyone considering how they'd use this, the Windows implementation of QGamepad in Qt only works for XInput devices as far as I can tell(which means modern console style controllers like the ones for the Xbox 360, Xbox One, PlayStation 3 and PlayStation 4), so Windows users might be limited from using certain types of alternative devices. I'd need someone with a different type of controller(like a flight sim joystick or racing peripherals) to test to make sure. Hopefully that's a limitation that goes away as QGamepad gets fleshed out further.

Vadimuses

The simpler it is to get your stuff working, and the less confusing the UI, the better, so lean towards that.

Fgure out sane defaults that work "out of the box". I think being able to plug a controller in, selecting an axis to record, pushing up in the controller stick and putting "n" into the "Send" field should allow me to setup 8-way navigation and then I can just walk around at a reasonable pace.

Adding more options is not a good thing unless those options actually solve problems is the idea.