Jump to content

MostDamagedOf


zefklop

Recommended Posts

The script identifier MostDamagedOf seems to select only PCs and ignore NPCs.

 

By the way, I was unable ti find documentation about this kind of identifier (NearestOf, LastAttackerOf, etc...), even if their name makes their utility quite obvious :(

Link to comment

MostDamagedOf() returns the most damaged party member (based on whatever metric). BestAC(), WorstAC(), LeastDamagedOf(), WeakestOf(), StrongestOf(), and StrongestOfMale() all work similarly (returning the matching party member based on some metric you'd have to determine through testing). You don't have to specify () (Myself), and any objects you chain along is usually pointless.

 

There is no documentation. Nearest() doesn't work (you just use your [spec], which conveniently always picks Nearest()), nor do nthNearestEnemyOfType()s. LastAttackerOf() is set in hardcode to the object last delivering physical (not-spell) damage. LastTargetedBy() does nothing. LeaderOf(), GroupOf(), Protect(ed|or)(), and LastCommandedBy() are worthless (BG and BG2). LastTrigger() is set in tons of ways, and can be set globally (e.g., casting a spell sets every active object's LastTrigger() to the spellcaster).

Link to comment

Groups are pretty nonsensical in BG. Basically, two creatures with the same specifics value are in the same group, with no other qualifiers. This is why NearestMyGroupOfType and InMyGroup() and such can return such ridiculous results (usually of the sort where a party member is helping an enemy or vice-versa).

 

I don't think that's necessarily what they intended for GroupOf(), but there's not much else to determine who's in what group (it could be allegiance checking, but it doesn't seem of enough use to bother with it).

 

I'm sure it will be possible to get additional objects, but most of the existing ones like that are already used with the intent that they're only picking up party members, so changing them outright would probably just break default scripts for some of the games.

Link to comment
I'm sure it will be possible to get additional objects, but most of the existing ones like that are already used with the intent that they're only picking up party members, so changing them outright would probably just break default scripts for some of the games.

hehe, that is actually what happened with MostDamagedOf() :(

Link to comment
Groups are pretty nonsensical in BG. Basically, two creatures with the same specifics value are in the same group, with no other qualifiers. This is why NearestMyGroupOfType and InMyGroup() and such can return such ridiculous results (usually of the sort where a party member is helping an enemy or vice-versa).

 

Yes, this has been my experience as well. InMyGroup() simply compares the SPECIFIC values (0x0274) of the targeted creature and the script runner. So, if the SPECIFIC value of the target matches the SPECIFIC value of the script runner then InMyGroup() will return true. The allegiances of the creatures don't seem to be a factor here, i.e. InMyGroup() will return true even if the script runner is [PC] and the target is [ENEMY] as long as they both share the same SPECIFIC value. :(

Link to comment

Yeah, I believe Nearest*OfType() completely ignore EA too. This makes sense for NearestEnemyOfType() (either the engine overrides the specified EA with its own determination of what constitutes NearestEnemy of the caller or it just ignores it altogether), but not really for NearestMyGroupOfType() (where no allegiance is implied).

 

So you might think you'd get all clever and check NearestMyGroupOfType([2]), BUT YOU CAN'T. ;-)

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...