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.
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.
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();