Under certain network emulation settings, it looks like outgoing packets from the client will be dropped in groups (around 4 or more packets at a time) rather than individually. This leads to the ac ...
Related to [Link Removed], where calling a multicast RPC in BeginPlay results in the character being spawned on the client with the incorrect role/initial property data. One thing to note: this does ...
The conditions for this bug are fairly specific. The actor must be statically placed, with its only replicated property being the fast array, and net.PushModelSkipUndirtiedFastArrays must be enabled ...
See linked UDN for more info. When a server initiates a non-seamless travel, it will inform any connected clients by sending the reliable ClientTravelInternal RPC. After a delay (controlled by Serve ...
There was a recent bug report that matched the description of some older cases (see linked UDN). The issue raised in those cases, [Link Removed], had been fixed, but the recent question seemed to in ...
When the client receives a bunch, it will first apply all the new values for replicated properties before calling any repnotify functions for those properties. This means that in between the StaticM ...
COND_InitialOnly properties can be resent when an actor becomes relevant to a client again. However, if the property is push based and it was never replicated the first time the actor was created on ...
Because the subobject's RepLayout is empty, it won't write anything to the bunch when recording a replay checkpoint. This means that when scrubbing to a time past a checkpoint, the destroyed subobje ...
It seems as though calling a multicast RPC during BeginPlay on the server will cause the new actor to finish spawning on the client before applying any initial replicated data, such as the actor's R ...
Because DemoNetDriver doesn't override PostTickFlush, it will call the base UNetDriver's PostTickFlush. When both the game NetDriver and DemoNetDriver are ticked, this results in the online interfac ...