citizenfx
feat(onesync/events): add ragdoll request event
Since some cheats have now an option to ragdoll any player server owners should be able to cancel that event.
My knowledge is limited, and I don't know how to figure out the event data. I put a placeholder so that someone with that knowledge should be able to replace that.
Do you have reproduction for actually causing other players to ragdoll?
Hi @AvarianKnight, I didn't figure out how to do it with natives, but I uploaded a clip so you can see https://streamable.com/usr93i
Hi @AvarianKnight, I didn't figure out how to do it with natives, but I uploaded a clip so you can see https://streamable.com/usr93i
It isn't a client-side effect? Did u confirmed if the target players really takes a ragdoll?
It does affect the target, because in that clip I'm the target and I asked the cheater to take the clip!
This event contains only one value: the network id of the target entity. It can be parsed in this manner:
void Parse(rl::MessageBuffer& buffer)
{
entityNetId = buffer.Read<uint16_t>(13);
}
However, given the recent feedback on PRs concerning game events, I believe the recommended approach here would be to use a convar to disable the routing of these events, similar to how it's done for the RequestControlEvent and NetworkPlaySoundEvent. Optionally, offer a mode that blocks the events only if the target is a player, and another one blocking for both players and NPCs.
Do you have reproduction for actually causing other players to ragdoll?
I can confirm this, I can give you a replay of a stream where the streamer is ragdoll many times.
Ok, I added the correct parameter. Can someone give me feedback if this method is ok? Or do I have to make this work like @william-des said?
While this event definitely should be blocked for entities controlled by other players, wouldn't this (or the more "appropriate" approach with disabling routing per ConVar) also block ragdoll-requests for networked NPCs owned by the requesting client? If this is the case here, this would be a "big" consideration to make, as this event is commonly used.
Maybe a more "reasonable" approach would be to actually include checks for entity ownership/integrate this event in the logic flow for filtering request control events ("sv_filterRequestControl"), as this should only be blocked for player-peds or peds owned by other players.
