I was watching the Roblox video which says authority allows the client to predict physics ahead of the server, and is corrected for once the client catches up with the server.
The problem I have with this model is how I set up client/server interactions such that the server is still the authority when it comes to custom physics or other systems where you’d want the client to predict ahead of the server.
basically all server authority is just fancy way to push input action
You just fire input action from client and then listen to the input actions on the client that fired it and on the server
You can look on FPX for example where its much more minimal and straightforward implementation unlike player module
it does NOT use events (because defered events killed such possibility of implementation bruh)
Instead you have to be checking the value of input action using InputAction:GetState() inside BindToSimulation
had to figure this out all by myself but that basically it
“The problem I have with this model is how I set up client/server interactions such that the server is still the authority when it comes to custom physics or other systems where you’d want the client to predict ahead of the server”
The way I understand it, you can establish some module that stores general game rules and simulation, then require and bind it to the simulation on both clients and server. The client will be able to predict physics, but whenever server data comes through, the clientside resimulates using the update function you bound to the simulation. Since both scripts require from the same module, the game should play the same. I found very useful info in this website: Server authority model | Documentation - Roblox Creator Hub
I don’t know if this prediction also applies for Attributes and stuff, but so far it seems to hold in my project. This allows you to also predict other kinds of things, like custom state machines, counters and whatever else through some StringValue’s attributes.
It’s important to realize though that there are limitations when using Server Authority. Like, what I’ve found is that some functions cannot be called in this simulation environment sort of place, such as Destroy. So if you want to destroy something, you got to mark it for destruction in simulation time and then destroy it in PostSimulation. Another thing I learned is that (atleast for now) you cannot set a string attribute to be over 50 chars. So, no JSON for now.
In the end the connections sort of look like this:
RunService:BindToSimulation(updateGamestate, 60hz)
RunService.RenderStepped:Connect(renderGamestate)
RunService.PostSimulation:Connect(postsimGamestate)
You could also treat the gamestate like an object, and ‘update’, ‘render’ and ‘postsim’ as it’s methods. Overall, it’s pretty cool.