Added AutoPassiveSP but there is a "lock" problem

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Update TargettingSupport.lua with part of my script
2.Set some values to AutoPassiveSP, AutoUnPassiveSP and AutoPassiveSPisPercent
3.Make actor use only skills on an enemy, i didn't set AttackAllowed to false, 
but this particular case happens a lot when using Bow mercs

What is the expected outcome? What do you see instead?
I expect the mercenary to "lock" into target when using skills only, but for 
some reason it enters passive mode when the SP is too low instead of continuing 
with normal attacks.
I don't think this is a fault of the AutoPassiveSP part of the srcipt, because 
i've seen many times that homuns or mercs use a skill on a target and then uses 
a skill on another nearby target, i "think" that the "lock" to target function 
is not being triggered by using a skill on a target.

What revision of the product are you using?
$Id: Version.lua 171 2010-06-19 10:12:41Z faithful613 $

What type of homunculus/mercenary are you using?
Bow Mercenary (however like i said, i've seen part of the problem using a 
Vanilmirth)

Please provide any additional information below.

I updated TargetSupport.lua to support AutoPassiveSP, AutoUnPassiveSP and 
AutoPassiveSPisPercent.

Changed or added lines will be between these comment tags
-- ADDED AUTO PASSIVE SP
Code
Code
Code
-- AUTO PASSIVE SP END

Note for the public: Use this file at your own risk, this is not an official 
release modification and it's not authorized as such, please do not report 
defects with this change.

Original issue reported on code.google.com by Kusanag...@gmail.com on 9 Sep 2010 at 12:07

Attachments:

• TargetingSupport.lua

[GoogleCodeExporter]

I will add a comment becuase i think this is a blend of 2 problems.

1st.- Homun/Mercs should not stop attacking (either physically or by skills) 
even if the threshold for going AutoPassive is reached. There's a comment added 
by me if this can be set as optional rather than hard coded.

2nd.- Somtimes Homun/Mercs cast a skill to an enemy target, and later, before 
killing that target, it uses a skill to a different mob, causing 2 unaggressive 
mobs to come to it making it harder to deal with the situation

Original comment by Kusanag...@gmail.com on 9 Sep 2010 at 2:04

[GoogleCodeExporter]

Sorry, I'm not clear what the problem is. AutoPassiveHP will cause the AI to 
temporarily enter passive mode when HP is below a certain threshold. If passive 
mode is set to not defend, then this is by-design.

The idea is that when HP drops below a certain level, it will act as if ALT+T 
was pressed--moving the AI into passive mode. When the HP rises above a 
potentially different threshold, it will return again to Aggressive mode.

AutoPassiveHP (and by extension, your AutoPassiveSP modification) has nothing 
to do with target locking. Further, AutoPassiveHP works for both attacks and 
skills. If you would like to implement behavior that is specific to skill 
usage, RAIL.IsAggressive is not the place to do it. Instead, look at adding a 
sieve function to the Skill table. An example of this can be found on line 172 
of SkillAIs.lua in revision 173.

So I apologize, but I do not understand the problem you are trying to convey. 
Can you clarify?

Original comment by faithful...@gmail.com on 17 Sep 2010 at 5:23

• Changed state: Pending

[GoogleCodeExporter]

I'll try to give examples of this problem see if it's a little more clear.

I think AutoPassive options should be situational, making it go into ALT+T 
seems a little drastic. I was in Orc Dungeon, my homun was attacking a mob of 
like 3 orc skeletons and it went below the AutoPassiveHP threshold and suddenly 
it started walking back and forth to the enemy without attacking, now here's 
when it becomes situational, i could either think that i want my homunculus to 
keep attacking the current targets and defending itself until it dies or think 
that i want my homunculus to survive and it should start walking away targets 
to an open space trying avoiding damage and focusing on staying alive. Let's 
say that after i killed the mobs and the the homun is below threshold, that's 
when i want it not to attack anything (if not aggressive).

The second example is when i was in Moscovia Dungeon using a bow mercenary, 
this is when i decided to add AutoPassiveSP, monsters there are not aggressive 
and the mercenary was easily dispatching them from a distance spamming DS, 
however without DS the situation became a little more complicated as the 
monsters could get in range and attack the merc, by AutoPassiveSP i can make 
sure it starts attacking monsters when it has enough SP, the problem comes when 
the low threshold is reached but it was already attacking a monster, the same 
thing happened, it completely stopped attacking which is not desired.

Now i say that this might be a "lock" problem because i think that attacking a 
monster that has already become aggro (either it is already aggro and the AI 
should defend or it started already  an attack) should be a priority, even if 
the thresholds levels are reached. This problem is only concerned on the 
AutoPassive options, HP or SP.

The second problem is that it seems that when using skills doesn't cause the 
"lock" normal attacks do, i've seen mercenaries and homunculus use a skill into 
a monster, then if no normal attack is performed then it uses a skill to 
another monster.

If you need more clarification let me know. 

Original comment by Kusanag...@gmail.com on 17 Sep 2010 at 11:54

[GoogleCodeExporter]

In revision 192, I added a state-file option MaintainTargetsWhilePassive. When 
set to true, this will allow the AI to attack and use skills against any target 
it has already attacked. I believe that this will remedy the situations that 
you've described above, without creating a new pseudo-passive mode that might 
confuse players.

Also note that I've implemented AutoPassive based on SP value/percentage into 
the base as well.

Can you verify that this works well for your situations?

Original comment by faithful...@gmail.com on 4 Dec 2010 at 3:42

• Changed state: Fixed