Anyway, I’m trying to carry a player character with another player character. I was hoping it would be as simple as attaching the player to the parent player and disabling movement on the attached player, but I’m having a lot of networking issues. On the client I am getting huge amounts of jitter on the parent player, though the locally owned/attached player moves smoothly as expected. I have tried turning off pretty much everything from disabling movement, turning off physics and collision on everything, disabling tick on the movement component, removing the movement component, and unpossessing the actor, but it still seems to have an unacceptable amount of jitter.
Placing a non-possessed character blueprint in the level seems to work as expected when attached. The player can move around smoothly, and everything seems fine.
My kind of last ditch effort is going to be hiding the player controlled character and spawning a new non-possessed player in the same state, but I’d like to avoid that if possible, because it seems like I should be able to just turn off all the things that are causing the jittering.
Does anybody have any idea what might be causing this?
Honestly I think the “turn off the player and make a fake one to carry” method is actually the correct one for this scenario. Because the network replication simply can’t handle that kind of attachment, you’d have to actually go in and change how the movement components handled movement updates and replication of those for it to work properly. The main issue is that the replication code has no notion of attachment afaik, so there’s no way of saying “compute my position in relation to my parent, then replicate that”.
It MIGHT be generally useful to allow replication of heirarchies though, so maybe the effort would be worth it (I’m thinking players in vehicles for instance), but I suspect it’d be a fair bit of effort.
This was the primary use case that I was thinking of despite it being different than mine. Another typical one I can see would be dealing with injured people in a shooter. Being able to drag/carry characters doesn’t seem like that uncommon a use case to me. It seems like being able to easily turn off networked movement on characters should be a more supported feature. Even removing the character movement components doesn’t seem to turn off replication/prediction completely, and I’m totally dumbfounded as to how I’d be able to go about that.
That makes sense and was what I suspected, but the thing that I find totally odd is that the jitter isn’t on the attached player, it’s on the attach parent, which makes absolutely no sense to me. The attached player moves exactly as I’d expect it to.
Just wanted to add. The jitter isn’t actually on the attach parent. It’s on the attached client, but I didn’t realize it because the camera was stuck to that actor so the other actor looked jittery.
The best way to do this is not ‘attach’ them at all, and in fact just use the ‘replicated’ location and update the attached actors position on tick. (ReplicatedMovement.Location).
The reason it jitters is because the packets that come from the server aren’t necessarily smooth, so hard-attaching doesn’t work as well especially if you’re looking through the actor with a camera.
So should I just be updating ReplicatedMovement.Location or that and the actor location? Is OnTick the best place to do it , or in something like OnCharacterMovementUpdated or should I use one of the virtual functions OnRep_ReplicatedMovement or PostNetReceiveLocationAndRotation?
How do you stop the ragdolled player from having issues with network replication? Does he not jitter at all? Is it just the actor that’s left after a player dies, or is the player still possessed by a controller?
Ahh, apologies…I didn’t read the post properly. I am yet to try to replicate this over a network. If I find some time I’ll give it a try and report back, although from what I understand, replicating ragdolled characters is more than a pain in the **** so I suggest going with TheJamsh’s solution. Sorry for wasting your time and good luck.
