Why is manual movement so choppy when using Add Actor Local Offset?

Hi, we’re making a networked game that depends a LOT on the position of moving objects being in the same place for all clients. We’ve got some replication going for these objects, but it is terribly choppy. They update very few times a second. The frequency set in the blueprint’s defaults is set to 100, replication is on and “replicate movement” is checked. If we increase the priority, it gets a little smoother, but not at all as smooth as we’d like it. Interestingly once we turn these objects physical, the replication is perfect, but when we move them manually using Add Actor Local Offset it’s not. This is true even if we run it on Local Host as well, so it’s nothing to do with bandwidth.

Do we need to do something special in order for the manual movement to update more frequently?

Even though you have requested a high update rate for the object, you will still not be guaranteed that it will be updated as that actual rate. A lot of things may affect this, especially differing framerates between the server/client and bandwidth usage.

I suggest using velocities to move the objects when possible, so that when the remote client doesn’t get an update for a brief period of time they can simulate the change in position to predict what will happen next. Then once they receive a new location and velocity from the server they will pop to that location and take up the simulation from there. You may have to implement the tick logic to update position based on velocity but that should be straightforward. When you set the objects to move using physics this is basically what is going on in the background, which is why you are seeing smoother behavior there.

Hehe, our Lead Programmer suggested that very solution earlier today! Now we know it’s an acceptable way to handle it! Thanks a lot! OuO

Zak or Sky, I set new server location based on the client actor location - so how would I use velocity exactly using BP so that it does smoothly translate to the next position if there was an interruption in the updating?

I would like to know this too, as I am having very choppy movement on my Pawn which moves via FloatingPawnMovement component in my Blueprint project.

Choppy over networking, I assume?

See the above comments. Basically there are frames during which the client is updating without data from the server, so replication/network updates aren’t filling in the time in between. The clients will need to do some position smoothing (and optionally prediction) to fill in and ease the gaps.

Character does this automatically, by using lagged smoothing on the mesh position so it slightly trails the capsule location used for collision. It also forward-predicts the capsule location based on velocity.

Okay, so is it safe to say that I will have to add my own smoothing algorithm to anything that is NOT using a CharacterMovement component, or else it will only ever show the position updates as they come in over the network, resulting in blippy/blinky/choppy “movement”? Are there any other movement methods/components that come with the Engine which provide that smoothing built in?

Objects that simulate physics use forward prediction between updates, based on velocity.

Thanks, Zak. I changed to using non-character Pawn (It’s a squat, cylindrical hover tank) with a simulated-physics static mesh instead of FloatingMovementComponent, and I’m getting much better results now :slight_smile:

I haven’t tried it over network, just PIE multiplayer, but it’s already a vast improvement. Much much smoother.

So I understand this means that you set a velocity on the pawn so it keeps moving amoothly until the server can update the client, at which point the pawn pops to where the server tells it to be. This will look mostly smooth if the connection and latency is good. It will jolt a lot more on a bad connection but that happens in the best of games, and to make it any better you would have to figure out some kind of forward prediction algorithm.

But it sounds pretty simple to me - if the pawn is already moving on the client in the last known direction and speed the server told it to have, it will be smoother than only setting the actor location on each network update.

I think you might have to do this with turning speed too, to smooth out rotations. i dont know. i am new to networking.

Oops, but now when I run the game on a mobile device with a low framerate (12-20fps), the tank never gets moving very fast, so I switched back to using other movement components and turned off Physics simulation for that pawn. But now the movement is choppy in general although it can at least reach its top speed instead of scooting along at a snail’s pace. I might just have to not release it for devices that run at a slow framerate…

So now I am trying moving the tank using ProjectileMovement component, it’s very choppy on network (pretending network since I’m just running two instances of the game on the same computer, one as a listen server and the other as a client). It gets even worse if I turn off Replicate Movement on the pawn itself, even with Replicate Component on the ProjectileMovement component.

I’m trying to decide whether to use Physics again and just say “too bad, you’re out of luck” to the low-performance devices, or continue trying to find a solution that’s consistent regardless of the clients’ framerates (which physics is not, and I can’t use substepping to make it so, on mobile Android).