Input exposure

[EasternGamer]

Inputs, such as mouse clicks, keys on your keyboard, joysticks, all have inputs that should be readable. A generalized onInput() with the ability to get an input ID. You could map these inputs to certain actions, like pitching down when pitching down on your joystick. Also, mouse clicks. An instance would be my AR HUD. You could right-click to bring up a custom AR context menu to select actions, or left click to select something.

[NQ-Deckard]

This is a slightly sensitive subject, as the collection of inputs opens the door for players to do a variety of nefarious things. As such these won't likely be implemented soon as there would need to be a considerable number of edge case guards put in place to prevent keystroke logging, UI and interface tracking. Such as for example, tracking when a player would navigate through RDMS settings and such, or attempting to mask the UI and guiding a play into context menu entries involuntarily.

As such this is a non-trivial addition, but I will make a note of it.

[ZarTaen]

I think one way to possibly combat some of the edge cases would be to explicitly have a context switch between Lua inputs and non Lua inputs, which could be as simple as pressing tab, or a dedicated mouse button, something that specifically cant be touched by Lua then.

While it would make some aspects of the game less fluid potentially (flying while inside a menu), it could end up being the choice for a player of "I allow this, at the cost of needing to context switch, or I dont want to, but inputs wont work", which could end up being an RDMS right of that resource from a player character.

Edit: Forgot, Lua would only be able to access specific input data when in the right context.

[samdeane]

Just exposing joystick analogue and button inputs would be a massive boon, without so many (any?) of the bad-actor concerns.

Another way to do it would be to allow scripts to declare additional key mapping targets, which the user can then explicitly map to a key (or not). Eg instead of having to use Option 1, Option 2 etc, a script could declare that it has a "Fly To Orbit" mapping. This could then show up in the Control UI (probably grouped by script in some way that you'd have to tunnel into, to avoid making the UI a horrible mess), and the user could choose to assign a key or button to it. The script would then receive it just like any other action.

[EasternGamer]

Just exposing joystick analogue and button inputs would be a massive boon, without so many (any?) of the bad-actor concerns.

Another way to do it would be to allow scripts to declare additional key mapping targets, which the user can then explicitly map to a key (or not). Eg instead of having to use Option 1, Option 2 etc, a script could declare that it has a "Fly To Orbit" mapping. This could then show up in the Control UI (probably grouped by script in some way that you'd have to tunnel into, to avoid making the UI a horrible mess), and the user could choose to assign a key or button to it. The script would then receive it just like any other action.

I doubt Joysticks have a single "input" range which they are mapped to. However, you can map a joystick to mouse and keyboard inputs if the joystick software allows it. I'm trying it now and it's somewhat working.

[samdeane]

You should be able to enumerate all connected XInput devices, and enumerate all the inputs for each one, getting the analogue or switch value.

[matpratta]

Just exposing joystick analogue and button inputs would be a massive boon, without so many (any?) of the bad-actor concerns. Another way to do it would be to allow scripts to declare additional key mapping targets, which the user can then explicitly map to a key (or not). Eg instead of having to use Option 1, Option 2 etc, a script could declare that it has a "Fly To Orbit" mapping. This could then show up in the Control UI (probably grouped by script in some way that you'd have to tunnel into, to avoid making the UI a horrible mess), and the user could choose to assign a key or button to it. The script would then receive it just like any other action.

I doubt Joysticks have a single "input" range which they are mapped to. However, you can map a joystick to mouse and keyboard inputs if the joystick software allows it. I'm trying it now and it's somewhat working.

I have some really similar stuff done regarding this on my plugin for Space Engineers, which in a nutshell passes down multi-joystick input down to in-game scripts. Most of it is written in C# with a wrapper for DirectInput, but it should be pretty easy to map into C++ for those who are familiar.

The way things work on DirectInput is that you have a few "common" analog axis (X, Y, Z, RX, RY, RZ), some "common" digital ones for POV hats plus some arrays containing both analog axis (sliders) and some digitals (buttons). If those could be passed down to the running script then it would open doors to some BIG things regarding how one controls their ship using Lua, even if only the "common" set was supported at first. The only things that I know aren't nicely handled are "centered" axis, where the zero point (no analog input) is at 0.5 instead of 0, which is what happens on most joysticks as their top and left positions are at 0 instead of -1, but that should be easy to correct for :)

If that ever gets some work done, I volunteer myself to test it out on my HOTAS, pretty much all the work I did on the plugin was using it and should be really easy to replicate on DU. As a bonus, we don't have to worry about the user getting scammed or mislead, since joystick input would always only be used for ship controls and never for UI...