IS4Code / YSF

YSF Server Functions
Other
98 stars 34 forks source link

DeathProtection #129

Closed NexiusTailer closed 1 year ago

NexiusTailer commented 3 years ago

Death protection have its main code commented: https://github.com/IllidanS4/YSF/blob/master/src/RPCs.cpp#L121-L128

It would be great to test it and make it work again.

UPD: I think the main problem was this piece of the check:

reasonid != WEAPON_ROCKETLAUNCHER && reasonid != WEAPON_HEATSEEKER

When there is no need to make that exclusion, but at the same time it needs to exclude "WEAPON_FLAMETHROWER"

So the final variant would be like that:

if (pKiller->syncData.byteWeapon != reasonid && pKiller->byteState != PLAYER_STATE_DRIVER)
{
    if (reasonid <= 46 && reasonid != WEAPON_FLAMETHROWER)
    {
        // logprintf("onplayerdeath error 1, synced weapon: %d, reason: %d", pKiller->syncData.byteWeapon, reasonid);
        return;
    }
}

UPD 2: Also, we can make some reliable improvements according to old YSF versions:

if (pKiller->syncData.byteWeapon != reasonid && pKiller->byteState != PLAYER_STATE_DRIVER)
{
    if (reasonid == 49 || reasonid == 50 || reasonid <= 46 && reasonid != WEAPON_FLAMETHROWER)
    {
        // logprintf("onplayerdeath error 1, synced weapon: %d, reason: %d", pKiller->syncData.byteWeapon, reasonid);
        return;
    }
}
IS4Code commented 2 years ago

pPlayer->syncData.byteWeapon is useless when the player is in a vehicle or a passenger. pPlayer->vehicleSyncData.bytePlayerWeapon and pPlayer->passengerSyncData.bytePlayerWeapon are to be used in that case.

Still there could be cases where it might prevent a legit kill, such as destroying someone's vehicle, causing it to explode, might report the weapon as the reasonid but the killer has enough time to hide it. Feel free to create a pull request from these changes, but some thorough testing will be needed.

NexiusTailer commented 2 years ago

Still there could be cases where it might prevent a legit kill, such as destroying someone's vehicle, causing it to explode, might report the weapon as the reasonid but the killer has enough time to hide it. Feel free to create a pull request from these changes, but some thorough testing will be needed.

Seems I really missed that moment, thanks for the note. But this can be changed to the condition which checks if a killer has this weapon at all (from the same source like GetPlayerWeaponData obtains from), not just armed now. If the player who was sent as a killer does not even have such weapon, killerid and reason for this death can be reset to unknown (killerid = 65535, reason = 255).

UPD: Resetting killerid and reason instead of block the event is more appropriate in general as well: we don't allow other players to be harmed by compromising their IDs as killers in any suspicious cases, but at the same time the player will actually die (both in his game locally and on the server), which will prevent situations with ignoring the real death incident and further possible problems based on this inside pawn scripts. Blocking the callback would be still relevant in cases if player is already dead or invalid (or other similar reasons where rewriting data won't solve the real problem).

UPD 2: Sorry, but I am not able to make a pull request at the moment.