Is it possible to add a simple gyro-to-right joystick mapping?

[banner88]

This was generally mentioned in another issue, but I just wanted to flag it separately as a feature request - I noticed MissionControl is able to emulate game pads. Would it be possible to make a basic universal gyro-aiming tool by tying the gyro inputs to the right analog stick? I think it would be hugely valuable for a bunch of games which would benefit from gyro controls but where the devs chose not to include it, and in basically all these games the right stick controls the camera.

Could you can use HidSixAxisSensorState angular_velocity.x/.y readings (which will be 0 unless there is movement), as values for an emulated R stick x/y direction? Or else to add to the current R analog stick input - I don't know if you can have input from both a controller and an emulated controller at the same time? You could also have sensitivity modifiers that adjust how much acceleration translates to how much R stick movement. That way you don't have to calculate anything in terms of gyro positioning.

[ndeadly]

Gyro controls are not currently supported (mostly because I haven't figured out how to properly calibrate them yet). When I've got that working I don't see why this isn't something i could look into.

I'm not quite sure what you mean by input from a controller and emulated controller at the same time? I guess you mean reading the physical controller data vs what the system reads via calls to the hid service. If so it's not possible to do that simultaneously because one depends on the other. You could still read the data from hid (and you'd probably want to because it's going to be calibrated, maybe corrected with sensor fusion etc) but it's going to be one frame behind.

I will take a look into this once motion controls are supported to see if it's feasible.

[chklovski]

Hi, just wondering if you had a chance to look into this since motion controls are now implemented for a range of controllers?

[ndeadly]

@chklovski no, not yet. I'm currently focused on BLE support. I will look at this eventually, but it's not of particularly high priority for me right now.

[dkgitdev]

I'd like to vote for this one as well. I'd like to offer my help as well with this one.

@ndeadly can you tell if you have any work started on this one, so I can continue from there?

As for the calibration part, we can use it as in Splatoon -- press button to reset. Or is this "calibration issue" much deeper?

[dkgitdev]

Also, I'd like to formalize request a bit

• mode selection (Always On / While Button pressed / Activate by button), select from a list;
• button selection (Reset for always on case and activation button when not), "press a key" or "select from list";
• sensitivity modifiers per coordinate, slider, %;
• dead zone per coordinate, slider, %;

This settings preferably being adjusted per game

[ndeadly]

@dkgitdev nope, haven't touched it due to having too many other things to work on. This one is all yours.

As for the calibration part, we can use it as in Splatoon -- press button to reset. Or is this "calibration issue" much deeper?

This is how you would have to account for gyro drift, yeah. Though a solution would need to be found so that having this reset button doesn't interfere with regular gameplay. The issue regarding calibration that I was referring to was assuming that we would be passing through the raw uncalibrated motion data for the system to calbrate itself, meaning we would have to perform a duplicate calibration step in order to use the data for this purpose. In the end it turned out much simpler to do this calibration myself anyway, so this isn't really an issue anymore.

Also, I'd like to formalize request a bit

• mode selection (Always On / While Button pressed / Activate by button), select from a list;
• button selection (Reset for always on case and activation button when not), "press a key" or "select from list";
• sensitivity modifiers per coordinate, slider, %;
• dead zone per coordinate, slider, %;

This settings preferably being adjusted per game

This level of control sounds great, but be aware there is currently no real framework in place for allowing this to be configured easily. Manually editing .ini files sucks. Ideally I would like to have all these kind of settings configured by both an applet and a Tesla overlay, and a means to communicate everything back to the sysmodule over IPC. I have done a bit of work on these things already, but haven't formally decided on exact implementation details yet due to the ever-changing structure of the core of the project. This stuff is lower priority for me than hardware support.

@Banz99 has submitted a PR some time ago introducing the concept of controller profiles. This is a step in the right direction and will most likely be merged in some form in the future after some of the details are more concrete.

If you're looking to contribute I'd encourage you to get in touch via discord, where I can easily answer your questions and discuss implementation details. I have a server set up for this, or you can contact me directly at ndeadly#5317