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

[Kayen]

Well I recently discovered why randomly scripts would break for months that seemed to make no sense ever.

We have a few scripts that utilize the damage function.
Damage(from, damage, spell_id, attack_skill, avoidable= true, buffslot= -1, iBuffTic= false)

For some reason however, when you do this function verse an NPC who has an HP Event set, it sets the HP Event to -1. Thus breaking the scripts.

Doesn't matter if a client casts it on an NPC or the NPC casts it on them selves, or NPC cast it on different NPC, result is the same $hpevent is set to -1.

Anyone have any insight on fixing this? Cause the function itself is darn useful otherwise.

[trevius]

This issue is very odd indeed. After reviewing the source code for the perl Damage function as well as the Damage and CommonDamage functions in attack.cpp and seeing where the HP Events get parsed as well, I cannot figure out how this issue is occurring. I don't see why the perl Damage command would be any different than any other type of damage, and I really don't see what it would have to do with setting the hp event to -1.

Here is an example script that reproduces the problem 100%:

my $nexthp = 99;

sub EVENT_SPAWN {

quest::setnexthpevent($nexthp);

}


sub EVENT_HP {
my $HP_RATIO_CHK = int($npc->GetHPRatio());
quest::gmsay("Script Debug - HPEvent $hpevent, HPRatio $HP_RATIO_CHK");

if ($hpevent == -1)
{
quest::setnexthpevent($HP_RATIO_CHK);
$nexthp = $HP_RATIO_CHK;
quest::gmsay("Script Debug - Correcting Next HP Event to $HP_RATIO_CHK");
}

# Set a new HP Event to occur with every 1% of NPC HP loss
if($hpevent == $nexthp) {

$nexthp = $hpevent - 1;
quest::gmsay("Script Debug - HPEvent $hpevent, HPRatio $HP_RATIO_CHK, NextHPEvent $nexthp");
if ($hpevent == -1)
{
quest::setnexthpevent($HP_RATIO_CHK);
}
else
{
quest::setnexthpevent($nexthp);
}
}

}


sub EVENT_AGGRO_SAY {

if ($status > 80) {

if($text =~ /Damage/i)
{
$npc->Damage($client, 1000, 0, 28, 0);
quest::say("Damaging now");
}

}

}

sub EVENT_SAY {

if ($status > 80) {

if($text =~ /Damage/i)
{
$npc->Damage($client, 1000, 0, 28, 0);
quest::say("Damaging now");
}

}

}

Just put that on an NPC that has 100k HPs, and say "damage" to it a few times. You can attack normally or even #damage it and the HP Events will function as they should, but as soon as you say "damage" to it, it will set $hpevent to -1.

I set this example script to automatically recover from $hpevent getting set to -1, but that isn't a real solution to the problem. This is just puzzling the heck out of me. As far as I can tell, the only times that $hpevent are set to -1 is when the NPC is first spawned and when the last quest::setnexthpevent() in the script has been used.

[Caryatis]

possibly from this?

line 849 from mob.cpp

// hp event
if ( IsNPC() && ( GetNextHPEvent() > 0 ) ) {
if ( ds->hp < GetNextHPEvent() ) {
int lasthpevent = nexthpevent;
parse->Event(EVENT_HP, GetNPCTypeID(), 0, CastToNPC(), NULL);
if ( lasthpevent == nexthpevent ) {
SetNextHPEvent(-1);
}
}
}

[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]

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 :)