Smooth Sync: Sync your Transforms Smoothly across the network

Community Marketplace
21

@Vaei

The rest don’t need to call an RPC. The owner needs to send an RPC of the transform to the server (possible because of ownership). The server then needs to send out the position to all clients (possible because it’s the server). I recognize that the server is then sending back to the owner though.

Unreliable RPCs take NetCullDistanceSquared into account. If you mean something else for relevancy, let me know and I can test anything you might be questioning.

Can you have the client change variables and have it replicate out to the server and all other clients? I thought it was purely server controlled.

That’s why I have a “SetOwnerToServer” variable, so the user doesn’t need to do anything extra for that. I do understand that multi-cast can send from server to clients regardless of ownership though. I’ll think about automatically making the server control the position, but I liked the explicit nature of having to set up server ownership so that the user knows exactly who is controlling the position. It seems common to just have the server control the position in Unreal when there is no owner though so I might implement it in the next update.

Let me know if I misunderstood anything or if you have more questions. Cheers.

22

The most important thing here is that servers do not own objects. Servers have authority over objects. Actors own objects. If you set PlayerControllerB to the owner, then PlayerControllerB owns that object - not the server, and PlayerControllerA and PlayerControllerC can not call RPCs and can not send the information that would otherwise be required to sync.

As such, if it wont work without ownership, then it’s a little pointless.

Maybe it’s a bug in the current version but it actually doesn’t sync at all, regardless. I made a new blueprint, added a cube, set the cube to simulate physics, set the blueprint to ‘Replicates’. Just doesn’t do it.

Look at this video - the character is being corrected when hitting the box on either the client or server, because it’s not synced.

https:///v39ye

23

Looking through your source now.

First, please stop using GetPlayerController 0, you’ll see it in tutorials a lot and should rarely actually be used and many tutorials are made by people who hacked a solution and thought to share it, not experienced devs. Rule of thumb - if you can’t get a reference properly, you’re doing something wrong. It returns the first local player controller and that is rarely what you actually want - especially on the server.

In your case, you don’t really need to find a better way to get the player controller because this plugin wont work with an owner for reasons already mentioned.

This piece of code here is nasty:


    // TODO: Is Unreal really going to make me send my own information back out to myself?
    // look up a better way.
    // If I own the object, don't sync it.
    if (realObjectToSync->GetOwner() == UGameplayStatics::GetPlayerController(GetWorld(), 0))
    {
        return;
    }

If the owner is a player controller, you can just check if it’s a local player controller, or even GetOwner()->GetNetConnection() != nullptr which pretty much works because of the entire problem you’re facing - no one else can call RPCs on it.

For this plugin to work, clients must not send their data. You really should simply be replicating the information and not multicasting it, it’s a waste of bandwidth. Replication is much more efficient.

That should do it

25

Vaei
Sorry, I’m new to Unreal so the terminology is a little different. When I said the server owns the object I meant it is owned by the Actor that is controlled by the person who is running the server on their computer. Thanks for the definition tips.

I believe your replication problem is because your object is set up incorrectly. Even Unreal’s replication doesn’t work with your set up. I think it’s because you are trying to replicate something else’s position and not the cube’s. Drag the cube into the level first and then put a blueprint on that and it will replicate the cube’s movement. Check out this post with relevant Unreal Stack Overflow explanation and a screenshot.

I do not understand how you can call RPCs from objects you don’t own anyway. I don’t think anyone can just call an RPC on any object that they want without ownership.

Client RPCs: “If the RPC is being called from client to be executed on the server, the client must own the Actor that the RPC is being called on.”
And MultiCastRPCs: “If they are called from clients, they will only execute locally, and will not execute on the server.”

Typically I would think you would send over an RPC to the server which would then send an RPC to PlayerControllerB (the owner in your scenario).

It will take some time to process and research a bit more about your second post so I’ll reply to that later. Thanks for the tips!

26

That would imply this only works on a listen server, not a dedicated server. With 2 players max.

The object is setup as per the instructions in the provided documentation and does indeed work with unreal’s replication system.

That’s why you don’t use RPCs. An item in the world should not be owned. That goes against unreal’s design.

27

@Vaei

I’m not able to get it to replicate movement using Unreal’s replicate movement this way.

If instead you Add a cube, Add a blueprint to the cube, Set the cube to simulate physics, Set the blueprint to “replicates” and “replicates movement”, then Unreal’s Replicate movement will work and so will Smooth Sync (with SetOwnerToServer checked, EDIT: and “replicates movement” unchecked).

If this is not the problem, can you give me some screenshots of your Actor you are trying to sync? Also any other relevant information to recreate this issue will help.

28

I believe the real motive behind this plugin is to have deterministic actor around the multiplayer computers… am I right?

29

@Syedhs
You are correct, I think.

With Unreal’s replicate movement, the server is forced to determine the position of all actors. The main motive for the plugin is so that users can set it up so that any client can control the position of an actor. With client control, the actor gets to move immediately on the owner’s screen instead of using player prediction or waiting for the server to move the actor and for the information to get back to the client.

Let me know if you have more questions.

30

The ‘stock’ UE4 rigid body replication is not deterministic ie if you kick an object for an example several times, the server and client may not have the same position and rotation of the actor.

31

@Syedhs
Oh, that’s interesting. Thanks for the info. Yes, Smooth Sync is deterministic in that sense. The position and rotation are determined by the owner and the actor is attempted to be in the same place on all connected game instances.

EDIT: I think Unreal’s replicate movement is server deterministic from my testing(maybe only under certain circumstances). Smooth Sync can be both server deterministic and client deterministic on any actor that I’ve tested.

32

UE4 is not deterministic… vehicle yes, but rigid bodies are. There are threads mentioning about this…
I myself have experienced this and have to do my own c++ code for this deterministic thing…
Your code is fine except for anti-cheating because server may no longer be the authority

34

Syed
Ah, yes, you are correct. Unreal’s Replicate Movement seems to track all movement from the server and transmits it to all clients but it seems to stop caring once the actor stops moving on the server. Then you can hit it on clients and it will get off, but once it starts moving on the server again, it syncs back up. It is weird that Unreal does it like this. Thanks a ton for the info, I’ll have to add something to my store page. I didn’t realize Unreal was lacking in this manner.

In Smooth Sync, I keep the object at the same position until the owned Actor starts moving again so it will be deterministic.

Yeah, owned by clients isn’t the best anti-cheating but you should be able to validate a lot of things (like position) server side before sending out to other clients. I wouldn’t recommend it for a super serious competitive FPS but even games like The Division use client determined position if I remember correctly. Plus it’s not like it’s impossible to cheat with server owned anyway. Definitely plenty of cheaters in CounterStrike back when I used to play.

Thanks again for the new information!

35

Alright, I understand how it’s intended to work now. Might be worth clarifying on MP page.

Unfortunately this isn’t any kind of solution to replicates movement. A solution to replicates movement would be the exact same, except with client-side prediction and interpolated corrections. This is feasible but difficult without RPCs.

What you’re trying to do is an entirely different system.

Furthermore, it’s not a solution for it’s actual intended purpose in any remotely competitive or persistent environment because it is prone to cheating.

36

@Vaei
You do not need to use the client owned functionality, it is just there if you want it. You can still have the server be the owner and there will be no RPCs from client->server.

Can you explain what you would like clarified on the store page? I’m currently at my character limit on there, I wish they would provide more space. I don’t think I’m misleading in any of what I write but I would be happy to take a look at any specific instances you point out.

I don’t make a claim to have client side prediction. I make the opposite claim on the store page of you won’t need client side prediction by using Smooth Sync (from using client owned objects, which I also state as the plugin’s key purpose on the store page).

You told me a lot of information at once. I corrected and responded to everything up until the point where you said my plugin wasn’t working. Then you never responded to my inquiry to replicate the issue. Did the problem end up being that you weren’t setting up your actor correctly?
I’d be happy to also respond to the other information you provided, but I just wanted to make sure I didn’t have any major issues like my plugin not working at all first. It also becomes difficult to talk about multiple things at once.

I’m definitely thankful for the Unreal knowledge because while I may have years of experience in multiplayer networking, I’m pretty new to Unreal. :slight_smile:

37

The server does not own something that isn’t also owned by the client, the server can be authoritative. Been over this. You’re setting the owner to a local player controller on the server and it’s not doing what you think it’s doing. The server stores all player controllers and all that’s doing is setting it to the first player controller it registered. I can’t explain this any other way, the design and your belief surrounding it is simply incorrect.

I think I was pretty clear. It doesn’t do what Replicates Movement does, it’s an entirely different system that solves none of the issues. Your plugin directly claims to be a replacement for it; it is not. That’s straight up misleading.

Not remotely similar.

No, but for your claim that it’s a solution for replicates movement you WOULD have client-side prediction (and without RPCs, because, as I’ve said a million times it can’t be owned and in that case you can’t call RPCs).

I stopped responding because I was going in circles, repeating myself over and over. It felt like you’d rather not make the plugin do what it claims and you also don’t want to update the description which is exceedingly misleading, I wasted a lot of time because I bought it on the basis that it is a solution to replicates movement. We’ve already made our own since which has proper non-RPC prediction and interpolation for corrections.

It works when you use it how it was designed and not how it says it is designed.

38

@Vaei
Sorry, when I say you can have “the server be the owner” of the actor I mean you can have a “server-owned actor” as described in the Unreal networking docs. https://docs.unrealengine.com/en-us/…ng/Actors/RPCs

So the issue you wanted solved ended up being that you weren’t setting up your networked actor correctly? Unreal’s replicate movement also doesn’t work with the way you were trying to set up your actor. There’s no possible way to solve every incorrect actor setup unfortunately and I can’t possibly add information like this to my store page since they don’t allow a lot of characters.

If your issue is the word “replacement” as meaning it will solve every possible non-advertised issue then I don’t know what to say. I have used this word in advertising for over a year (in other products) and never had an issue where someone thought it would solve every possible non-advertised issue. You would definitely use it as a replacement by replacing using Replicates Movement with using Smooth Sync. I make no claims to have features that I do not have.

What is “it”? I’m having a hard time following when you don’t specify some of your general words. Actors can be owned and they can call RPCs from client to server. https://docs.unrealengine.com/en-us/…ng/Actors/RPCs

I’d be happy to test any specific scenario you describe where my plugin doesn’t work that doesn’t go against what I have on the marketplace page though.
I’ve already tested you saying that it doesn’t take distance relevancy into account. It does. I also tested and corrected your incorrect network actor setup. I’d be happy to continue looking for an error in my product though if you want to give me other specific scenarios where my product doesn’t work.

I thought it all worked out after you stopped responding to me showing you how to set up networked actors in the Unreal engine. I’d be happy to approve a refund though if it’s possible through Unreal. I didn’t realize you were so dissatisfied with the product. I think you have to start the process though? I seem to have no way as a publisher to do it from the link Unreal provides.

EDIT: I believe this is the link to the refund page.

39

The concept of a “server owned actor” does not exist - not in those docs and not in UE4. I have ELI5’d this over and over in as many ways as possible.

I think you don’t understand how Replicate Movement works. You’re constantly saying certain setups wont work with Replicates Movement when they absolutely do. It’s extremely basic and I don’t know where your misunderstanding stems from:

There is a struct in EngineTypes.h called FRepMovement that contains LinearVelocity, AngularVelocity, Location, Rotation, and a few other things. If bReplicatesMovement is true, the corresponding settings are compressed and packed into FRepMovement in the function AActor::GatherCurrentMovement() and then replicated to clients with an AActor::OnRep_ReplicatedMovement().


    /** Used for replication of our RootComponent's position and velocity */
    UPROPERTY(EditDefaultsOnly, ReplicatedUsing=OnRep_ReplicatedMovement, Category=Replication, AdvancedDisplay)
    struct FRepMovement ReplicatedMovement;

When the ReplicatedMovement variable (struct) changes, it replicates it to all clients, who then apply the result.

As such - any client can collide with an object that is replicating movement and the server will determine the result and propagate to all relevant clients.

The problems with this is that there is no interpolation, so it snaps. It also doesn’t use any form of client-side prediction for the player that touches an object which allows it to desync constantly.

The overall problem then is that it gets corrected a lot, doesn’t factor in player latency, and teleports when corrected. No one owns the object.

Your plugin does not solve any of these issues. The store page is false - it’s not a matter of elaborating, saying that it’s a replacement for replicates movement is a lie - even if you want to believe otherwise, at this point, there’s little justification. It doesn’t have anything to do with it. I don’t care about a $5 refund - using the plugin was a waste of time and it’s misleading to other users, that’s the real issue at hand.

40

It says “server-owned actor” in the Unreal networking docs where I linked. Here: https://docs.unrealengine.com/en-us/…ng/Actors/RPCs
Here is a screen shot of the section.

I understand how Replicates Movement works. Smooth Sync can also sync position determined by the server to the clients.

My plugin does have interpolation.

41

Have to agree here.

44

That has no relevance to the context of your plugin and you’re confused.

Every client and the server each bring up a world. And for each actor spawned on the server, a copy is spawned on each client. The actor spawned on the server is referred to as a “server owned actor” meaning that when the client calls an RPC on that identical actor it is called on that actor on the server.

You’re setting the owner to server’s player controller 0 believing that it somehow makes the server own it and it simply does not. Player controller 0 is the player controller of the first player who joined the game. The first player who joined the game owns the actor using your plugin’s component. That is the player that gets synced. No one else does.

If you set ArbitraryActorX to own another actor on the server, that ACTOR owns the object, not the server. The actor needs an owning connection to call RPCs.

You can not make a solution for Replicates Movement that uses RPCs because objects that use replicates movement are not necessarily (and are rarely) owned. x10100

At the end of the day you are claiming your plugin does something that it does not, even after being told this.

  1. Doubt it
    2 & 3 Irrelevant