Announcement

Collapse
No announcement yet.

Improvement of NetMulticast to save performance and bandwith on nonrelevant actors

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

    [FEATURE REQUEST] Improvement of NetMulticast to save performance and bandwith on nonrelevant actors

    According to this topic reliable NetMulticasts are sent from the server to the client even if the multicasted-to-actor is not relevant (aka the relevancy-check is skipped for reliable NetMulticasts).
    Originally posted by GarnerP57 View Post
    The server holds all the cards so it decides if a client needs to receive the event or not. The server makes a relevancy check if the Multicast is unreliable. If the Multicast is reliable it skips the relevancy check though.
    The whole point of relevancy checks is to save bandwidth on unimportant actors.
    Originally posted by VovanSK View Post
    Currently NetMulticast is sent to all clients (even if calling actor is not relevant to them). I'm only tested Reliable NetMulticast but more on that later.
    There is bug report which covers some part of this problem so vote for it and maybe Epic will finally fix this issue.
    https://issues.unrealengine.com/issue/UE-36139
    If this is true, then this obviously causes alot of performance waste and bandwith waste. I don't know how it behaves with unreliable NetMulticasts.

    My suggestion is that NetMulticast-RPCs should have their reliability-options extended to save bandwith and performance:
    Instead of only having Unreliable and Reliable we should have four categories for NetMulticast:

    UnreliableToAll - Unreliable multicast is sent from the server to all clients regardless of relevancy
    ReliableToAll - Reliable multicast is sent from the server to all clients regardless of relevancy
    UnreliableToRelevant - Unreliable multicast is sent from the server only to clients for which the multicasted actor is relevant
    ReliableToRelevant - Reliable multicast is sent from the server only to clients for which the multicasted actor is relevant

    If this can't be done or until this is implemented, a quick hotfix would be to have NetMulticast have a relevancy check for both unreliable and reliable multicasts (as stated in the quotes, it seems like unreliable multicasts already do a relevancy check, the reliable rpcs however don't).

    #2
    Maybe make it custom - so it is up to you to decide whether it is relevant or not? The default should be always relevant though.

    Comment


      #3
      It's done this way on purpose, since the actor may become relevant again later and your RPC could have changed some important state.
      Adding a ReliableToRelevant mode would be possible but what exactly would you use this for?

      Comment


        #4
        Originally posted by Zeblote View Post
        It's done this way on purpose, since the actor may become relevant again later and your RPC could have changed some important state.
        If the actor isn't relevant to the client then it won't run the RPC anyway so I don't understand your point above. Your RPC isn't automatically resent if relevancy changes.

        Maybe you can clarify.

        I can see several issues with this, one is bandwidth. The other is cheating. I wouldn't want all clients to know about another one which is out of their "range".
        [PLUGIN] Google TextToSpeech (WaveNet) Integration

        Comment


          #5
          Originally posted by Stefan Lundmark View Post
          If the actor isn't relevant to the client then it won't run the RPC anyway
          The RPC is sent to and processed by all clients that know about the actor. If your actor is spawned on the server, and has never been relevant to a client, the RPC will not be sent to it - it wouldn't be able to process it anyway.

          Comment


            #6
            Originally posted by Zeblote View Post

            The RPC is sent to and processed by all clients that know about the actor. If your actor is spawned on the server, and has never been relevant to a client, the RPC will not be sent to it - it wouldn't be able to process it anyway.
            Well. The point of this thread is that what you're describing above isn't true. All clients will receive the event no matter relevancy.
            [PLUGIN] Google TextToSpeech (WaveNet) Integration

            Comment


              #7
              Originally posted by Stefan Lundmark View Post

              Well. The point of this thread is that what you're describing above isn't true. All clients will receive the event no matter relevancy.
              Relevancy isn't always the same as a client knowing about the actor. If an actor does not exist on a client, it will not send an RPC there - that would make no sense.

              Also, I looked at the code in 4.20 earlier today, and it seems like the relevancy bypass for reliable multicast RPCs has been removed, or at least, it's no longer in the same place it used to be. Needs more investigation now...

              Comment


                #8
                Originally posted by Zeblote View Post
                Relevancy isn't always the same as a client knowing about the actor. If an actor does not exist on a client, it will not send an RPC there - that would make no sense.
                Is this documented somewhere? I disagree but would be interested in being proven otherwise.

                Originally posted by Zeblote View Post
                Also, I looked at the code in 4.20 earlier today, and it seems like the relevancy bypass for reliable multicast RPCs has been removed, or at least, it's no longer in the same place it used to be. Needs more investigation now...
                Definitely.
                [PLUGIN] Google TextToSpeech (WaveNet) Integration

                Comment


                  #9
                  Originally posted by Zeblote View Post
                  Also, I looked at the code in 4.20 earlier today, and it seems like the relevancy bypass for reliable multicast RPCs has been removed, or at least, it's no longer in the same place it used to be. Needs more investigation now...
                  Oh, if that's true that'd be awesome.

                  Comment

                  Working...
                  X