KLS, I'm not picking up any vibe. I'm happy to have this discussion, since it raises my hopes that someday some of this work can be shared. I don't want to find myself fixing merge errors anytime anyone touches origin/master.
I think my post of 9/28 has the information you are asking for. If I'm misunderstanding your question let me know. When you ask how I passed the extra info, I have two possible answers.
The first type of additional information would be the quest-id, subroutine name passed into EventNPC (et al.). I added two additional parameters to each call. This is a bit invasive, but I was in a hurry to put together a proof-of-concept demo. (As an aside I used the Cleric epic for this demo). My example above with EVENT_SLAY was taken from attack.cpp, and shows these two parameters added to existing code. When my new code sends an event to the parser, I fill in real values. An example:
Code:
parser->EventNPC(EVENT_DEATH, deathEvent-> killer, deathEvent->init,
"", 0, getQuestID(), getSubroutine());
I'd like to make this clear: The above code comes from new code in a new source file (QTriggers.cpp is the current name). All calls to EventNPC in existing EQEmu code have 0 and "" as the last two parameters. Speaking of deathEvent...
The second type of additional information which you might be asking about is the event-specific data. Existing calls to EventNPC are passed sufficient parameters for the quest code to do its thing. My quest runtime needs more context data. This is not for the parser, but instead for my filtering code. In my 9/28 post I showed a QEventDeath structure being filled in and passed to the QTriggers object. This method keeps all of the data in once nice package, which the receiver is free to use or ignore. I dislike long parameter lists, because I lived through Windows 3. (Oh dear dog, what is the 15th parameter of this function again?)
Threaded Mode
