The FindNearestFriend (used in both cases) can return a dying (but not dead yet) monster because IsAlive is implemented differently for monsters (it returns true if monster is in dying animation).
To reproduce the bug:
Have two monster_barneys nearby
Kill one of them.
Kill the second one while the first one is still in dying animation.
The first barney will play a death sound two times because at the time when the second barney takes damage, it makes the first barney change his schedule to slIdleStopShooting, and then he gets back to the dying schedule since he's in the dead state, playing the death sound again via TASK_SOUND_DIE.
Same thing potentially can happen if the monster that is chosen to answer the question is dying at the moment of question being asked, but it's harder to reproduce.
Some talkmonster code leads to the monster changing their schedule.
https://github.com/FWGS/hlsdk-portable/blob/17b34aa42b2060706deb20aa82df0ea2766e1b18/dlls/talkmonster.cpp#L1154-L1161
https://github.com/FWGS/hlsdk-portable/blob/17b34aa42b2060706deb20aa82df0ea2766e1b18/dlls/talkmonster.cpp#L1140-L1145
The
FindNearestFriend(used in both cases) can return a dying (but not dead yet) monster becauseIsAliveis implemented differently for monsters (it returns true if monster is in dying animation).To reproduce the bug:
The first barney will play a death sound two times because at the time when the second barney takes damage, it makes the first barney change his schedule to
slIdleStopShooting, and then he gets back to the dying schedule since he's in the dead state, playing the death sound again viaTASK_SOUND_DIE. Same thing potentially can happen if the monster that is chosen to answer the question is dying at the moment of question being asked, but it's harder to reproduce.