Odd bug with Damage(from, damage, spell_id, attack_skill, avoidable= true, buffslot=

[trevius]

Yeah, that is just where nexthpevent gets set to -1 if no further HP events are set when the EVENT_HP gets parsed there. It doesn't make sense why that would treat the perl Damage function different than normal damage.

[Secrets]

Originally Posted by trevius

Yeah, that is just where nexthpevent gets set to -1 if no further HP events are set when the EVENT_HP gets parsed there. It doesn't make sense why that would treat the perl Damage function different than normal damage.

Every time an HP Packet gets sent, it sets it to -1 if it is less than the amount of HP on the mob. You could try forcing an HP update right after damaging it. If what is happening is what I think is happening, it's parsing EVENT_HP twice; once when you damage the NPC, another when the tick gets sent to the client. I think so anyway; didn't look into it more than that.

Resolving it manually or sending an HP update after doing the damage should work though.

[trevius]

In order for what you are describing to happen, both the regular HP update and the one caused by Damage() would have to be getting run at the exact same time. I thought about that possibility, but I highly doubt that would ever happen and certainly not with a 100% reproducibility.

From how I am reading the code, it looks like it checks if the current HP ratio is less than the nexthpevent and if so, it then parses the EVENT_HP, and then if nexthpevent wasn't changed (no nexthpevent was set in the script when it was parsed), it then (and only then) sets it to -1. Even if that were to happen, I have no idea how it would still parse an EVENT_HP with a nexthpevent of -1.

There has to be something I am missing here...

[Derision]

This is what appears to be happening in Trevius' example:

If you call Damage from Perl, when:

	parse->Event(EVENT_HP, GetNPCTypeID(), 0, CastToNPC(), NULL);

is called from void Mob::CreateHPPacket(EQApplicationPacket* app), it gets to this point:

void PerlembParser::EventCommon(QuestEventID event, int32 objid, const char * data, NPC* npcmob, ItemInst* iteminst, Mob* mob, int32 extradata)
{
        if(!perl)
                return;

        if(event >= _LargestEventID)
                return;

        if(perl->InUse()) {

and since 'Perl is in use', executing the EVENT_SAY, the EVENT_HP is queued until the EVENT_SAY completes, therefore SetNextHPEvent is also not yet executed which means
lasthpevent == nexthpevent in the test in CreateHPPacket, leading to SetNextHPEvent(-1) being called.

As I say, the EVENT_HP is queued and should execute (along with any other queued EVENTs) once the EVENT_SAY in this example has finished.

[trevius]

Thanks Derision! I think that makes the most sense of anything I have seen yet. I was thinking EVENT_HP could probably have been coded better anyway, so maybe I will think on it a bit and see if I can figure out a better solution. I thought it seemed odd that the code for it would rely on a value that was supposed to be changed by perl during the function. If you are correct, probably other servers are getting bugged events that use EVENT_HP sometimes and maybe not realizing this is the cause. We use it in quite a few events on Storm Haven and some of those are out buggiest events. It would be awesome if a rewrite of how EVENT_HP is handled could resolve the random events bugs we have seen.

[trevius]

Thanks to Derision finding the cause of the issue, I was able to get it fixed and it is in Rev1715 on the SVN now