How-To: Cull Pops on the Server (Optional)

Goal: stop sending pop events to players who are too far away to see them. With culling on, the server delivers each event per-client only to players in range, instead of multicasting to everyone - a bandwidth win on large maps with many players.

Prerequisites
You completed Quick Start. This is a single project setting - there is no code and nothing to add to your actors.

1. Set the cull distance

Open Project Settings -> Crimson -> Crimson Number Pop -> Replication and set ServerCullDistance (cm). 0 (the default) keeps the multicast-to-all behavior. Each broadcast then compares the event's resolved location against every player's view location (GetFocalLocation) and sends only to those in range.

Project Settings -> Crimson -> Crimson Number Pop -> Replication -> Server Cull Distance (cm). 0 = off (multicast to all).
Pick a distance that respects client filters
Set ServerCullDistance to at least the largest MaxDisplayDistance your players can choose. The server cull runs first - a client can never show a pop the server culled away.
Verify
With two clients and a small cull distance, damage near client A pops on A but not on the far-away client B; move B closer and its pops resume.

2. What happens under the hood

On the first culled broadcast, the plugin adds a UCrimsonNumberPopClientComponent to each PlayerController on the server - a per-player delivery channel that carries a Client (owner-only) unreliable RPC straight into that client's subsystem. You never add this component manually.

OnNumberPopReceived does not fire on the culled path
The GameState component's OnNumberPopReceived delegate only broadcasts on the multicast path. With ServerCullDistance > 0, events feed each client's subsystem directly - custom listeners bound to that delegate (HUD overlays, analytics) will not be called. Keep culling off if you rely on it, or listen elsewhere.
First event after a join may drop
The client component must replicate to its owner before RPCs on it resolve, so the very first in-range event after a player joins can be lost (unreliable RPC on a not-yet-mapped object). For cosmetic numbers this is acceptable by design.

See also

  • Concept: Event Flow & Replication - the multicast and per-client paths side by side.
  • How-To: Filter Pops Per Player - the client-side distance cap that stacks on top of this.