08.10.2018, 07:29
(
Last edited by BrunoBM23; 13/10/2018 at 07:44 PM.
)
Desynchronized players and how to deal with them
You probably dealt with desynchronized players before and know how problematic it can be, especially with anti-cheats.
Let's suppose your anti-cheat covers weapons and bans players if the weapon wasn't given by the server. If you were to disarm a desynchronized player, their weapons wouldn't be removed and that is exactly how there would be a false-positive, and that player would be banned for using the weapons.
In general, you can't spawn, set the health/armor through functions, teleport, give/remove weapons, set ammo and so on. That is because those players don't react to certain RPCs sent by the server, however, client messages and game texts do work.
OnPlayerUpdate callback
This callback is still called. That is because those players still send synchronization packets to the server, such as on-foot/vehicle/passenger sync, which is why you can still see them moving/shooting and interacting with the server and possibly other players.
Desynchronized players, however, don't react to certain RPCs as said previously. They can still walk around, send commands to the server, chat, kill people, etc, however, they also notice issues on their end. There are two RPCs sent to stream players/vehicles in and out, and that is simply not gonna work, so, other players are not going to be streamed in, and those which already are, won't be streamed out, but the player will stop receiving their sync packets at such point, even though they won't be removed from the game.
The so called "laggers", however, still react to these updates, but both cases are different. Still, they are also victims of false-positives and are most likely to be desynchronized at some point.
How to detect?
Now comes the interesting part (or probably not).
Since you know they don't react to certain RPCs, there are a few things you could try. I personally like and use this way to keep track of desynchronized players (Keep into account that it is not everything from my system, I just provided a small piece so you can have an idea of what is done, don't think it is a ready system you can simply copy and paste into your script):
How does this work exactly? It simply sets the ammo on slot 0 (fists/brass knuckles), between 1 and 0 (before you ask, the ammo on melees doesn't matter, the weapon is not removed if set to 0), which goes unnoticeable by the players. Since a desynchronized player can't have their ammo set, it is going to be the same over and over again, which is how the trick is done.PHP Code:static
bool:IsPlayerSynced[MAX_PLAYERS char],
PlayerAmmo[MAX_PLAYERS char],
PlayerUpdateTick[MAX_PLAYERS];
public OnPlayerUpdate(playerid)
{
if(gettime() > PlayerUpdateTick[playerid])
{
static current_weapon, current_ammo;
PlayerUpdateTick[playerid] = gettime() + 2;
GetPlayerWeaponData(playerid, 0, current_weapon, current_ammo);
IsPlayerSynced{playerid} = (current_ammo != PlayerAmmo{playerid});
SetPlayerAmmo(playerid, current_weapon, !current_ammo);
PlayerAmmo{playerid} = current_ammo;
}
return 1;
}
//Using IsPlayerSynced{playerid} somewhere...
Why OnPlayerUpdate callback? As said previously, desynchronized players still send synchronization packets to the server, so the callback keeps getting called. Doing the verification there is good, especially since AFK players don't call that callback, so you won't have issues with AFK players being flagged as "desynchronized".
What to do once confirmed?
You may kick the player with a message telling them to rejoin. Why? Because even if you don't have a system where desynchronized players could be potential false-positive victims, it just causes confusion and often false cheater reports from your players, especially due to the fact people that are supposed to be streamed in, aren't going to be shown in the desynchronized player's game, so damaging that person is just not possible in such case.
