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).

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).

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.

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?

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”.

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. :slight_smile: 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…

Is this documented somewhere? I disagree but would be interested in being proven otherwise.

Definitely.

Oh, if that’s true that’d be awesome.