GetButton(), GetButtonDown(), GetButtonUp()
These work just like the regular unity input button checks, but they can be used reliably for analogue inputs and not just buttons.
Again, these work just like you would expect. And work for inputs with analogue or binary values.
Performs several GetAxis() checks returns the results in a vector. Just a time saver for you really
eg; movementInput = Sinput.GetVector("Horizontal", Vertical");
For every input check, you can optionally pass an InputDeviceSlot value, by default this will be the 'any' slot which checks ALL devices, which is ideal for single player games. But if you want only input from the 2nd gamepad, or just the mouse, you use those slots to filter your input checks.
This means you can simply code multiplayer input by having a single player script, where the instances just have a different slot to check.
To get a player's slot, I recommend using:
This works just like GetButtonDown() but instead of returning true or false, it will return the InputDeviceSlot of whichever player pressed the control. You can use this for things like a 'Press A to join!' screen. If there are no presses this frame, it will just return the 'any' slot.
Sinput has some functions to make quality menu navigation easier to code:
This will return true when a button press is detected, and if the button remains held long enough, the function will begin to return true again periodically. This means you can make menus where players can hold a button down to keep scrolling, but it won't start scrolling too soon. You can set how long the wait before repeating and how long between each repeat is with Sinput.buttonRepeatWait and Sinput.buttonRepeat.
This will reset all controls (or just controls for a specified slot) for a time, and all Sinput checks will return false or 0 until that time has passed. You can pass 0 if you want to reset inputs for just the one frame like the usual Input.ResetInputs().
You should call this whenever you detect a menu item selection to prevent the player from unintentionally making more selections too quickly.
Any Sinput control can be set to have toggle behaviour, which makes it so GetButtonChecks will behave as though the control is pressed even after it is actually released, and until it is actually pressed again. You can use this to make it so controls that would otherwise need to be held down (eg crouch) can be instead toggled on/off by the player.
I would strongly advise you expose this option to your players for any control that might need holding for a prolonged period; some players can't press a lot of buttons at once, some may find it strenuous to hold a button, and most keyboards don't support too many buttons being held at once anyway so if you're porting gamepad code it's worth keeping in mind.
If you have a control that may or may not be a toogle and you need the actual value, you can use these functions;
GetButtonRaw(), GetButtonDownRaw(), GetButtonUpRaw()
GetButtonDownRepeating() doesn't have a 'Raw()' equivalent because it ignores a control's toggle setting (I can't think of a good reason it should, if you think adding this behaviour is worthwhile let me know!).
You can set the overall mouse sensitivity that Sinput uses simply by assigning it;
Sinput.mouseSensitivty = 0.5f; //makes mouse movement half as sensitive
In addition to that, you can use the following functions to set the scaling of smart controls (note: this won't work for regular controls).
It's worth keeping in mind, all axis values returned by a smart control will be multiplied buy it's scale, including mouse movement which may have already been scaled by the mouseSensitivity setting. (I'm not sure if this is ideal and I'm still thinking on a better system)
Smart controls (again, not regular controls) can have their axis values inverted simply using;
Framerate Independent Inputs
This one is a little tricky to explain, but put simply, some GetAxis() values you might want to multiply by Time.deltaTime (eg buttons, gamepad sticks), but others you do not (mouse movement).
As an example, think of aiming in first person, an analogue stick in one place will return a constant value every frame - you can multiply this value by deltaTime and turn the first-person view by that much. It doesn't matter if the framerate (and therefore, the deltaTime) fluctuate.
But if you try to do this with mouse input it could be significantly less precise depending on how consistent the framerate is - you will want to turn the first-person view by exactly how much the mouse was moved without the framerate being an influence.
For the most-part, you should be able to get by without worrying, just use Sinput to check a control and you won't have to worry if the value is coming from a mouse, a gamepad, or a keyboard - but for important things like first-person aiming or moving an in-game mouse pointer you will notice (or at least, you'll feel) that the controls are a little off if you don't have separate behaviour in your scripts for these different types of controls.
For that purpose;
If this function returns false for a control, that means any GetAxis() value for that control should NOT be multiplied by Time.deltaTime this frame. (I specify this frame, because the player might switch to gamepad control the next, or maybe they are using both. Sinput is hecka versatile you know ;p)