Stop element sync on demand

[haron4igg]

Is your feature request related to a problem? Please describe.

In respond to total disaster with WH/ESP cheating this days,
i think there is actually a solution, which will cure this issue for competitive servers for like 80% of cheat use-cases.

Describe the solution you'd like

If it would be possible to pause player/vehicle/ped synchronization for particular players on demand - we would actually prevent
cheat-makers and cheaters from knowing 'long-distance' situation in game world.

There would be no-way for cheat-makers to bypass it since client will have limited data.

lets say we have method:
setPositionSyncEnabled(emement, forPlayer, state)

So for server side, we may write a script, that for every 100-300 ms, enables sync of elements that are in range of N meters to player and removes position sync for elements that are offside of this range.

If server disables sync of some element, this element should become 'non-streamable' for client. or at least hidden to some technical dimension / or sent to some outside of map location, until sync is re-enabled.

Describe alternatives you've considered

No response

Additional context

No response

Security Policy

• I have read and understood the Security Policy and this issue is not about a cheat or security vulnerability.

[Zangomangu]

This is achievable using dimensions

[haron4igg]

This is achievable using dimensions

2 of most used cheats that i know bypassing dimensions already.

[CrosRoad95]

setPositionSyncEnabled(emement, forPlayer, state)

this function sounds like most dumbest thing i have ever seen. I know that recently cheaters count increased but solutions like your should never be accepted.

When i have been working on bullet physics, my idea was to use it in deathmatch server so server know what player sees and what should be synced, that way you won't ever know even enemy rotation if he is outside eye sight

[haron4igg]

setPositionSyncEnabled(emement, forPlayer, state)

this function sounds like most dumbest thing i have ever seen. I know that recently cheaters count increased but solutions like your should never be accepted.

When i have been working on bullet physics, my idea was to use it in deathmatch server so server know what player sees and what should be synced, that way you won't ever know even enemy rotation if he is outside eye sight

Its just a tool which you may or may not to use depends on situation. For me its not improtant if player knows what is rotation/position of enemy in 1000 meters, but it is crucial that cheater is not aware of gameplay situation in 1000 meters.

In my server - cheaters using ESP to observe where 'big fights' are happens, or observe if some lonely player visiting some 'profitable' location. so they can come there and get 'easy profits'. This is what i'm trying to stop, and i can do nothing with this using current toolset.

On other hand - so far i have banlist of 140 players only for this year, who been caught using known cheats, using features which i'm able to detect. I can't imagine how much more people using this undetectable ESP, but at the end i'm having numerous of complains and people stopping play just because they don't feel confident that we can handle this issue.

[haron4igg]

At the moment few admins of similar project as mine, (me as well) having solution, to 'hide' player/vehicle from render so cheats are being confused and not able to render it. This is literraly the same idea as 'setPositionSyncEnabled' - but it's client-side solution and could be easly bypased in any time by cheat-devs.
And this was the last thing with current tool-set we were able to oppose them...

[ffsPLASMA]

This is achievable using dimensions

Working with dimensions on a large or specific way is either annoying or impossible.
Disabling sync of one element for a specific player or group of players could be very useful.

something like that I have in mind:

syncElement(element, player/table, bSync)

• element: the element to sync or not sync
• a player element or a table of player elements to sync to
• bool to let it sync or not

[Zangomangu]

From haron's description it sounds like he needs a cutoff based on distance.

So we could have an opt-in setting to disable sync updates over a certain distance between players
One solution could be to allow disabling lightsync entirely (gotta investigate to see if this is feasible)

[haron4igg]

From haron's description it sounds like he needs a cutoff based on distance.

So we could have an opt-in setting to disable sync updates over a certain distance between players One solution could be to allow disabling lightsync entirely (gotta investigate to see if this is feasible)

I prefer still to choose who should receive updates, and who not.
For example - team-mates should be able to see each other, or car-owners should see their cars on GPS/Map at any distance.

As of my understanding of light-sync, this should be already feaseble, because current light-sync evaluates distances for each player individually. And my proposal just needs one more extra flag on each syncable element, to filter it out for particular player.

[Zangomangu]

Those are some good examples

My concern with a scripting function like this is that it gets mismanaged by scripters

There have been many reports from server owners claiming an issue with MTA when it's their own bad scripting allowing clients to abuse their server. So it's hard to see these people making proper use of a function like this.

But considering that anti-cheat is the job of server owners there should also be the necessary tools available. So overall i'm in favor of adding a function like this, as I don't see an alternative to countering ESP cheats

[Dutchman101]

I don't agree with the concerns, and i support implementing this suggestion, good idea.

[T-MaxWiese-T]

something like that I have in mind:

syncElement(element, player/table, bSync)

• element: the element to sync or not sync
• a player element or a table of player elements to sync to
• bool to let it sync or not

That's what we need. Currently, only vehicles, peds and players are synchronized. But we are also working on object synchronization: #3405 . What I am currently missing with vehicles and peds is that if you set the synced parameter to false, you can no longer set it to true. This means you are forced to create a new element if synchronization is desired and set the parameter to true.
Players are also elements there would be the question whether you should be able to deactivate the synchronization there. This might be fun for cheaters.

[T-MaxWiese-T]

So I see some inconsistencies with the deactivated synchronization of the different server-side elements.
So you have to ask yourself the question: What exactly does no synchronization mean?
I would say no synchronization means that all player actions are not synchronized between the clients, i.e. the values from the server cannot be modified by clients. This means that there is no exchange between the server and the clients.
Then there is the question if a sync is deactivated for an server-side element, should the position and rotation be synchronized by the server as for example with createVehicle?
I would say yes, that should be an additional argument.
And then there is the question of whether server-side elements should behave like client-side elements if only the position and rotation is synchronized by the server?
I would say no because otherwise it would look strange if a player moves a vehicle and then it is synchronized by a player and the vehicle is suddenly somewhere else. This means that the server-side elements should be static as defined by the server so that every player sees the same thing.
You could possibly use other arguments such as whether the element health should be synchronized.

[Fernando-A-Rocha]

Peds and vehicles with "sync=false" are not synchronized by any clients, meaning that if they move somehow, the server won't receive or will ignore any updates, right?

we would actually prevent cheat-makers and cheaters from knowing 'long-distance' situation in game world.

Regarding this core issue, haven't we solved it already?

With these 2 server settings, we can determine the distance within which peds and vehicles will be synced to clients, no?