what-will-become-2.1 (svn) | Potentially infinite skill loop

[Alphaman]

I am starting this thread to report a (potential) bug in Openkore regarding skill blocks and their priorities. This bug has been observed in numerous server types and Openkore versions, but for sake of following regulations, my current server's type is "kRO_RagexeRE_2010_03_03a".

From other posts, I have found that Openkore is supposed to prioritize skills depending on their block's position in config.txt. This behaviour has also been visually confirmed most of the time. There is, however, at least one exception to that behaviour I have come across.

Please consider the following scenario:

a slave priest is set-up to resurrect dead party members, and to heal itself if his HP drops below 80%. Placing the resurrection block before the heal block should guarantee its execution prior to any healing the priest might have to cast on himself. However, if said priest is under heavy attack, starts healing himself, and then a party member dies, he won't execute his resurrection block before his health is above 80%, AND he is ready to cast another skill. To give a practical example, if he was being attacked by, say, 2 of those pesky, fast-attacking Novus, his health might never be over 80% by the time he is ready to cast another skill, resulting in an infinite (or, at the very least, continuous for as long as his SP holds up) skill loop/spam.

My only question at this moment is whether this might have been the intended behaviour or not. Feel free to ask any questions, and I'll clarify as best as I can

[EternalHarvest]

So we have something like this, to clarify:

1. partySkill Resurrection (if target is dead)
2. selfSkill Heal (hp < 80%)

It seems like any selfSkill has the higher priority than any partySkill (they checked this way). That calls for rewriting config parser and part of AI which handles selfSkill/partySkill etc.

[Alphaman]

Yes, that's exactly how I have it in my config file.

So this isn't supposed to be the intended behaviour, I take it?

[EternalHarvest]

Maybe it isn't... But looks like it always worked like that (at least with current AI::CoreLogic).

And it won't hurt to implement it with such priority behavior, as one can always put all selfSkills before partySkills (or we can add special priority block options).

[kLabMouse]

Maybe it isn't... But looks like it always worked like that (at least with current AI::CoreLogic).

And it won't hurt to implement it with such priority behavior, as one can always put all selfSkills before partySkills (or we can add special priority block options).

Nah. Priority was always from the begging of "Config file" to the end.

[EternalHarvest]

Nah. Priority was always from the begging of "Config file" to the end.

functions.pl, r126 - the same logic as in current (first, check all self skills; second, check all party skills).