You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
There are a couple of problems in omp server behavior which produce false detections for the server-side anticheat and actually can be (and should be) fixed on the side of omp server itself.
The first issue appears when the player was in spectating mode and leaves from it, the server instantly sets him PLAYER_STATE_NONE which must not be used anywhere except as a bare "just-after-connection" state (when no any other state were set before), because this is the only documented behavior in samp server for this state. Setting it between two other states while playing leads to ruining anticheat logic if it tries to make sane checks (like checks for skipping PLAYER_STATE_SPAWNED, when cheaters send onfoot sync just after connection). The place where this kludge is located is probably here.
The second issue was found recently, but seems it persist for a long time too, it's when the server gives a player any non-bullet weapon (for example, brass knuckles or any melee like chainsaw, flowers etc) with ammo set to 0. After player received such weapon in hands, he can switch his current weapon to any other slot and then switch back to new weapon to hold it again. Just after these actions GetPlayerWeapon, GetPlayerAmmo and other functions will return 0 as server cleared the whole slot from both weapon and ammo, probably because ammo was already 0 so it considers the weapon also disappeared and thus can be cleared from data, but it's not.
To reproduce the first issue
Toggle a player spectating mode, set some other player for him to spec on
Toggle it off by the server or wait until the one he's spectating on will left the game, so our player will be spawned
Log OnPlayerStateChange, it usually show that his state was changed to 0 and only then to the real one after it
To reproduce the second issue
Give player some non-bullet weapon with ammo 0:
GivePlayerWeapon(playerid, 9, 0);// Chainsaw
Let him switch his holding weapon back and forth
Obtain values from GetPlayerWeapon and GetPlayerAmmo
Release version
Latest v1.3.1.2748, but both issues also exist on older builds
The text was updated successfully, but these errors were encountered:
Describe the bug
There are a couple of problems in omp server behavior which produce false detections for the server-side anticheat and actually can be (and should be) fixed on the side of omp server itself.
The first issue appears when the player was in spectating mode and leaves from it, the server instantly sets him
PLAYER_STATE_NONE
which must not be used anywhere except as a bare "just-after-connection" state (when no any other state were set before), because this is the only documented behavior in samp server for this state. Setting it between two other states while playing leads to ruining anticheat logic if it tries to make sane checks (like checks for skippingPLAYER_STATE_SPAWNED
, when cheaters send onfoot sync just after connection). The place where this kludge is located is probably here.The second issue was found recently, but seems it persist for a long time too, it's when the server gives a player any non-bullet weapon (for example, brass knuckles or any melee like chainsaw, flowers etc) with ammo set to 0. After player received such weapon in hands, he can switch his current weapon to any other slot and then switch back to new weapon to hold it again. Just after these actions
GetPlayerWeapon
,GetPlayerAmmo
and other functions will return 0 as server cleared the whole slot from both weapon and ammo, probably because ammo was already 0 so it considers the weapon also disappeared and thus can be cleared from data, but it's not.To reproduce the first issue
OnPlayerStateChange
, it usually show that his state was changed to 0 and only then to the real one after itTo reproduce the second issue
GetPlayerWeapon
andGetPlayerAmmo
Release version
Latest v1.3.1.2748, but both issues also exist on older builds
The text was updated successfully, but these errors were encountered: