InputForge — Server-Authoritative Input System

Resources Community Resources
,
1

Been messing with Roblox’s new server-authority stuff and ended up building this Figured I’d share it

InputForge is a small server-authoritative input system built on BindToSimulation + InputActions The server owns the sim so clients only send input and no speed or fly hacks work.

Drop a module in a Context folder and it auto-loads. The InputAction + InputBinding get built straight from the module so you just declare Action Type Keys then write your logic in :Process().

Setup drop the whole model into ReplicatedStorage and you’re done

Add your own

  1. Duplicate _Template into a Context folder
  2. Set Action Type Keys
  3. Write your logic in :Process()
    image
    image671×264 10.7 KB

Included as examples

Requirements — enable these in Workspace:

image
image388×161 3.97 KB

Get it

Still improving it so any feedback or ideas are welcome below

3 Likes
2

roblox :

image
image787×140 12.4 KB

image
image476×301 18 KB

:waving_hand:

3

There is no need to use this
It’s just wrapping the exact same purposes that it’s intended to do.

4

If this means what I think it means, then I think you’re using server authority wrong.

What you’re doing with that method is no different to not having server authority and just using remote events. Your systems which rely on input will be extremely laggy and unpleasant to use.

The entire point of Server Authority is that you simulate the same actions on both client and server, where the server has authority over the client, so the server can reset things if there’s a mismatch on the client.
You simulate actions on both so they feel responsive but stay true.

Let’s take a sprinting system.
I press a button, and my client adjusts the WalkSpeed of my character. The server also reads the input and adjusts the WalkSpeed there as well.
If I were hacking and adjusted the clients walkspeed above the set sprint speed, the server would snap the player back to the intended speed.

Of course I’m unable to verify any of this, but from your own wording, you aren’t using this correctly.

And that’s just a part of server authority. Your system does nothing relating to this.

5

Respectfully your take is based on a wrong assumption You said yourself you couldn’t verify it so let me clear it up

The system runs the same code on both sides through BindToSimulation:

  • client processes the LocalPlayer (prediction)
  • server processes every player (authority)
    image
    image1001×621 34.5 KB

That’s your sprint example word for word. Client reads the input and sets WalkSpeed, server reads the same input and sets it too. If a client pushes WalkSpeed past the sprint value the server never agrees so it stays authoritative and snaps it back. That is server authorit done properly not a remote-event setup

Also worth pointing out my system builds the InputActions and InputBindings for each player automatically from the module You just declare Action Type Keys and it generates and parents them into the player’s InputContext You don’t touch a single InputAction by hand

On the “no speed or fly hacks” line that wasn’t me claiming I invented anti-cheat I was describing what server authority gives you Never said otherwise

Thank you for taking the time to respond I appreciate it

1 Like
6

instead of passing in the InputContext and then finding the InputAction using FindFirstChild, why not pass in the InputAction itself, or the state of the InputAction?

1 Like
7

Good point tbh rn each module runs its own FindFirstChild every step which isn’t great. Passing the action or its state straight in would cut that and keep modules cleaner I went with the context to leave room for abilities that need more than one action but for single action ones your way is better Might have the core resolve the action once and pass it in Appreciate the suggestion

1 Like