I am aware there are similar posts, but none quite meet my expectations for a fast-paced game. The exact problem that needs to be solved is not only replicated sprinting (easy enough), but rather client-predicted sprinting in blueprints. Granted this will be moved to C++ for launch for improved performance, but it’s still critical I learn how this is done in blueprint so I can more accurately understand the concept.
I’ve attempted to simply set the move speed on the client and then the server and use serverside reconciliation to smooth it out though it still rubber bands.
If anyone has some ideas, I would be happy to hear them! Thanks!
Hey @3dRaven!
Thanks for getting back to me! So, I figured out the same thing but also with Ignore Client Movement Error Checks and Correction which is I guess effective for long term high speeds (e.g. sprinting), are there any downsides to using this that you’re aware of? As though it runs only on the client and there aren’t any snapbacks after sprinting with it, even on high ping.
ANYTHING that a server simply accepts from a client rather than either doing the work itself, or at least verifying, is susceptible to client-side hacking.
Anything.
Your rubberbanding (prior to setting the “Make It Easy to Cheat” I mean “Server Accept Client Authoritative Position” flag) is likely caused by client-side prediction of your sprint speed, but you haven’t told the server that you want to sprint, just the client. The client guesses how you’ll move, but when the next server update comes down, your client snaps back to the position you’re server thinks you’re in.
So.
Option 1 (the correct option): Tell the server when a client wants to sprint. This is probably just matter of setting the sprint flag to be replicated, but I don’t know unreal networking, just general networking… I worked on MMOs for about 7 years (EQN T.T, and ESO). If you have a stamina resource, you want to check it on both the client and server, to prevent more rubberbanding.
Option 2: Set the “client authoritative position” flag, accepting the potential consequences.
Thanks for the comprehensive guide @mstorer3772!
I guess I haven’t explained my issue in enough detail, I’ll provide you with a few quick videos to highlight the issue when I simply set the variable on both sides. The issue only comes up when I spam sprint and I’d rather not have a cooldown on sprinting.
EDIT: Pardon the choppy framerate, it’s only visible with the recording. As you can see though, the upper right frame is experiencing the issue visually, but this only applies to the client executing the action as you can tell via the lower left frame.
I got more information! This actually occurs with the standard template if you set up a basic system with network emulation on. This doesn’t appear to be due to conflicting information.
From what I can tell. When the client says it first, it updates it immediately (as it should with client prediction). But the now outdated information is still being sent from the server, also normal. The issue only arises due to the outdated information (outdated being used lightly due to the server being the authority) forcing the client back to the state it was just in, since the way the server sees it, it’s moving too fast and therefor resets it. Then the information reaches the server, and it says “OH WAIT! You were right! Let me reset you back to where you were.”
Long story short, I need a node that runs clientside that disables correction for a brief moment until the server retrieves the data, or a way to ensure that the server acknowledges a potential sprint immediately before it gains the aforementioned data.
If someone knows how to go about this, I’d appreciate it if someone could tell me!
