What would be the best way to change walk speed on the character over network?
I’ve tried all kinds of approaches. But when simulating net lag of 60 ms or higher (or lower in fact too) I always get a correctional jitter on the client.
I’ve tried changing walk speed on client first -> then on server: Jitter appears (mostly when stopping the sprint and returning to normal walk speed)
I’ve also tried changing speed on server first, then on client: Jitter also appears just as bad
I’ve also tried only settings walk speed on server, but this creates jitter all over the place because the client is constantly fighting the server
Same goes for only changing speed on client.
What is the correct way of doing this?
As far as I see it there will always be a correctional jitter due to the net lag delay. Whenever client and server have different walk speeds which happens between transition server always tries to correct client. So I would have to disable the correction or something during transitions?
I’d like someone to correct me on this. Basically, the character movement component has its own set of network rules that make customizing it a pain.
Keep in mind that in a multi-client environment, even if you set speed on yourself and server, other clients will percieve you jittery ,because they have not recieved an update that you should be moving faster but the server is telling them you are farther ahead in space. In some cases, updating on server will automatically update on every client, but that’s usually for simple RPC components and variables. The easy solution is to go through server then through multicast to every client. That way the change fires first on server then on everyone else. But this results in a delay from the user until the server grants permission (2x lag, essentially). So you can mix this with fire on self, and fire through server through multicast. What this is doing is setting a personal change, then asking the server if this change is legal (run on server, will only update on the server, but multicast will update on server and EVERYONE else); if you have 1000 ms ping, you should be completely able to sprint freely for 1 (10?) seconds until the server deems the change legal or illegal. If legal, there will be no change to you. If illegal, you will rubberband back to the position you were in when making the request to server.
Depending on the movement, you might never get it fully working across the network. The end-all solution is to un-replicate the movement component and broadcast your player transforms yourself, but that can be really tedious for unexperienced users.
I have experienced rubberbanding with some multicast stuff and ended up building a function node to basically nerf the multicast behavior. So multicast inherently broadcasts to everyone including the server and the self. So the function just excludes the self, so there is no waiting on server. You wire up your event to fire on self, then you send up your server to multicast events, then run through this function before firing the network event. I’ll post the screenshot later. Got to get to my work computer!
Sorry I lost my way back here and forgot about it. Anyways…
In this case I am updating my player position, my HMD position, and motion controller positions on the server then on the multicast. This WOULD force the user to rubberband because the server is telling them where to go, but the macro is stopping the event line. So no rubberband on self, and it multicasts to all clients.
This is how I update my movement across the network without relying on replicating the movement component. My players can rope-swing around the environment and the movement component thinks the movement is illegal. So fixed with own update method here.
IN YOUR CASE, you would set up the sprint firing event to run through a sequence node, first sequence output will sprint on self, the second sequence output will run to server, run to multicast, run through the ExcludeSelf macro, then fire the sprint.
Now I would really like if somebody else could tell me why this would be wrong or if they have a better solution to multicasting to everyone except yourself.
P.S. I do not care about cheating. Most of my projects are purely exploration or proof-of-concepts.