I would like to suggest two additions to InputAction features that would make IAS significantly more useful for server-authoritative systems:
- A
PredictionCallbackAPI for reacting to predicted input changes. - Technical
InputActionTypes such asVector2int16andVector3int16, specifically designed for efficient server-authority replication through:Fire().
1. Add InputAction:PredictionCallback()
A common server-authority pattern currently looks something like this:
RunService:BindToSimulation(function()
local state = InputAction:GetState()
-- Process input
end)
This works, but it requires calling GetState() every simulation step, even when the input has not changed.
For example, if the player keeps holding the same movement direction:
Move = (0, 0, 1)
Simulation
Simulation
Simulation
Simulation
Simulation
...
The input state may remain identical across many simulation steps, yet the code still needs to retrieve it and determine whether anything changed.
This creates unnecessary polling.
Proposed API
InputAction:PredictionCallback(function(state: any): RBXScriptConnection
-- Process predicted state
end)
The callback would execute when prediction produces a new input state.
For example:
MoveAction:PredictionCallback(function(state)
-- Process newly predicted input
end)
Instead of:
local PreviousState
RunService:BindToSimulation(function()
local State = MoveAction:GetState()
if State ~= PreviousState then
PreviousState = State
-- Process changed input
end
end)
The InputAction system already knows when the predicted state changes, so developers should not need to repeatedly poll the state and recreate that detection logic themselves.
Why not use .Pressed?
.Pressed serves a different purpose.
It represents an actual input press, while PredictionCallback() would represent predicted input state changes.
Additionally, .Pressed is a signal, whereas this proposal is specifically a callback API receiving the predicted state directly.
This distinction matters for server-authoritative systems, where the relevant event is not necessarily:
“The player physically pressed something.”
but rather:
“The client prediction produced this input state.”
2. Add Technical InputActionTypes
I would also like to suggest additional technical InputActionTypes:
Vector2int16
Vector3int16
These should not be treated as ordinary player-facing input types.
Their purpose would specifically be:
- efficient representation of server-authority input,
- compact replication,
- avoiding unnecessary conversion/packing work,
- providing native representations for quantized gameplay input.
Most importantly, these technical types would be intended to be fired manually through :Fire().
For example:
MoveAction:Fire(packedMovement)
Rather than being directly bound to keyboard, gamepad, or other physical input.
This makes them useful as the second layer in a server-authoritative input architecture:
Physical Player Input
↓
Translate / Quantize
↓
Technical InputAction
↓
:Fire(packedData)
↓
Server Authority
The InputAction therefore represents the gameplay/network representation of the input, rather than the physical device that produced it.
Why This Matters
Server-authoritative systems often do not need the raw representation of player input.
The server may only need a translated and quantized gameplay state. There is little reason to replicate keyboard state, gamepad state, camera information, and individual device inputs when the client can first convert them into the representation the server actually consumes.
I have written a more detailed explanation of this architecture here:
Why You Should Proxy Out Your Server Authority InputActions
The proposed technical types would make this pattern easier to implement efficiently, while PredictionCallback() would remove the need to repeatedly poll GetState() just to detect changes.
Summary
I would like to see two additions to InputActions:
PredictionCallback
InputAction:PredictionCallback(function(state: any): RBXScriptConnection
-- ...
end)
A callback that runs when prediction produces a new state, allowing developers to react directly instead of polling GetState() every simulation step.
Technical InputActionTypes
Vector2int16
Vector3int16
Technical, replication-oriented types intended to be manually fired through:
InputAction:Fire(...)
These would make it easier to build efficient server-authoritative input pipelines while keeping physical player input separate from the data actually consumed by the server.
Let InputActions tell us when predicted input changes, and provide efficient primitives for the input representation that actually needs to reach server authority.