A dev might want to move an AActor or APawn in the server and expect to see the movement reflected in the remote clients. He checks the ‘Replicates’ flag, moves the actor/pawn on the server and then spends hours trying to figure out why it didn’t do anything on the remote clients.
I see many posts about this in these forums, never with an answer or explanation, and many people wasting hours and hours of development time because the feature they see listed in the documentation doesn’t really exist. Certainly not as advertised.
If I’m supposed to propagate the actor’s movement to remote clients through an RPC, or the feature only works with Blueprints (haven’t tried it), that should be on the docs. If Epic intends to only support people using a UCharacterMovementComponent or ACharacter for actor movement, that should be there as well.
Sometimes people say, “but with ACharacter you get client-side prediction” which is saying Epic’s way is the only way and to hell with modular design (isn’t the point of components to adhere to modular design?). ACharacter is a total mess of random features, functions, and voodoo values stirred into a soup of chaos. If I want to use AActor to get rid of a lot of that bloat and crap that I’m not using and adhere to clean modular designs, I shouldn’t be penalized for it.
Here’s a sample test if you’re curious: A Simple AActor - NOT ACharacter, NO UCharacterMovementComponent- with the replication flag on and which moves itself on the server. Result: The actor moves on the server but not on the remote clients. I.E. The ‘Replicates’ flag does nothing, as far as devs can see.
Replicate Movement is meant to work with a movement component of some kind like FloattingPawnMovementComponent, ProjectileMovementComponent, etc. All of those work with Pawns, not actors – ‘PawnOwner’ is a necessary field for all of them.
Even if it had worked on the Pawn and even if CharacterMovementComponents on Characters work, it raises the question as to why the ‘Replicates’ is in AActor if it’s the one place where none of these features work.
projectile movement component works with any actors, not just pawn. “replicates movement” should replicate the location of the actor, whether it has a movement component or not.
i made a test with an actor. i gave it a projectile movement component, set its actor properties to Replicates and Replicate movement, and i added velocity on the server. the replication works fine, although its not very smooth.
then i made a second test with an actor that doesn’t use a movement component, and just adds a velocity vector to its world location on tick. as long as i had Replicates and Replicate Movement both true, replication worked fine.
then i made a third test, with the same actor from the second test, and i replicated the velocity vector, and applied the velocity to the location on both the server and client. this smoothed out the jittery motion. i think this is what epic calls movement prediction or simulated proxies or something, i just call it replicating velocity.
so whether you use a movement component or not, if you want the actors position to update on the client, make sure both “replicates” and “replicate movement” are true.
This isn’t a bug, bReplicates (the variable for the box you’re ticking) will set the actor to replicate, then you can declare variables with a UPROPERTY(Replicated) to have them replicate from the server to clients (never in reverse), or call RPCs to and from the server with a UFUNCTION(Reliable/Unreliable, Server/Client, WithValidation or not).
The basic tenant of what you’re saying is not supported by documentation. I see no documentation by Epic that says that an actors location will be updated through network connections if Replicates and Replicate Movement are both true. The ‘movement’ in Replicate Movement I believed referred to a movement component but turning it on or off, using or not using movement components made no difference. “Actor Replication” and all sub-documents talk about how to set up custom properties or doing RPCs - no mention of location changes on the server automatically propagated to remote clients.
There’s also no mention of having to do “SetIsReplicated” on the root component of your actor, which also didn’t do anything for me, but I hear people tell me it should. I see no way of calling a “set replicated movement” on the root component.
Some say I have to implement GetLifetimeReplicatedProps for the root component which sounds weird but I may try it later.
It’s a bug because if you set that variable for the intention of replicating changes in location for the actor made on the server, nothing happens - nothing is replicated. Replicating properties, which is what you’re talking about, could have its own flag or doesn’t need that flag anyway because you have to reimplement GetLifetimeReplicatedProps which should do the job on its own just fine.
It is working as intended, you’re implying it should simply replicate every single thing and that would hurt a lot of developers and their games, it’s setup like this for optimization. Unreal engine is an engine in which you can make a game rather than a preset made for you and an engine needs to draw the line between providing functionality and making the game for you because the later takes away control from the developers. It needs to work the way it currently does for optimisation.
I do appreciate you tried to help and the link looks great. I’d rather have pages I can read which I can go through much quicker than a video. I do disagree about this topic with you but I appreciate people responded.
Not to be argumentative, but I also disagree with “you wont make games following that mindset”. I’ve found the opposite to be true. People who ignore issues other people create end up drowning in other people’s work. If I order a ham sandwich and I get ■■■■-on-a-plate, it’s in my right to complain. They can say, “we didn’t say it would be an actual ham sandwich, that just a name we picked”, but you’d be doing everyone a favor by asking them to rename it or sell an actual ham sandwich.
in ue4 editor, in the details panel, hover your mouse over ReplicateMovement, it will explain:
“If true, replicate movement/location related properties. Actor must also be set to replicate.”
that tool tip is documentation, directly inside the source code, written by epic, which directly explains what i have been saying all along. check off both things and it will do exactly what you are asking for.
the reason you need to go through all the trouble of setting 2 booleans instead of 1, is that many actors you replicate will not need their location/rotation/scale replicated, like treasure chests, doors, switches, score boards, shops, weapon factories, anything stationary, anything with scripted movement triggered by an event, etc… and it would be a huge laggy waste to send all that useless extra data, every time you wanted to replicate an int or a boolean.
set replicate movement to true, and set replicates to true. problem solved. there is nothing special you have to do with your root component, you don’t have to worry about lifetime replicated props, that’s for the engine to worry about, you just check off 2 check boxes and you are done.
the documentation is not perfect, its a work in progress, and when i started using this engine, there was barely any documentation at all, and none of it addressed replication, but i still learned from various other sources and my own experimenting.
I have both checkboxes on and simply moving the actor in the server does not replicate on the remote client. I see the actor moving in the listen server, but not moving on the remote client. If there are no other steps to make this happen, then it is an honest to goodness bug in the system.
A bit later today I’ll post a test project showing what I’m saying. I need time to knock down the project to just the bare essentials and then share it.
i didn’t know you tried both checkboxes. from your earlier posts it sounded like you were refusing to use that checkbox because you believed it was only for movement components, and you seemed only willing to try what was directly written in the documentation.
but if you have both checkboxes set, and its still not working, its a bug in your code. maybe your constructor is wrong. shouldn’t you have an FObjectInitializer, which you pass to super?
class TESTCONSTRUCTOR_API AMyActor : public AActor
// Constructor declaration
AMyActor(const FObjectInitializer& ObjectInitializer);
So I commented everything out that wasn’t just the simple move-the-actor-in-the-server-tick from the whole project. Ran it, and it worked. I thought, “great, now I can add everything back in one-by-one until it breaks again and I’ll see what was wrong”.
I added everything back in one-by-one, testing after each addition. I ended up adding everything back in, and it still working. Same.Exact.Code. My conclusion is that it was a BS UE4 actor corruption crap like it’s happened to me so many times in the past. Too many to count by this point.
I am happy to hear that you have gotten your project working. I will be marking your last comment as the answer for this thread. If this issue occurs again or you still need assistance with this issue please feel free to reopen this issue by posting a reply with any additional information you may have…