akourbat

Did some more testing. It works... unless you are a fast clicker. I suppose chat parsing takes some time, and if you happen to click the mastery a second time while it is being processed via "secondary detection method" and "StM" is being on - you end up getting mastery to execute twice in a row.

akourbat

Yes! Just ran a quick test on one of my wardens vs. dummy, and is working! Thanks!

Thurallor

Yes, it should work now (v4.05), with the "secondary detection method". The plugin now considers the two names to be entirely equivalent -- it doesn't care which stance you are in -- when parsing the chat log.

akourbat

Excellent! Sometime in the past I had similar issues on my Ministel, with Codas. Each of mini's 3 stances has its own specifically named coda, and switching stances sometimes messed up the rotation on specific codas. I believe now the database has all 3 coda names in it.

Now, if warden were to switch stance mid-combat, let's say from ranged to melee (which would replace "javelin" with "spear" in each and every warden's ability), and assuming you added "javelin" skills to the database - would it be still recognized as intended skill? I am talking about effect of StM ("Seize the Moment") being on (i.e. still no cool-down on masteries).

In other words, would "Fist-Spear" mastery be treated same as "Fist-Javelin"?

To be even more specific - I like the warden's yellow build (ranged) that fishes for StM proc, immediately switches to melee once it is on, and back to ranged when it is off - etc.

Thurallor

Ah, that's the issue, then. The skill database (which is manually compiled and maintained) contains the "Spear" names, but not the "Javelin" names. I'll add those in the next version. Thanks again for reporting the issues.

akourbat

I am pretty sure that was the first thing I tried when I encountered the glitch, but I'll recheck. One thing to note is that I am playing in ranged stance and my gambit builders and masteries are spelled differently (javelin instead of spear). The plugin offers only "spear" versions in the list of abilities. Not sure if this is relevant or nor for chat message parsing.

Thurallor

I think this has to do with the fact that the "Seize the Moment" effect reduces the cooldowns to zero. The normal way that the plugin detects skill execution is when the cooldown resets; if the cooldown is disabled, then that event probably never occurs. However, it should work with the "secondary detection method", which looks for a message in the combat log.

akourbat

Hi, I am still re-working my rotations, both to incorporate recent additions to the plugin, as well as to reflect my leveling progress. So far I have not encountered any glaring bugs - stuff seems to be working as expected.
For my wardens, the biggest impact on bars was due to new ability to set LUA variables directly by raising events, as for continuous evaluation ("CE") - I expect this to be most useful to my guardian (to track block/parry response effect availability while moving) and hunter (for merciful shot ability and focus-based skills usability while moving, too). I'll experiment more on warden's gambit default ability. The tricky part is to catch the moment the CE kicks in and saves the day, as it is hard to emulate such combat situations on target dummy.

Overall excellent updates, thank you!

A minor issue I had with wardens (unrelated to plugin recent updates) - is that when I hit lvl 50 and acquired end-yellow-tree talent "Seize the Moment" https://lotro-wiki.com/index.php/Seize_the_Moment, I noticed a glitch when it procs. In spite of having all my gambit masteries using "when executed" check, during the StM effect they just stay stuck in active slot, and keep executing over and over, filling the gambit bar with builders, rather than executing once and moving on. I overcame this by unchecking "when executed" for them and instead using "on left-click" to advance them. Since they are instant anyway and dont require a target, this worked for me. Outside of SzM effect, masteries worked just fine with "When executed" option selected. Just thought I'd still report the issue though.

Thurallor

In version 4.04, I have changed the new option to be slot-specific. Awaiting your feedback.

akourbat

Yes, that was my first thought, too. I suppose there is a performance penalty for running continuous evaluations, ideally would want those targeting specifically abilities that tend to "mis-behave" in combat.

I did a very quick run on the dummy, being on warden. I have "gambit default" skill as a separate bar, which is then included in gambits's own bars. It is a source of some issues for me, so I keep experimenting on it, including small delays before and after it, etc. It is a kinda special ability which is greyed out by default and lights up only when there are appropriate gambit builders present on the warden's gambit bar.

So I set that one bar on "continuous eval" and put an "if" checking if the ability is usable, and what I noticed is sometimes gambit default was entirely dropped from the rotation, leading to "merged gambits". I'll test more on the weekend.

Thurallor

No, not as currently implemented. I guess I would have to make it a slot-specific option, instead of bar-specific.

akourbat

Awesome! Sure, will update the plugin asap and will test it during this weekend! Thanks!


Question - if my bar includes other bars, and one of those "child bars" is set to continuously re-evaluate conditionals, would that behavior be "uplifted" to the parent bar(s)?

Thurallor

Hi akourbat,

I have added the "continuously reevalated conditionals" as an experimental option in v4.03. (It must be activated for each bar, in the bar's settings menu.) Please give it a try and let me know if you find any problems.

Thurallor

It is a bit confusing. I will try to think of an intuitive way to indicate that the event is being generated by an included sequence.

Awesome, please keep your eye on the "error" log, there may be a few bugs yet.

akourbat

Done. No, Events bar is not included in any other sequence. One of the bars (dps2) actually does use "reset" event - flagging end of the rotation, and it is included in "Main" sequence, other bars also are included in "Main", but do not use "Reset".


UPD: Right, now that I thought more about it, it makes sense - as my sequence is built as nested "if-else"s and "dps2" is at the end, one could say that every other bar is sequence indirectly uses "Reset"... It just was confusing a bit when I first looked at the new panel.


I am super glad with this new ability to set LUA variables directly by raising an event - very clean, and it was working as expected when I briefly tested it. Good job!!