Set Actor to be owned by Client In local multiplayer problem


I have an actor called: “ActorA” where both players must be able to call an RPC functions for turning on a point light inside of the actor.
Inside my player controller, I have the event trigger input ( F button on the keyboard) which calls a blueprint interface function called: Interact" inside the ActorA.

Inside ActorA interface function " interact" I’m checking with Has Authority: if the function is executed on the client or the server-side.


So far so good. The problem is if I call this function from the client it goes on Remote authority and it tries to call ToggleVisibilityOnServer Event function and since ActorA its self has no owner or the owner is the server, this event is getting dropped and doesn’t work if it’s called from the client since the client it’s not the owner of this actor and all RPC’s are dropped.

I’ve already tried with Set Owner node inside ActorA in order to make the client the Owner of ActorA but it never works.

Since I want to keep all my events for ActorA inside ActorA and the listen server and the client call them from the player controller I want to make the Client Owner of the ActorA in order to BOTH the server and the client can Run RPC’s properly.

Could anybody help me, please? I’m kinda lost here.

Owner it’s a replicated by default variable all you have tp do it’s reference it from the client.

Have you figured this out yet? May I ask why your actor is coming from the game state? Just curious.

There’s no need to pass ownership back and forth - if anything, the server should own everything and the client makes the requests (ask’s permission) from the server to interact. Otherwise if you call the interact event directly from the client, I could fudge my location and even though I’m nowhere near your light, I can call the interact event on it.

It’s important to check to make sure things are valid on the server side before you trust input from the client. I would highly suggest adding logic to do the line trace or check for overlap or something on the server side after the client presses his interact key just before you call the interact event on your actor.

I have a Replication Series that introduces beginners to the world of multiplayer networking in Unreal - it’s just a short one at the moment but it may help you connect some dots around this topic (I’m not calling you a beginner btw - just saying it’s a series for beginners :rolleyes:).

Here’s a quick and dirty sample. I’m assuming you know something about interfaces and how they work. In this case, I have a parent actor called BP_Interactable that implements an interface that I’ve named **BPI_Interact **and anything in my game that can be interacted with will be a child of this BP_Interactable actor.

This would be on my Pawn: Pawn presses their interact key, we call an RPC to run on the server which calls the Interact event on the Interactable - in my game I have a line trace that returns the actor that the line trace hit).

On my BP_Interactable object, the **Interact **interface event is executed (we’re already on the server at this point so we can either just run logic on the server or call a Multicast if we want to execute on all relevant clients - no need for passing actor ownership back and forth - that can cause more headaches than it would solutions.

From my Understanding you would need to pass the Interactable and Self threw the Server node also? other wise its running on server trying to get self, am i right in saying that?

Sorry, just seeing this now. No you wouldn’t since the Server already knows that “Self” is referencing the Pawn that’s doing the interaction.

The server has a reference to the Pawn as well so we use that instead of trusting what the client sends us as “Self”.

Anytime you want to pass anything from the client to the server, the first assumption you should make is that the client is a scum and he/she is going to try and cheat.

So ask yourself “what if the client told me “Self” was actually another player?” - this would mean that PlayerA can force PlayerB to interact. Although that would be a cool mechanic, I don’t think that’s what majority of games out there are aiming for :joy:

1 Like