Aggro LOS fix (maybe..?)

[greggg230]

I've just started playing around with the emulator a few days ago, and the only glaring bug I've noticed is that NPCs don't assist one another properly. No NPC will assist a MOB unless they have LOS on you--this is easily exploitable, obviously, and makes pulling mobs almost trivial.

I looked around in the code, and the solution seemed pretty obvious.

In aggro.cpp in the function EntityList::AIYellForHelp , a block of code checks for LOS in the following way:

if(useprimfaction || sender->GetReverseFactionCon(mob) <= FACTION_AMIABLE )
{
//attacking someone on same faction, or a friend
//Father Nitwit: make sure we can see them.
if(mob->CheckLosFN(attacker)) {
#if (EQDEBUG>=5)
LogFile->write(EQEMuLog::Debug, "AIYellForHelp(\"%s\",\"%s\") %s attacking %s Dist %f Z %f",
sender->GetName(), attacker->GetName(), mob->GetName(), attacker->GetName(), mob->DistNoRoot(*sender), fabs(sender->GetZ()+mob->GetZ()));
#endif
mob->AddToHateList(attacker, 1, 0, false);
}
}

The change is really easy. Just change if(mob->CheckLosFN(attacker)) to if(mob->CheckLosFN(sender)). That way, MOBs will assist each other whether or not they have LOS, but still with the restriction that they have LOS with either the MOB you aggroed or a MOB assisting that MOB.

I've tested it out a decent amount and things seem to be working fine. The only reason I can imagine the code would be like this intentionally is that the LOS function is expensive, but changing it this way shouldn't normally create a ton more work for the processor; my server showed no signs of slowdown or stress as a result in admittedly limited testing.

[John Adams]

I'd like to see this on a relatively populated server where more than one player/group is aggroing stuff within the same range. That may be why it was tied to the aggroing party (hackhackhack).

Though I agree, I think this fix is nice and more in tune with how things should be. Nice work. TGC, anyone? ;)

[cavedude]

Aye, I'll merge it on TGC next reboot ;)

[eq4me]

I always thought that LOS had something to do with aggro range. For example you could pull the single mob near the ladder from the Ghoul Suppliers room in LGuk when you aggroed him as soon as you saw him while climbing up said ladder. Climb to high and the whole room would come. But maybe something has changed since then.

[Congdar]

I'm not sure if this is a good thing. If you want to link mobs, you should use the perl way to do it instead of a world wide change like this.

[greggg230]

I'm not sure if this is a good thing. If you want to link mobs, you should use the perl way to do it instead of a world wide change like this.

I'm not sure I understand. This should be a world-wide change, as this is how MOBs should always act.

This has nothing to do with MOBs being linked in the sense that was implemented in Velious and later.

[Congdar]

I said i wasn't sure. It seemed to me that assist is already working.

[Derision]

In testing this I would concentrate in dungeons, if you haven't already done this, bearing in mind there
is no pathing for aggroed mobs.

E.g. If I pull a mob and there is a mob around the corner that can't see me, but is within assist range
of the mob I am pulling, with this change, the unseen mob will run straight at me through the walls.

Should this second mob itself yell for help while it is 'running through the walls', possibly through
another room filled with mobs, there may be a chance of a chain-aggro event which pulls a load of mobs
through the walls.

I've not tested this or studied the YellForHelp code, but it is just a thought I had while wondering why
things are coded the way they are. :)

[greggg230]

In testing this I would concentrate in dungeons, if you haven't already done this, bearing in mind there
is no pathing for aggroed mobs.

E.g. If I pull a mob and there is a mob around the corner that can't see me, but is within assist range
of the mob I am pulling, with this change, the unseen mob will run straight at me through the walls.

Should this second mob itself yell for help while it is 'running through the walls', possibly through
another room filled with mobs, there may be a chance of a chain-aggro event which pulls a load of mobs
through the walls.

I've not tested this or studied the YellForHelp code, but it is just a thought I had while wondering why
things are coded the way they are. :)

That most likely would happen, but the aggroed mob would have to run through the wall and go into line of sight with a mob in another room or something, which seems like it would be pretty rare and pullers could adapt to it in those situations in which it does apply. Obviously, it'd be best to have pathing for aggroed MOBs and proper aggro code, but I think one out of two ain't bad right now. hehe

[Derision]

That most likely would happen, but the aggroed mob would have to run through the wall and go into line of sight with a mob in another room or something, which seems like it would be pretty rare and pullers could adapt to it in those situations in which it does apply. Obviously, it'd be best to have pathing for aggroed MOBs and proper aggro code, but I think one out of two ain't bad right now. hehe

Since reading your initial post I was pondering the possibility of another way of doing things:

If the mob has LOS to the 'sender' but not the player, it runs to the current location of the 'sender'. At that point, it checks for LOS to the player. If it has it, it runs straight at him, if not, it checks for LOS to the 'sender' again and runs to that point. Rinse and repeat until it has no LOS to either, in which case it wipes it's hate list and goes back to where it was.

Not 'Live Like', but maybe a sort of middle-ground.

[ChaosSlayer]

as far as i can say up untill today the AGRO and Assist worked 100% as on live - you pull 1 mob - his friend around the conner will agro, as well as agro any other friends in range.

the only problem was with mobs running through wall which cuased them to potentialy pass additional areas with other mobs who never would have been agroed on live.
in other words there is no problem with assist - only with mobs ability to ignore walls.

[greggg230]

Has anyone tried this out? If so, how's it working? I've been busy with work the past few days so haven't had a lot of time for EQEmu.

[cavedude]

This one is up on PEQ with this reboot. I'll post the reaction (if any)

[cavedude]

This looks to be a good fix, and makes things more Live Like. It does make some encounters more difficult due to other broken systems, but that is no fault of this code. Moving to submissions.

[trevius]

I added in this code as well. It seems to work great. I had to reduce the agro range of NPCs in some zones to keep some overwhelming pulls from happening now that the LoS bug to pull by hiding around a corner doesn't work. That isn't an issue with this code though, just some adjustments that people might want to consider after adding this in.

[BWStripes]

In testing this I would concentrate in dungeons, if you haven't already done this, bearing in mind there is no pathing for aggroed mobs.

E.g. If I pull a mob and there is a mob around the corner that can't see me, but is within assist range of the mob I am pulling, with this change, the unseen mob will run straight at me through the walls.

Should this second mob itself yell for help while it is 'running through the walls', possibly through another room filled with mobs, there may be a chance of a chain-aggro event which pulls a load of mobs through the walls.

I have to say I love this change, brings back in some skill required to pull properly. At least enchanters will have something to do other than VQ/VoQ.

I will comment it does behave as Derision speculated, on TGC, particularly in a lot of new style zones (Luclin+). Some walls and doors are not treated as non-LoS. Vex Thal has a few nasty spots now. We've had 9 pull and 12 chains with what should have been straightforward pulls. Other zones like Griegs were nasty anyway, but this makes it almost unplayable in places.

[Derision]

Some walls and doors are not treated as non-LoS.

Doors are not included in the .map files and hence not accounted for in LOS.

Including them in LOS calculations is doable. Either by taking them into account during .map generation by azone (and tagging the polygons with the door id), or by handling them separately in the zone process.

The former would require a new .map structure and regenerating all the maps. Either way, if the LOS code hit a door, a check would need to be made if the door was open or not, which is easy enough.

How easy this would be also depends on the accuracy of the information in the doors table, in particular the size and angle of the door.

I'll think about it :)

[cavedude]

How easy this would be also depends on the accuracy of the information in the doors table, in particular the size and angle of the door.


Every door in the PEQ database was parsed from Live, so they are as accurate as we can get them. We never add doors manually for this very reason, though I doubt manually added doors could cause that big of an issue, except for maybe the stranger ones. If they sit in the door frame properly, then they can't be off by more than a couple of coords tops.

[ChaosSlayer]

speaking of doors - i was trying to add a basic door1 to a Guk ldon zone and it won't show up - i guess it don't have the graphics laoded for these zones.

is there ANY door or object graphic available for LDONS? (I know Tak had doors, but rest ldons did not) - I am trying to make ANYTHING what could
serve as clicky zone out object, and running out of idea (other than to add zonign npc which don't work very well in a dungeon)

btw - anyone working on doors for DoD zones?

[trevius]

As for finding available objects (including doors) that can be placed in a zone, I describe how to find them in this post:

http://www.eqemulator.net/forums/showthread.php?t=25420

As for working on doors in newer zones, I have added in doors manually to dreadspire, but that is all I have done so far. I never actually played in the zone on live, so my doors probably are not near 100% accurate, but good enough for what I am doing and I feel that they look correct.

It would be much better if someone could get packet collects from these newer zones to pull exact info for doors like CD did for PEQ database in the other zones. But, I don't know how possible that is now since the packet collector that was working then probably never caught the later zones and I don't think there is a current working one.

Adding them in manually is somewhat time consuming, but it isn't too bad once you get the hang of it. Mainly just going around the zone and getting a bunch of locs and then editing the DB over and over until they are just right. I think the hardest part for Dreadspire was getting the secret doors to be exact enough to not be noticeable right off the bat. Unfortunately, if you have advanced lighting on, they stand out horribly anyway even if they were perfectly aligned.

Sorry to get off-topic with this post. It would have been better if Chaos had started a new thread, or continued the one that I posted above.

As for this LoS fix, it seems great so far. You just have to edit agro ranges on some areas to keep huge trains from happening (Vexthal is really bad with the standard agro range).

To keep in line with this post, would it be possible to write a new section of source that evaluates doors separately so that they aren't seen through?

[trevius]

This fix is good and should go in the next release. Haven't seen any issues with it so far.