Announcement

Collapse
No announcement yet.

Replication trouble

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Originally posted by GarnerP57 View Post
    Ownership is what makes "RunOnServer" possible so if the client that calls "RunOnServer" is not the owner of the actor when calling the event the server will drop the event and do nothing (there should be a warning in the log showing that the event was dropped).

    So make sure that when the client picks up the weapon that the server "SetOwner" on the weapon to the pawn that the client currently possesses.
    Oh ok this is new for me, and you were right. Since the weapon is placed in scene there is no owner being set on it. And of course output log shown it but I was so accustomed to string printing in the viewport that I've absolutely forgot about log tab existence. What a moron I am But this also raises a new question if I may, if I have let's say, a lot of actors that have some network relevance like doors, deposit boxes (opening animation from timelines), etc. what owner should I set it on?

    And of course thank you all very much for finding time to help me.
    Last edited by Mat5i6; 10-30-2018, 06:26 AM.

    Comment


      #17
      You're welcome.

      A lot of things don't need an owner at all you just have to accept the limitation that you will not be able to use "RunOnServer" RPC's on these actors.
      If you have a treasure chest placed in the world the chest would not be owned by anyone, but how would a client then interact with the chest?
      You would use something that the client already owns like the Pawn/Character and on this make a "RunOnServer" interact event. then the server-side character sends a regular event (non-RPC) to the chest and the chest can set a replicated variable and/or make a Multicast event back to all clients.

      Comment


        #18
        Originally posted by Mat5i6 View Post

        Oh ok this is new for me, and you were right. Since the weapon is placed in scene there is no owner being set on it. And of course output log shown it but I was so accustomed to string printing in the viewport that I've absolutely forgot about log tab existence. What a moron I am But this also raises a new question if I may, if I have let's say, a lot of actors that have some network relevance like doors, deposit boxes (opening animation from timelines), etc. what owner should I set it on?

        And of course thank you all very much for finding time to help me.
        Sorry, I had assumed when you'd "picked up" the weapon that you'd done so using an RPC to attach the weapon to your character on the server (this automatically transfers ownership to you, thus enabling the functionality Garner has excellently described).

        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.
        Last edited by GrumpyNZ; 11-01-2018, 01:43 PM.

        Comment

        Working...
        X