Yeah, generally what is said across the spectrum is that movement is replicated out of the box, but I find that to be far from the truth. Maybe in a sense of local multiplayer idk.
As far as any kind of movement replication over the network from various points in the real world, I find it absolutely needs replicated events across the client and network simultaneously. The default add movement nodes don’t satisfy any of that and on dedicated servers you’ll likely find the character won’t move at all even on the client with it set up like that.
Given that the movement is updating very quickly, it’s a good place to setup these rpc events on the input axis values and you’ll get a nice smooth prediction over the network. The data transfer is actually very small, so it’s pretty effective, but if you run to much and or make them reliable, your connections can become saturated and kick the client.
So basically, what you have posted above, if you’d like to try the method I’m suggesting, you can setup just like you have posted in your screenshot above with a couple changes.
For the client, create a RunonOwningClient event and put your movement nodes behind it. Feed the axis float values from those nodes into that RunonOwningClient event. Call that event from your input and feed the axis values into that event.
On the server, create a RunonServer event and also a multicast event. Do the same thing on the multicast event in the exact same manner as the client event. Feed the axis values from the multicast into the server event. Also from the same line of logic from the original input source, call the server event as well and feed the axis values into that RunonServer event as well.
Now you’ll have a nearly perfect synchronized line of code over client and server. It’s probably good to set up duplicate add movement setups for the client and server so you can exclude certain things in the future from either if necessary. You will however need to call them from the same input. This also applies to left/right movement.
Given that you are updating and sending these very quickly, you can also run some branches, enums or whatever to switch on different speeds depending on stuff going on elsewhere in your code on the tail end of this and it’ll do a great job of picking up changes in variables without getting out of sync by trying to update movement speeds on other areas of logic.
I’ve heard others suggest other methods that I do not find to work at all, so idk what they are talking about, but what I suggested, I can attest to 100% does in fact work great with dozens of players over the network all over the world without any disconnections at all.
After setting up like this you’ll want to fine tune your network update frequency to the lowest possible amount to maintain smooth gameplay while also utilizing the least amount of bandwidth as well.
Docs say 20 hz or something low, but I see a lot of jitters in that in a fast-paced environment. I run much higher without issue, but that is on dedicated servers with nearly unlimited bandwidth. Locally run servers on client machines will have a dramatically less amount of upload bandwidth so that should be a consideration…