inputPressed doesn't exist serverside, despite PlayerButtonDown being shared.

[legokidlogan]

Starfall's inputPressed and inputReleased hooks currently only exist on client, even though the equivalent glua hooks PlayerButtonDown and PlayerButtonUp are in the shared realm.

Because of this, any time someone wants to have arbitrary key press/release events (i.e. any keys, not just the limited IN_KEY list) on serverside, they have to network the button presses themselves. Not only is this incredibly tedious, but it bloats network traffic with tons of redundant messages.

[thegrb93]

I'm pretty sure PlayerButtonDown/Up doesn't work serverside in dedicated servers

[thegrb93]

I can probably throw up a server and test, but I remember it originally was shared and was moved to clientside only because it didn't work.

[thegrb93]

Okay, I tried it out and it looks like the gmod devs might've fixed it. I guess the problem now is we need to make sure player's aren't able to see all of everyone's keypresses without permission

[Hazeofdream]

can't e2 already do that with event keyPressed with zero perms? just allow it by default and let clients choose

[thegrb93]

Fairly sure that only works for IN_KEY enum keys

[Hazeofdream]

the IN_KEY's have dedicated functions but it works on any keys

[thegrb93]

the IN_KEY's have dedicated functions but it works on any keys

Can you give an example?

[legokidlogan]

E2 doesn't have a permission system, so you can always get states and update triggers for any player's keys, at any time.

As for the dedicated IN_KEY functions, E2 has :keyUse(), :keyAttack1(), etc for checking current state.

[legokidlogan]

I guess the problem now is we need to make sure player's aren't able to see all of everyone's keypresses without permission

Starfall already has the input permission on client for reading keys, it just needs to be extended to a shared context.

However, it's also used for stuff like input.lockControls() and input.enableCursor(), so it might need to get split into input.read and input.lock or something along those lines.

[thegrb93]

Right, but clients are able to disable the input permission if they wish, whereas that wouldn't be possible with a serverside hook.

[thegrb93]

If we can sync the input permission from client to server, then I think we can add it.

[thegrb93]

Suggest adding a new option registerprivilege("input", "Input", "Allows the user to see what buttons you're pressing.", { client = {replicated = true} })

Then this permission will send a net message to the opposite realm it's created on and apply whatever setting changes it gets. The server realm will contain an EntityTable of players with their replicated settings.

This will allow server settings to be replicated on the client as well which I remember was needed for something else a while ago.

[thegrb93]

For the serverside, will need a new check permission function too that takes a player arg, since different players will have different settings.

[thegrb93]

Maybe a replicated provider would be able to handle checking the replicated setting.

if SERVER then
    registerprivilege("input", "Input", "Allows a user to see what buttons players are pressing", { replicated = {} })
else
    registerprivilege("input", "Input", "Allows the user to see what buttons you're pressing.", { client = {replicated = true} })
end

[thegrb93]

Actually just putting the realm that its replicated on would work. registerprivilege("input", "Input", "Allows the user to see what buttons you're pressing.", { client = {replicated = SERVER} })

[thegrb93]

Then it will be true for server and false for clients and the table index will exist on both.

[thegrb93]

Another problem is that the client provider can't be invoked on the server because there's a 'Friends Only' option that only works clientside.

[thegrb93]

Will need a server version of the client provider.