There isn’t really a way to ensure that every client’s train is at the same position without replicating. But I would suggest to pass the state change via reliable RPC, and replicate the train’s position and velocity from the server to the clients.
An example for why I say there’s no way to ensure that the trains positions are the same at all times only with the state change:
- You use a reliable RPC from the server to all clients saying the train lever is down, the train may start. P1 & P2 receive this call at exactly the same time, and the trains are perfectly in sync.
- P2’s brother starts up a netflix stream, and P1 puts the lever up. Since P2’s network now has more traffic, the call for lever up takes 0.4ms longer to get to P2 than P1.
- As a result of this, the train on P2’s client travels at max speed for 0.4ms longer, and therefore travels further.
This is a pretty unnoticeable difference, but imagine there’s a lightning strike, or the router randomly crashes, or there’s an outage even just for a couple seconds. Now P2’s train has travelled much further, with no way to sync them back together.
As a rule I would say to always use a reliable RPC for important state changes, and replication for everything else. I say this because it’s important to remember that replication will always send the most recent up to date information, and won’t stack messages to ensure that everything gets to all the clients. In the case of reliable RPC’s, the server will send a message for an event, and continue to send that message until they receive a confirmation that the client has received it. After which the server will send any messages that stacked up behind that message.
What you don’t want to happen (and what could happen if you simply replicated the state of the lever):
P1 flips the lever to open → immediately flips it back to closed → after 0.1 seconds flips it back open.
There is a non zero chance that P2 misses the replication of the lever being closed, if they got the message that the lever was open and then experienced some packet loss for a tenth of a second. This would result in the train on P2’s client reaching max speed 0.1 seconds faster than P1. Resulting in desynch