Suggestions on Network

Suppose I have a server with three players: A, B, C. Players have an attribute: x, which indicates their ability to camouflage themselves. There is another attribute: y, which indicates their ability to discover each other.

The maximum distance they can find each other: z = y-x. For example, if A wants to find B, the distance Z between A and B must be less than A’s detection ability y minus B’s camouflage ability x. So there may be a situation where a can’t find B which is close, but C which is far away, because C is not good at camouflage himself.

If the client can know other people’s information and only set it as transparent material or other display camouflage, then the cheating software can identify the enemy through various marking methods. So many game stealth skills will be targeted by cheating software. So I imagine that if the server thinks you can’t see the enemy, it won’t tell you the enemy’s information. Whether to send the enemy’s information to you depends on the judgment of the server. If you want to achieve such a function, the default synchronization method seems to be not working.

So I find a concept named Relevancy .It can control whether the two clients object are network related or not. But we can`t edit it by bluepoint,So only you developers can implement it in depth. I think such a function is necessary. I hope it can be installed in the next version. The simple point is to use two floating-point controls, like net curl distance.

Can you site a thread / bug report showing where Network Cull Distance Squared doesn’t work in Blueprints? Either way, was thinking you could do a distance check and untick ‘always relevant’ manually anyway… But that might appear really buggy in-game. Better that something is invisible because it really isn’t relevant. Instead, why not just use transparent material FX that makes it harder to see other players (without special vision etc)… But use validation checks, so that cheat software can’t beat it easily… What cheat software are you using to test this etc?

I don’t mean that the network curl distance doesn’t work, but that it is consistent for all objects. As I said, a can’t see the closer B, but can see the farther C, just because C is not good at camouflage.

Suppose the curl distance of B is set, but maybe C is better at detection than a, then a may not see B, but C can see B at the same distance.

Therefore, the cull distance, which is consistent for all clients, cannot be eliminated.

In fact, cheating software is very easy to steal the information in the memory. So if the information of a, B and C is synchronized to the client, whether you set it visually or not, it is visible to the memory, isn’t it?

So it is feasible to compare two values. Whether curl distance or not depends not only on the square of the distance set for the eliminated object, but also on the value of the player’s visual detection ability set for the player’s character blueprint. This ensures that the same curl distance can be different for different players at the same distance.

A player with the ‘discover’ ability can always see all other players (same as ‘Always Relevant’).
EXCEPT maybe those players with the camouflage ability (as its not clear if they stay invisible).

Essentially any players with the ‘camouflage’ ability transmit a much smaller NCDS to all players.
EXCEPT maybe those with the special ‘discover’ ability, who are able to see everybody (or not).

The thing is… Using this approach for gameplay will still be glitchy, similar to having LODs constantly pop in and out crudely. Plus if there are a subset of players that have the special ‘camouflage’ ability, and a subset of players that have the special ‘discover’ ability (with the ability to see all others including the special camo players - or not), it will require some kind of ‘remote relevancy’ settings. Like having an ‘ONLY OWNER SEE’ property operating remotely with a list of players stored inside each player containing remote visibility settings etc. This sounds like Custom Engine work tbh, rather than any kind of Blueprint networking limitation… :slight_smile:

This is my meanings too,So we have not ‘relevancy’ settings to make it.we need this relevancy’ settings can be customize by bluepoint.Such as using floating value of detection ability from investigator minus floating value of camouflage ability of camouflager as judgment condition to control
And this ability to discover and camouflage may be related to distance, for example, if you are too close, the camouflaged player may still be detected. However, this setting can be customized externally, and does not need to be directly implanted into the ‘relationship’ settings. We only need a Boolean value that can be inconsistent for different players, which is used to control which players the server synchronizes the information of the actor (for these player controllers, the Boolean value of the actor is true) or not (the Boolean value is false).
Eeem also requires some functions, such as the player controller can have functions that return an array of all objects in the ‘relevance’ list (executed on the server). Then we can traverse the object and set whether it is relevant to the player (according to our custom conditions). Then the next step is to synchronize the related objects to the player.
In a nutshell, I hope to provide a simpler way for us to define more conditions for the function AActor::IsNetRelevantFor();