it has to do with the perl quest variables that are set for quests; i don't think it happens in qst format, though there might be similarities.
In short : variables ($text, $name, $charid,...) are set accordingly for an event, but not reset. e.g. you might be processing an EVENT_DEATH, but still get $text pertaining to a previous say to this npc (or event another one), by the same or other player.
This discrepancy is shared by all events (it's perl related), and may or may not be harmful (it IS harmful for default.pl quest, or if you are using global variables)
example :
A says 'hail may name is A' to NPC, then leaves . B comes around, and gives item #1001. $text is 'hail my name is A. B leaves, and C comes around. $text, $itemxxxx still set. C has a global var enabled "killed_brother" to "true" on this NPC. C speaks (overrides $text), and NPC reacts attacking C as the quest was designed for. Then D comes around, having never killed anyone. D says 'Hail', and immediatly gets attacked, because "killed_brother" was still set to true.
the guts :
the embparser stores quests in packages, one for each NPC (qst1234), and one (qstdefault) for quests that don't. When an event is triggered, variables are set in the package. Then an other event, variables are set again. But only the variables that are valid/known in the time of the event are set. Different events - differents variables. Thus some variables keep the values set in event #1.
i can't think of any fix at the moment, just wanted to get a feedback. This is really a pain somewhere imho :evil: , but some might think it's just usable undocumented feature
perl quest variables mess
Threaded Mode
