Fix setPedOnFire(ped, false) doesn't cancel TASK_SIMPLE_PLAYER_ON_FIRE

[FileEX]

Fixed #3249

[TheNormalnij]

Why do you want to extend the setPedOnFire function instead of adding the new function removePedTask?
A new behavior is not intuitive. Your setPedOnFire(ped, false) does something with ped tasks ever if the ped has no fire effect.

Maybe im wrong here.
Does isElementOnFire return true before you call setPedOnFire(ped, false) when a ped has no fire effect?
Does the player lose health when TASK_SIMPLE_PLAYER_ON_FIRE is active?

[FileEX]

Why do you want to extend the setPedOnFire function instead of adding the new function removePedTask?

We already have the killPedTask function.

A new behavior is not intuitive. Your setPedOnFire(ped, false) does something with ped tasks ever if the ped has no fire effect.

Yeah, it's a intentional because before using setPedOnFire, you can use extinguishFire, which means the player won't be on fire anymore, but the PLAYER_ON_FIRE task will remain active. That's why I changed the approach to return false if there's no fire.

Does isElementOnFire return true before you call setPedOnFire(ped, false) when a ped has no fire effect?

No

Does the player lose health when TASK_SIMPLE_PLAYER_ON_FIRE is active?

No, but as mentioned in the issue, it causes some problems with aiming.

I see that my proposed simple solution, which involves interrupting the PLAYER_ON_FIRE task after setting setPedOnFire to false (which is logical because if we don't want fire, we also don't want the task associated with it), is not well-received. I don't see the point in calling two separate functions:

setPedOnFire(ped, false) -- to extinguish the fire
killPedTask(ped, "secondary") -- to remove the PLAYER_ON_FIRE task

In my opinion, this approach doesn't make sense, because this action should be executed along with extinguishing the fire, not separately and manually by the scripter.

[TheNormalnij]

Yeah, it's a intentional because before using setPedOnFire, you can use extinguishFire, which means the player won't be on fire anymore, but the PLAYER_ON_FIRE task will remain active. That's why I changed the approach to return false if there's no fire.

This is a problem. extinguishFire should disable the task or don't touch peds. A ped should not be able to get this bugged state when the ped isn't on fire but has active PLAYER_ON_FIRE task

[FileEX]

Yeah, it's a intentional because before using setPedOnFire, you can use extinguishFire, which means the player won't be on fire anymore, but the PLAYER_ON_FIRE task will remain active. That's why I changed the approach to return false if there's no fire.

This is a problem. extinguishFire should disable the task or don't touch peds. A ped should not be able to get this bugged state when the ped isn't on fire but has active PLAYER_ON_FIRE task

Done. I used a hook on the CFire::Extinguish function so that it aborts the task when a ped is affected. I think this is the best solution.