I have a prop that flies around my island like a blimp. It passes through 4 locations at opposite sides of the island like a giant square path. I noticed at times the prop would get stuck, skip the next location in the path, and then suddenly appear at the next following location after some time. I’ve been using MoveTo in a loop and it absolutely works as intended, never cancels, and always completes.
I spent a day debugging this and realized if I move the player closer to the next intended location, the prop would not get stuck and would visibly animate to the next location. In fact, if I chased the prop around the island, the entire loop animates smoothly. I switched my implementation to use TeleportTo and got the same results.
It seems that at a certain distance from the player the server no longer updates the position of the prop to the client. I can 100% repro this issue and in fact sit at different corners of my island to make the prop get “stuck” at various places along the flight path at what appears to be a consistent distance from the player location each time. Chasing the prop around the island maintains a closer distance and the problem disappears.
Is this a culling behavior for replication? Is there a setting for this that can be modified?
I did another test with two players at opposite ends of the island. Each player sees the prop get stuck at different locations along its path, but at the same relative distance from each player. It appears the prop’s location is still sync’d and consistent across clients when it finally visually pops at the next location along the path - as if to catch up.
I am experiencing the same issue with TeleportTo. Sometimes it works properly and it seems to be dependent on how far away I am from the object.
In Unreal Engine, there is an Always Relevant option you can check, but there doesn’t seem to be one for UEFN. It would be nice if we could control which actors should be always relevant.
I was experiencing the same problem, that a prop that was getting moved with the MoveTo() method was not updating for clients that were too far away and now found a solution:
In another post, someone pointed out that Cinematic Sequence Devices have a option to make them always relevant, called Level Sequence Actor Always Relevant. So if you parent the prop that you want to move to that sequence device and use the MoveTo() method on the sequence device instead of the prop, it should also update the props position, even from far away. You don’t have to play any sequence on the device, it just acts as parent dummy. For me this worked flawlessly.
I saw that post you mentioned. This does work thanks to the little extra bit of instructions you provided (Moving the sequencer not the child prop). Thank you so much!
Coming back to say this issue is still existent. You can work around one prop using the sequencer hack (And let’s be honest it’s a hack), but when you have props that are parented to other props and they need to move then things get wonky. If you have props A and props B1 - B4 for example, and you wish to move Prop A from vector 1 to vector 2 and WHILE that is happening rotate prop of type B then you will see the lag behind when you teleport them to there new location with the different rotation. It’s obvious this is because the prop they are parented to is moving so they will lag behind the parents position (if the parent is moving forward relative to the child props). As far as I’m aware you can’t just apply rotation in a relative manner. Then the cherry on top is that if actors are far enough that the replication bug comes into play you can have the child props lag behind by many many meters until they are moved again and the actor is there to see it. (If a tree falls in the woods and no one is around to hear it, does it make a sound?) I’ve been holding back several maps because of this. I’ve tried using control rigs and that makes no difference, I even went as insanely far as to replace vector transforms all together and have instead tried to apply different materials with world position offsets and while this can stop props from detaching from the parent prop by a quarter mile, it is still effected by client / server replication issues. Doesn’t matter if world partition is on or off. This is a side effect of the optimizations that have been made to UE specifically for Fortnite to support 100 player BR and I fear there will be no solution soon as it would require a lot of engine work. It looks like I will soon be forced to release some of my maps that are plagued by this irregardless and hope that players will understand the limit we are working with on this subject.
For what it is worth I have compiled a video showing this bug in action. Here the cinematic sequencer “hack” is being used to control the movement of several props. I demonstrate even with spatial loading the bug does exist still, even though very slightly. (Granted some jitter is expected as no care was taken to synch movements, however in the real world example the cannons are moved when the ship gets to the end of its MoveTo “queued” if you will as to ensure the parent prop is not moving). The result you get is entirely dependent on your location in the world. Some ships cannons do not stay attached at all depending on where they are spawned while others seem to have no issues. I can relate this to the Blimp example the OP provided. The simple solution in my case it to not actually allow the cannon props to move on AI ships, but this does not help others who have moving platforms that are far away or that are in one of the quads on the map that simply break client replication. (Usually Quad 1 if you draw four quads using the map origin 0,0,0 as the x and y intercepts).
Edit:
I’m begging for this one to be fixed, please. I’ve found another hacky work around where if you “wiggle” your prop as in you make a loop and nudge it up and down 1cm it will force it to at least appear when an actor is close enough to it. So if you teleport a button for example, you may need to do this so the button is their when a player get to it.