Pet not protectimg me unless I get hit.

[Slingshot]

Not sure if this was mentioned. My pet won't attack my attacker unless the attacker actually does damage to me.

Example: Low level skelly agros me in butcherblock. It has a tough time hitting me and misses a lot. My pet just sits there staring at it. It finally get's lucky and hits me for some damage. Then my pet kills it.

I'm a beastlord so I'm not sure what would happen if I had a damage absorb shield like enchanter rune. I would think my pet wouldn't attack until my shield was gone considering enchanter pets aren't controllable.

I think this also happens even if I'm the attacker. My pet wouldn't attack the mob I was in combat with until it actually did damage to me.

I think my pet is supposed to attack whoever takes a swing at me whether they hit me or not.

I'm Running Rev 189.

[joligario]

Yes, I agree with this. With the changes to how you can queue up targets for your pet, we lost the ability for the pet to queue up targets on whoever has been attacking you prior to the pet being idle. Pet should queue up targets on hit/miss and spell land/resist.

[MNWatchdog]

Ya, this does need to be fixed. Having to explicitly send a pet on mobs that are already attacking you but havent caused any damage is annoying.

[trevius]

I think that is one more reason to bring back player hate lists. Removing them solves a few minor issues, but makes certain other things considerably harder to code properly. All we need to do is allow player hate lists again, but add WipeHateList() to a few places like FD, Escape, and Fading Memories (and a few others).

If someone knows all cases that WipeHateList() would be required if we restore player hate lists, I think it will be considerably easy to get them back to how they were before and still have all hate list issues fixed. Or we could always restore it now and just fix the minor issues it causes later when they are seen.

I think the IsEngaged() check for players is just too valuable to not have it available to us to use. Heck, if possible, I would be happy if we could just make a second hate list that was for clients only. That would resolve both issues at the same time, but I don't really know what would be involved in making that happen. But, if we did, we could just have a new command like ClientEngaged() or something.

[Slingshot]

These are the spells that memory blur.

http://everquest.allakhazam.com/db/s...&action=search

If you take out the ones below 65 (I think eqemu only goes up to level 65) and the non client spells that should cover all the spells that have a % chance to wipe the hate list. Other than that there's just feign death as far as I know.

Not sure if this helps or not, but it's a place to start.

[Slingshot]

If IsEngaged() does what it sounds like I don't think that would be right. On live my pet doesn't attack what isn't also attacking me even if I'm engaged in combat with it.

As an example if I'm assisting the main tank and the mob never takes a swing at me my pet won't attack unless I tell it to. When I played an enchanter at low level I would nuke just to get the mob to take a swing at me so my pet would help out, then I'd back off.

Basicly I would need a hate list and my pet would have to monitor that hate list. Taking a swing at me would generate hate and my pet would respond. Things that memblur and feign death would have to wipe that hatelist.

Wish I knew C++ so I could help out. I wouldn't even know what files of the source I would need to look in to find this part of the code.

[KLS]

Player hate lists don't seem to have anything to do with this problem but I'm not against them coming back so long as we cover the bases where they should be wiped. Before they never were wiped ever and it kinda caused issues.

I haven't gotten a chance to review the code that causes this but I bet the person who implemented it didn't follow http://eqemulator.net/forums/showthread.php?t=26629. >=(

[So_1337]

I keep seeing it misspelled during these discussions. As we all know, it's properly spelled "whipe".

<3 KLS

[Angelox]

Originally Posted by So_1337

I keep seeing it misspelled during these discussions. As we all know, it's properly spelled "whipe".

<3 KLS

You mean 'wipe' is spelled 'whipe'?

[So_1337]

==10/17/2008
KLS: Tweaks to /pet attack
KLS: Renamed WhipeHateList to WipeHateList so I never have to view that spelling monster ever again.

Sorry, couldn't resist.

And now that I'm here, I guess I'd better contribute in some fashion...

The client hatelist was what caused the whole zone-wide training problem by not being cleared on things like feign death and Call of the Hero. It was done away with entirely, though it probably could've stayed so long as it was cleared properly. However, since then, quite a few things that depended upon it (like the NPC fleeing code) have been tweaked to work without it. If that is indeed the reason that pets are acting screwy, I'm sure it can be remedied by a similar fix.

And yes, there definitely needs to be more reading of that sticky =/ I try to give good feedback whenever I can get a set of binaries and try things out, but it's kind of a pain when we wind up breaking one thing while fixing another. I know that was Sony's policy, but we don't have to follow that one if we don't want to =P

[Slingshot]

I'm not a programmer or anything but couldn't we just execute whatever makes the pet attack when we are hit even if we are missed?

If we take damage it works fine. When we don't the pet just sits there.

[KLS]

Haha, but that's not what the issue being described is sir! I just couldn't pass up an opportunity to remind people was all =p

The pets should have their own hate lists that don't rely on their masters, and it actually sounds like that might be working and in this case the simplest solution is probably the right one:

I'm not a programmer or anything but couldn't we just execute whatever makes the pet attack when we are hit even if we are missed?

If we take damage it works fine. When we don't the pet just sits there.

[Loccochris]

Pretty sure I know why this is happening. Decided since PEQ was down for 2 days I might as well dab with the code a little. In the following section of code from zone/attack.cpp

Inside Mob:CommonDamage method

if(damage > 0) {
		//if there is some damage being done and theres an attacker involved
		if(attacker) {
			if(spell_id == SPELL_HARM_TOUCH2 && attacker->IsClient() && attacker->CastToClient()->CheckAAEffect(aaEffectLeechTouch)){
				int healed = damage;
				healed = attacker->GetActSpellHealing(spell_id, healed);
				attacker->HealDamage(healed);
				entity_list.MessageClose(this, true, 300, MT_Emote, "%s beams a smile at %s", attacker->GetCleanName(), this->GetCleanName() );
				attacker->CastToClient()->DisableAAEffect(aaEffectLeechTouch);
			}

			// if spell is lifetap add hp to the caster
			if (spell_id != SPELL_UNKNOWN && IsLifetapSpell( spell_id )) {
				int healed = damage;
				healed = attacker->GetActSpellHealing(spell_id, healed);				
				mlog(COMBAT__DAMAGE, "Applying lifetap heal of %d to %s", healed, attacker->GetName());
				attacker->HealDamage(healed);
				
				//we used to do a message to the client, but its gone now.
				// emote goes with every one ... even npcs
				entity_list.MessageClose(this, true, 300, MT_Emote, "%s beams a smile at %s", attacker->GetCleanName(), this->GetCleanName() );
			}
			
			// if we got a pet, thats not already fighting something send it into battle
			Mob *pet = GetPet();
			if (pet && !pet->IsFamiliar() && !pet->SpecAttacks[IMMUNE_AGGRO] && !pet->IsEngaged() && attacker != this) 
			{
				mlog(PETS__AGGRO, "Sending pet %s into battle due to attack.", pet->GetName());
				pet->AddToHateList(attacker, 1);
				pet->SetTarget(attacker);
				Message_StringID(10, PET_ATTACKING, pet->GetCleanName(), attacker->GetCleanName());
			}

You will notice that the last part dealing with pet aggro is nested inside this if (damage > 0) if statement. Now the weird thing is even though this is suppose to be when a mob takes damage the client method makes a call to this. Essentially this method is being used for both when a player is hit and a mob is hit.

Moving the pet code outside above this if statement should solve the issue as I am pretty sure this method gets called regardless if its a miss or hit. If it doesn't fully fix it it will at least make the pet respond to more things then you actually taking a hit and we just have to trace farther backwards. I haven't had a chance to fully trace the code, frankly some of the commenting on these methods are weird or missing.

I havn't actually set up a server yet to test it so perhaps one of you can.