Originally posted by Mat5i6
View Post
With something like a door you don't need to own it to manipulate it, what Garner has been explaining is that you need ownership to invoke a Run On Server event, as without ownership (of the class you're calling an RPC from) the event will fail to get to the server in every case.
So to clarify, ownership is only required to get you onto the server. Once you're on the server you can manipulate things as the server in most any way you wish and replicate the changes the server makes to clients through one of either: Replicated variables, Run On Owning Client Events (RPC), Multicast (RPC) and/or RepNotify Variables (these are the ones that are important when you're consider Net Relevancy, more detail at the end of this post).
All you need is a reference to the door/box etc. and the ability to get your input event (open box/door) from your client to the server. Since likely you'll be using your player character class to do this action/input you need to get it to the server using your normal method. Since you already own your character by default the RPC event to "open door/box" will go to the server as expected without issue.
To ensure you always get the result you want, call your Run On Server event in the class that you own, you can cast/interface to call events on other actors/classes from there with confidence as you definitively have Authority over that thing as the server if you follow this procedure.
So when you're on the server in your Character Class, you can use your reference variable to cast (or use an interface) to start your timeline that will run in the door/box class. (You can think of it kind of like the server owning the door, and you're asking the server to open the door for you, and since the server has authority over the door, it will oblige. But for accuracy's sake, the server, under the technical UE4 Definition, is not able to have "Ownership" of something, it's more that the server maintains control over anything and everything even when an object is unowned. If you queried "Get Owner" on an object that had no owner, it would return null.
With regard to relevancy, this isn't related to ownership. Relevancy will determine what a player who wasn't within the net relevant range at the time of the event will see. In this case, if the client is too far away to be net relevant when you opened the door with an event, even if it was multicast (these are fire and forget events in so far as they will only change variables for clients who are net relevant at the time a multicast event is fired), the changes won't be reflected for that client when he becomes relevant without a RepNotify that sets the new state of the door for it, and thus now is out of sync. (i.e. the player who became net relevant will still see the door as closed, while the server and any player that was net relevant at the time would see it as open).
Net Relevancy quite a broad subject and too detailed to start writing it all out.
I suggest you go and watch this excellent Epic Tutorial carefully, as it explains everything you need to know in regards to Net Relevancy.
Here
Hope this helps.
Leave a comment: