Aggro Event

[sandy]

I posted here the code updates to implement it ( easy )
http://www.eqemulator.net/forums/viewtopic.php?t=14548

with this event, if you aggro a npc, by entenring in its aggro range, or attacking him, you can now write script events when they get the aggro

I write this to fit the one in eqlive, it's used a lot, npcs says a message when you aggro them :

It's done like this now :
sub EVENT_AGGRO {
quest::say("Die infidel !!");
}

[smogo]

k, sandy, that's nice bump :)

Just wandering, if we keep adding events (expecially unsollicited events), how much noise is this gonna get, and how much extra-cpu requested.

To tell the truth, it'd be nice to extend the aggro event to a 'come in range' event, hence move it from attack.cpp to Mob::AiCheckCloseArrgo. It can then be used for more social quests, for NPC to hail friends, or potential customers, not just aggroed mobs.

There definetly is need for a 'here-is-info-related-to-positions-on-the-map' event. EVENT_AGRRO is ok, but, while you're on the topic, why not a EVENT_INRANGE, with setNextRange, just like you did for EVENT_HP. That was nice.

[sandy]

when a mob aggro a player, it can be because the player casted a spell on him, because the player attacked him, or because the player came in its aggro_range, or because another mob yell for help close to him

I needed it to implement that monsters say a message when they are aggroed like in eqlive

=)

for noise and cpu i don't know =) I post it here so people can say if there is errors better ways t implement it etc ... too

[smogo]

np 8)


Aggro vs inRange
i understand your point. Aggroing is not triggered just when character comes in aggro range of mob ; also the aggro message is nice (WR has it, iirc). I think theres need for both events, they can be used in different ways. The questions can be : how to do this efficiently


cpu usage and unwanted triggering
Just a few stats :
* AICheckCloseArrgo account for more 50% of whole zone.exe cpu in many zones (actually whenever mob population is above 200, which is quite common)
* Out of this, usually less than 15% is really 'in range', that is faction is to be checked because mobs are actually close enough
* Depending on zone type, such check is a hit ... i don't konw how often, but can't be much : mob that aggro one another don't last long :), and no player would last long if it aggroed more than one or two of mobs every step taken in the zone

Having mob say (or doAnim, or emote, or signal, ...) every aggro should not be that much cpu, based on that.


The method you describe is optimized if most (if not all) mobs have such 'aggro message' (keep in mind that lacking such method cause perl exception, that probably accounts more than checking if it's worth the call)


Explicitly setting next event range
just like in the EVENT_HP, it's convenient to set what mob wants an event, at what range, the default being "never". This is what i'd use for non-automatic events, as described in the above post, based on your work on EVENT_HP.


I'll try both the EVENT_AGGRO and EVENT_RANGE, with different methods (still undecided whether to merge to 0.5.7dr2 or wait for next release :/)

keep on good work :)

[sandy]

Like i explained, there is a smart way to make monsters triggering events only if we want it

It's like it is made in Neverwinter Nights
Each monster have a flag called User_Defined_Event in the database =))
You can specify with this flag that its spawn event is enabled
And when the mob spawns, it checks the flag, see that its spawn event is enabled and then trigger a spawn event and then looks and run its spawn script

Maybe it's possible to make something like this when you load the perl scripts

[smogo]

yeah, this is what is used for quest_globals, for instance.

Ok for that, it's a good idea, i suppose we should have an "int event_mask;" field in Mob that would extend qglobal's behaviour, i.e let event trigger or not depending on Mob's having usage for it.

i suppose this has to be a simple type, so int32 is fine for now. This allows for 32 events. Gonna go and work on that;

p.s. my windoze box died last night (heart attack, AMD cpu don't live long :(, less than 5 years, where have IBM good times gone ?), so can not follow this very accurately atm.

i started some changes to Quest CVS, including EVENT_AGGRO and EVENT_RANGE. It's running on my pet server, but i dont have the client to test it :/