Fix #472 setElementHealth in onClientPedDamage can cause crash

[FileEX]

Fix #472

This is my next attempt to fix this issue.

• Fixed the crash.
• Fixed the bug where the ped would still die.

The hook in CRenderer::RenderEverythingBarRoads is necessary because when an entity is frequently re-created, a crash occurs due to m_pRwObject being nullptr. This happens, for example, when shooting a ped with a minigun. In my opinion, this should not cause any synchronization or desynchronization issues, but this will become clear during testing if this PR gets merged.

function handleDamage(attacker,weapon,bodypart,loss)
    setElementHealth(source,1)
end
addEventHandler("onClientPedDamage",root,handleDamage)

I believe this is my last attempt to resolve this issue, as I have run out of ideas for fixing it.

[botder]

I did similiar crash fixes before, but if you're looking for a cleaner solution, using a queue for entity re-creation (caused for example by changing model or respawning) and processing it after the game update, should fix all of these crashes.

[FileEX]

I did similiar crash fixes before, but if you're looking for a cleaner solution, using a queue for entity re-creation (caused for example by changing model or respawning) and processing it after the game update, should fix all of these crashes.

What do you mean by processing it after the game update? These crashes are usually caused by the entity pointer becoming invalid during code execution, so it still needs to be replaced with the correct one using hooks, right?

[botder]

I did similiar crash fixes before, but if you're looking for a cleaner solution, using a queue for entity re-creation (caused for example by changing model or respawning) and processing it after the game update, should fix all of these crashes.

What do you mean by processing it after the game update? These crashes are usually caused by the entity pointer becoming invalid during code execution, so it still needs to be replaced with the correct one using hooks, right?

Usually these crashes are caused by a hook that triggers an event, which then calls to functions that cause the invalidation. My suggestion is to delay whatever actions these "invalidating" functions do after the game update, where no chunk of code holds a pointer to an invalidated entity.

[FileEX]

I did similiar crash fixes before, but if you're looking for a cleaner solution, using a queue for entity re-creation (caused for example by changing model or respawning) and processing it after the game update, should fix all of these crashes.

What do you mean by processing it after the game update? These crashes are usually caused by the entity pointer becoming invalid during code execution, so it still needs to be replaced with the correct one using hooks, right?

Usually these crashes are caused by a hook that triggers an event, which then calls to functions that cause the invalidation. My suggestion is to delay whatever actions these "invalidating" functions do after the game update, where no chunk of code holds a pointer to an invalidated entity.

I understand what you mean now, but I’m not entirely sure how this could be achieved. The event needs to be triggered at the appropriate moment, as it is now, to allow it to be canceled correctly. So, how could this be done while still preserving the ability to cancel the event? Additionally, how would it even be possible to delay the code executed in a event function?

[botder]

I understand what you mean now, but I’m not entirely sure how this could be achieved. The event needs to be triggered at the appropriate moment, as it is now, to allow it to be canceled correctly. So, how could this be done while still preserving the ability to cancel the event? Additionally, how would it even be possible to delay the code executed in a event function?

I didn't talk about the event callback function, but whatever function the user decides to call (setElementHealth that respawns dead peds), that cause this effect: entity invalidation. And I don't mean we should delay setting the health, but rather the ped recreation.

[FileEX]

I understand what you mean now, but I’m not entirely sure how this could be achieved. The event needs to be triggered at the appropriate moment, as it is now, to allow it to be canceled correctly. So, how could this be done while still preserving the ability to cancel the event? Additionally, how would it even be possible to delay the code executed in a event function?

I didn't talk about the event callback function, but whatever function the user decides to call (setElementHealth that respawns dead peds), that cause this effect: entity invalidation. And I don't mean we should delay setting the health, but rather the ped recreation.

Done

[botder]

Did you test the code/crash?

[FileEX]

Did you test the code/crash?

Yeah, multiple times even with minigun.

[botder]

If this works as intended, then we should use this approach for vehicles and other things too.

[FileEX]

If this works as intended, then we should use this approach for vehicles and other things too.

You're right, but since this PR also touches the ped damage logic, it would be better to do it in a separate PR soon, so that if a revert is needed due to potential synchronization issues, it won't undo other changes.