Created input library

[davidsonbr]

Works like the GLua library, user can check key states via key enumerations.
Same with mouse keys.

[Xandaros]

This definitely needs permission checks and those should probably be disabled by default...

[davidsonbr]

As well as adding permissions that the users changes via console commands, I added both inputPressed and inputReleased hooks. Both are called when either a key / mouse button is pressed / released respectively.

[Xandaros]

Some suggestions after testing this for a short moment with @awilliamson:
For the permission checks, pass the player you are trying to get the keys off as object.
(In sf screen terms: subject is entities.owner(), object is entities.player())
Get rid of the convars and, by default, allow getting the key if subject and object are the same, neutral otherwise.

Edit: Just saw that we actually call subject "principal" and object "target". Might want to change that at some point...

[awilliamson]

Discussing this with @Xandaros at the moment. He's against using ConVars in the permissions. I'm fine with it, to an extent, we'll have to discuss this a lot more as there's more implications from this decision which needs to be thought out.

The 'input sharing' can be circumvented using rpc iirc. If you're creating convars on the client also use "CreateClientConVar" for future reference.

[awilliamson]

@EpicG Is this worth waiting for your permissions rewrite? I know getting client input is a touchy subject. Perhaps we should make an issue discussing ideas for users to control access levels to their client information or control?

[davidsonbr]

I feel like waiting on the permissions system would be a good thing for this.