Force a variable to replicate even if it hasn't changed?

I have a situation where the players can interact with a switch, which results in the switch playing an animation of it turning from “off” to “on.” Obviously, when there is some lag, the client doesn’t see the switch animate immediately, which feels a bit unresponsive. I could play some audio/effect to hide the lag, but I was thinking of doing some simple client-side prediction.

The client could check if the conditions are met, if so, notify the server and set the switch to “on,” which triggers the animation play. Assuming the server agrees, no problems. If the server disagrees for some reason, then we have a broken state, where the server sees the switch as “off” while the client sees it as “on.”

This state is held in a replicated variable that I’m allowing the client to change as part of its client-side prediction. The issue with this however is that since the server hasn’t changed it, it does not get replicated so the client doesn’t know that the server hasn’t also changed it.

To solve this, I’m thinking that when the server rejects the interaction, it needs to notify the client in some way, so the client can undo its predicated state (i.e. put the state back to “off”). I know I could send an RPC to the client. However then I wondered if there was a way to force the server to replicate that variable, even though it hasn’t changed on the server, which would auto correct the client.

Anyone know if this is possible in Blueprint? Perhaps you have a better idea on what I should do, or should I forget the client-side prediction and just roll with the audio/effects smoke and mirror trick and make the client wait out the server round trip?

For a TPP/FPP character setups I fake responsiveness by having the character play a montage for the interaction. This generally covers network delays.

on input pressed → rpc server → play montage
Server: executes change, actor replicates

Typically states use Rep_Notify. e.g. Bool (on/off)


Optionally you could have the server send a response rpc back if the switch states differ.

On input → rpc server [state you are attempting on/off)
server rpc → get current state → compare state → validate action → if good, execute. Else rpc client current state.