Selective replication of clients?

Creation of a multiplayer game. How can I do selective character replication? Suppose there is a Character behind the camera view (or behind the wall) and that they replicate only when they enter the player’s field of view? If possible on Blueprint

Read up on Network Relevancy

You don’t want to fiddle with the replication of a pawn this way. It would increase network saturation, bandwidth consumption and it would add an additional delay akin to peakers advantage.

There’s also client performance. Loading/unloading the actor. Pawns are heavy actors.

In essence you’d be loading and unloading the character at high rates.

What’s the overall purpose?

The general goal is not to show characters to clients over the network until they are in the camera’s field of view. To reduce the possibility of using ESP cheats.

There is also no information anywhere about using Net Dormancy: Dormant Partial. As it turned out, it works only through C ++, does not support blueprint, but at least some example is needed.

I had a feeling that’s where this was headed.

There’s only one approach that comes to mind when dealing with ESP. That’s a hella lot of traces and conditional checks against the games features/abilities,rendering/occlusion etc etc etc.

The player gets flagged for a thorough dev/ac-team review of the round played.

You’ll need the server to record demos (replay system). You’ll need to add collisions to actors that normally don’t have, nor need them (e.g. foliage). Can’t do traces against branch leaves, bushes, grass etc blocking the view if they don’t have collision.

e.g. long range through heavy soft cover… player hidden by bushes, grasses etc.

You’ll need custom trace channels as well. Along with a comprehensive occlusion table that details the rendered/not rendered distances for each of these special actors. Highly consider LoD changes as well.

If your game has spatial audio (panning/hrtf, w/attenuation) for player movement… footsteps etc. Then you’ll need to consider false positives at specific ranges. Can’t have the system flagging a player that could easily be heard. You also have to consider software/hardware compression on audio. This will increase the loudness of lower volume sounds over distance.

Heavy usage of “was recently rendered” will go a long way. Loads more to this and your maps/asset have to be designed from the ground up based on the intent.

All of this needs to run on the server, never on the client. This will be a nice chunk of your overall tech debt.

At the end of the day you also have to be able to prove the use of illegal software before taking heavy action. e.g. perma bans.


IF players know you are actively checking for ESP usage then they’ll stop being obvious about it. They won’t take shots through heavy visual cover. They won’t track players (ads/soft aim directly on them) outside of audible range. In essence they’ll know where everyone is and play it like happenstance and you’ll be none the wiser, nor able to confidently say otherwise.

You may catch the script kiddies here and there or the rager, but not the majority paying $30-$100 a month on a subscription package.

This results in the majority of the code you’ve added to detect them a complete waist…performance bloat.

ESP is a hard nut to crack. I’m pretty confident if any of the other AAA studios, AC developers had a way to do it, they’d do it and this conversation wouldn’t be taking place.

Now that I’m fully engaged in this topic I can pile on more feedback about disabling replication.

Consider the following scenario.

Each player (4) can only see 1 other player in their current frustum. If you disable replication on any of them you disable it for all.

Disabling replication would also eliminate footstep sounds for hidden players. Footsteps are generated using animation notifies. Notifies require animation. With replication off, there’s no updates to the pawn, thus no animation.

You wouldn’t hear them running away or moving around to another position. Then pop, they are back.

In essence the player in the bottom could literally run directly up to the top player and he wouldn’t know it until he’s shot in the back.

Yes everything is correct. The player at the bottom does not see the player at the top until the review opens on him, also as for the sound, since the server knows everything about the players, you can set the sound to play at specific coordinates of a certain distance and the players will be heard behind small objects. With the sounds of a shot, the same is true, only the radius is larger. The question remains in the load on the server with this use (tests are needed because it is necessary to set up the world). Bushes and glass will be completely transparent, respectively, through them there will be replication. Also, in addition to the ESP, this approach should complicate the life of aim bots, since bones or collisions of characters will not be visible through the walls.
If it’s not difficult, you are interested in an example of the work of Net Dormancy: Dormant Partial

Well if not by disabling replication of a specific character for a specific player, do you have any other suggestions? Or leave it as it is and at the same time just track and catch a larger circle of cheaters with the help of anti-cheats?

Even if you don’t replicate the character you are replicating events that highlight location. ESP doesn’t have to use the character. It can use the footstep “sound location” as a beacon. Footstep sounds are typically played via an audio component in the character class. It’s positioned at the feet near the skeleton root bone. IF you use spawn sound at location, then you are still providing a “LOCATION” that ESP can use. That sound needs to be applied near the root bone location of the player that’s moving.

I can take that location and draw a character sized box/capsule in world space in an overlay… tada ESP.

Also applies to any other sound the character would make. Gun shot, Gear rustling, Reloading etc.

Bushes and glass will be completely transparent, respectively, through them there will be replication.

Servers do not render. They only use the collision hulls of meshes and other collider components.

Also, in addition to the ESP, this approach should complicate the life of aim bots, since bones or collisions of characters will not be visible through the walls.

This won’t have any effect on aim bots. They use the skeleton for aiming. If players are shooting through walls, then your game is client authoritative. It should be Server Authoritative. Shots that do damage are spawned/initiated on the servers sim. Clients only fire “Fake” projectiles/traces for responsiveness.

The server needs to verify (scrutinize) the spawn/start location of the shot in comparison to the location of the player (character skeleton etc) in its sim and disregard any muzzle/camera position on the autonomous proxy.

The only practical way to eliminate ESP and Aimbots is for the server to handle all rendering and simply send the client renders of the frame. Stadia does this.

I highly recommend you dig deep into the multiplayer side of games. Fully understand the replication system and how it impacts other aspects of the game.

To do selective replication you’d have to for all intents and purposes rebuild UE replication system from the ground up. There’s a lot more to it then simply toggling for X player.

There’s gameplay consequences.

Let’s forget about character replication, explain how Net Dormancy: Dormant Partial works, and how to use it preferably with an example