"High single frame packet loss" with local listen server when adding components in-game


we’re facing strange server issues (when testing in the editor) that cause the spawned actors to fall through the level and the client to also pose as Player 1. When looking at the Output Log, the only message that seems out of place is “LogNetTraffic:Warning: High single frame packet loss: 16”. This only happens if we Add (Custom) Component to the spawned characters. If we uncomment that part, the two players behave as expected and the game can be played normally except for the missing abilities.

For the record, this is a C++ project with Blueprints built on top. I’m testing the game in the editor (2 players, no dedicated server), but I also tried playing the packaged game, with the same results.

Here’s what we’re doing:

We use custom spawn points holding information about the player id and unit type (as enums). The GameMode collects all spawn points and calls SpawnUnit on each connecting PlayerController with the subset of spawn points matching the controller id (first controller is Player 1, second controller is Player 2).

SpawnUnit spawns one CombatCharacter for each of the spawn points in the array passed in. Player id, unit type and location are copied from the spawn point. The character is auto-possessed by a separate AI Controller, but receives the PlayerController as owner (for easier access to global player functions and properties).

The spawned character is then registered to the GameMode and list of characters available to the player. Then we call AddAbilities for the new character.

In AddAbilities, an ability component is added to the character depending on its unit type.

Somehow, this last step causes the client to be unable to connect properly. The characters spawned for player 2 are briefly visible before they appear to be falling through the floor. Then the client respawns as Player 1. After stopping PIE, the message log contains a lot of messages about trying to interact with characters that are “pending to be killed”. Meanwhile, the Output log contains a warning about “high single frame packet loss”, which is the only indication in the log that anything is wrong:

LogNet: NotifyAcceptingConnection: Server CombatMap accept
LogNet: Open CombatMap 09/22/15 09:41:27
LogNet: Added client connection.  Remote address =
LogNetTraffic:Warning: High single frame packet loss: 16
(stop PIE mode)
LogNet: UNetConnection::Cleanup: Closing open connection. Name: IpConnection_33, RemoteAddr: Driver: GameNetDriver, PC: NoPC, Owner: No Owner
LogNet: UNetConnection::Close: Name: IpConnection_33, Driver: GameNetDriver IpNetDriver_24, PC: NULL, Owner: NULL, Channels: 1, RemoteAddr:, Time: 2015.09.22-07.41.28

If I disconnect the Add Ability Component calls, everything works fine. But leaving them connected for even a single character results in the above issue.

The GameMode, CombatPlayerController and CombatCharacter each have a C++ parent class. The ability components also have a C++ ancestor but are themselves children of Blueprint components.

As far as I remember, this used to work fine until I reparented the components with an intermediate Blueprint component (directly derived from their original parent) to handle common functionalities. We’ve got two other ability components that don’t cause any network problems, but they’re both a) spawned in C++ and b) didn’t get reparented.

I’m going to try earlier revisions to find out how to fix this, but I’d really appreciate any input on what might be happening here.

Thanks in advance,


It turns out this behavior was introduced when I marked the parent Ability Blueprint as Replicates (which I did at around the same time as the reparenting). I reverted that change for now, so our characters can use their abilities again. However, we do need the components to be replicated, because we want the players to be able to see what abilities the enemies have and plan their strategy accordingly.

I think the problem is that I was trying to change replication for a child class (all Blueprint abilities) but we’re using the non-replicated C++ parent class internally for keeping track of all abilities. I’ll have to test that tomorrow. So I’m not marking this as resolved yet.

My above speculation proved correct: Once I set the base (C++) component as replicated ( using bReplicates = true; ), the components replicated correctly and I no longer had any network issues.