Unreliable Events delayed until net update intended?

Development Programming & Scripting Multiplayer & Networking
, , ,
1

Hi,

Until today I have been using the following setup for my replicated blueprints:

  • Replicated variables to record a stat of an actor
  • OnRepNotify functions to adjust the actor after a net udate
  • NetFrequency variable to adjust how often I want the net update to be performed
  • Unreliable events to request an immediate non-gameplay-relevant action, such as sound or pfx
  • Reliable events to request an immediate gameplay-relevant action, such as death or spawn

That setup made perfect sense to me, but today I realised it does not work this way at all. As it turns out, my unreliable events weren’t being delayed by some mysterious amounts of lag, but by the NetFrequency variable. So now if I want to spawn a particle system on clients at the right time I either have to crank up my NetFrequency to a performance-killing levels or set them to reliable, which puts them on the same level of priority as damage events, which is not responsible at all.

In result, unreliable events are quite useless to me because if want to wait for the next net update, I have OnRepNotify functions for that.

Is this an intended functionality?

Kind regards,

Marcin Dudkowski

2

Hi Marcin,

It is intentional that unreliable multicast events get queued up an processed on the next net update for the actor. However, unreliable unicast events should be getting sent immediately. I guess the thinking was that part of being “unreliable” also meant that the event wasn’t time-critical either.

Unreliable events can be useful, as there might be cases where there is a one-shot event that isn’t necessarily time-critical, and introducing a replicated property to handle it would otherwise be unnecessary.

3

Hi Ryan

Thank you for your reply. That is something to go on.

With this in mind, then, what would be your suggested technique for prioritising RPCs, such as EventAssembleTheBridgeSoThePLayerCanGetThrough over EventPlaySomeSparksCauseTheBulletHitTheWall?

Kind regards,

Marcin

4

Hi Marcin,

Something like the AssembleTheBridge RPC sounds important enough to be reliable to me, or better yet, perhaps based on a replicated property. The main benefit of using a property for it would be that if you support join-in-progress, late joiners would automatically receive the most up-to-date state.

Unless you’re really trying to optimize aggressively for bandwidth I wouldn’t worry too much about using reliable RPCs. If you really need to you might be able to split your functionality into multiple actors with different NetFrequency values - but this might add more complexity than value.

Also, if you increase the NetFrequency on some of the actors with time-sensitive RPCs, you could try lowering the frequency on other actors that may be less important to compensate and even out performance.