Thurallor

Strange. Is the "events" bar being "included" by those other bars? If not, I would guess it has something to do with the name of the event ("Reset") being a special case (which would be a bug, of course). Would you mind sending me your .plugindata file?

I upload the image to imgur.com. Then click "...", then "Get share links" and use the "BBCode (Forums)" link.

akourbat

Fantastic!

I am seeing some bars that don't generate the event (in fact aside from "events" bar, none generate "reset", it is manually triggered by me via hot-key) https://1drv.ms/u/s!AkUfQANqQ5Oy0nd_...WA6nQ?e=5za7sk

What could be the reason?


P.S. I am not seeing an icon to insert pictures in the post edit mode, how does on usually posts screenshots here?

Thurallor

The new release (v 4.00) doesn't include this feature yet, but it should make some of the things you are doing easier and more convenient. See release notes.

akourbat

Aah, I see now. For some reason I assumed this was a pre-condition for executing the currently displayed slot. So my gambit masteries were still executing even if target was dead already (or new target still being processed by client), but not advancing to next slot, when I had that option checked. This ties in with your further explanation that once the skill is displayed in the active slot on the bar, there is nothing the plugin can do currently to prevent it from being attempted to be executed by clicking it, short of bar reset.

I am already a big fan of this potential "continuously reevaluated If" option feature!

The one I was specifically testing is "Tier1 - Battering Strikes" effect applied when warden does "Precise Throw" (https://lotro-wiki.com/index.php/Bat...rikes_-_Tier_1). It reduces Crit Defence of target when applied.
So my setup was as follows:

- individual target dummy (3 min uninterrupted combat),
- rotation with automatic "If" and "target does not have effect" with "Tier1 - Battering Strikes" selected form drop-down list, surrounding "precise throw" gambit abilities. The rotation had other abilities as well, with their own logic.
- I had the sequence opened is edit mode, and "If" selected to watch its return.

At the start of the combat with dummy selected as target, "If" showed "true" (as expected). After "precise throw" fist landed, it turned to "false" (also as expected). But, after a few seconds, it reverted back to "true", although the target still had the effect (it lasts for 35 sec). So the "precise throw" was executed again and again, with similar results.

For now, I went with a setup which has a LUA variable set when skill is executed, which is being re-set when target changes (via auto-executed sequence watching for target changed and resetting the variable). At least that avoids re-applying the debuff on the same target. It is not ideal, but it is something already

Ok, that is perfect, just wanted to make sure.

Anyhow, thanks for your clarification, many things are now understood better by me. And looking forward to further enhancements to the plugin!

Thurallor

Yeah, for whatever reason, when you switch targets, the API doesn't report/expose the new target information immediately. It can take a significant fraction of a second before any info about the target is available. To see how long, go to a place with several mobs standing around, and TAB between them. The first time you target each mob, you'll see a short delay before the correct morale/power appear in the mob's vitals. The API can't get info about the target before that happens.

The plugin tries to mitigate this problem by generating a second "Target changed" event when the info becomes available, so any "Target changed" event behaviors can be executed again with the info available. But if you are in the middle of a sequence, changing targets, there can (and often is) a significant interval of time during which no information about the target is available.

If, in the middle of a sequence, you have "If" slots based on some info about the target, you should first check if there actually is a target. There is no "If target present" conditional, but a pretty good proxy is "If target morale > 0". All target-related conditions should be "false" if there is no target, or if info about the target isn't yet known.

To be clear, there are no options for executing the skill, once it's been clicked. The act of clicking the slot tells the game client to execute the skill, and the plugin has no say in the matter. All the plugin does is decide whether to display the slot or not -- and whether to advance to the next slot after you click it.

The "require target" option indicates whether to advance to the next slot after the skill is clicked, based on whether you have a target.

I could add a similar option "require the skill to be ready and usable", which would indicate whether to advance to the next slot after the skill is clicked, based on whether the skill was available when you clicked it.

However, the "advance when skill is executed" option is aimed at achieving much the same effect. If you click on a grayed-out skill, it won't execute, and so the sequence shouldn't advance if this option is enabled.

I think this is a case that would benefit from an option (as mentioned below) to specify that an "if" slot should be continuously reevaluated until the next skill is clicked.

Yeah, this would be a special case of the "continuously reevaluated If" option. I think I would rather implement the general case, if it's feasible. Especially because merely dropping the skill from the rotation wouldn't always be the desired behavior; maybe you'd want to substitute a different skill, for example.

Unfortunately, the "effect on target" functionality of the Lua API is very flaky and inconsistent, and not likely to be fixed any time soon, if ever. I've tried hard to find a workaround, but so far failed. The next version of SequenceBars will allow you to generate user events based on chat window messages (e.g. combat log messages), so there may be a way for you to implement your own way to handle target effects. But it will never be as accurate as monitoring effects on your character, because the API simply doesn't work, and the chat messages don't give complete information. (I need to add a disclaimer in there about target effects not working very well.) Sad but true.

Assuming all of your "If"s are set to automatic, they should all be evaluated in an instant, before the sequence advances to the next slot. None of the "If" tests should require any network traffic or significant processing; the plugin uses local caching to optimize speed. In the worst case, it would just drop a frame or two. Can you figure out which "If"s are getting the wrong answer?

Yes. A plugin's variables are only available to that plugin, on that game client. They can't be accessed by any other plugin on the same client, unless those two plugins are specifically designed to share variables (i.e. by sharing an "apartment"). The only way to share data between game clients is through chat messages. (Plugins can't even send chat messages spontaneously; all they can do is make a /tell shortcut and ask you to click it.)

akourbat

Quick update - I got myself a cool training dummy from Curator seasonal splendor vendor, that popped up today during the festival. This one adjusts to your level when summoned, and does not reset combat every 20 seconds like dummies out there in open world. So now, I can watch longish debuffs on it and monitor sequence conditionals, very cool!

To my previous message - most of my mentioned woes with "ready/usable" appeared to be due the fact that I ticked "requires target" on Gambit Mastery abilities. Once I unchecked those - as they really dont need target at all, it goes much more smoother. I'd guess the problem was that when in real combat, and in such time windows where during target selection the mastery was clicked when there was no yet active target, the plugin missed or ignored notification on usage, and it got sequence locked. So the bar was stuck on the mastery that was now on cool-down. I still do have some problems on gambit default ability, but now cant pin-point the source of trouble yet. Some gambits require target, and some do not - whereas all my "Gambit default" abilities have "require target" checkbox ticked (maybe I should change that too, specific to each gambit?).

Now I am testing "effect on target" functionality, e.g. some debuffs. The ones I tested today was debuff applied by warden's ranged "precise throw" line - i.e. crit defense debuff. It is weird. Granted, these debuffs are not causing any active damage ticks (i.e. no chat messages). But - watching the side window which shows the sequence, the appropriate "IF" sometimes catches the effect, and sometimes misses it. These debuffs are quite long (60+ secs), and I would rather use other gambits while debuffs are still up on the target, ideally re-applying T1, then T2 as they drop off.

What I also noticed (I think), is that when I slow down on my clicking, it skews towards being more accurate. My sequence is quite complicated, and there quite a few "IF"s that need to be checked before the action is selected. (even if my warden is lvl 32 lol).

Which leads me to a question - is there a max batch size the API can handle as single request? Maybe some "IF"s are getting dropped due to some such limitation?

Another (unrelated) question - if I set a LUA variable on one character, is it unique to this character only? Let's say there are two game clients running - as I sometimes dual-box - each of the two characters will set his/her own variables, right?

Thx again in advance if you'll find time to respond.

UPD: Just tested warden's HoT gambit line, which puts HoT effects on warden himself (healing every 3 sec, recorded by chat), and it is just fine, regardless of my click rate. HoTs are re-applied as expected.

akourbat

As you say, there are two general types of "If" - one that checks for combat/non combat effects present/absent, and the second one monitors the state of your own abilities - ready/usable. There are more, like target being in fellowship, but I'd still put them into the first category.

The first I'd call reactive, the second - pro-active.

The one that gives me most headaches at the moment is "ready/usable", because wrong boolean result of "If" at the exact time the ability is clicked (due to slower clicking, maybe due to movement, or server lag) can effectively lock up your rotation.

If, for example, the options for executing the ability slot could include the forced check for "ready and usable" (like a checkbox maybe, you can opt-in or out) - with such check being carried out right when you click the ability on the bar - I would imagine that could solve a lot of issues. You'd still need to put your "Ifs" for readiness/usability for the sake of plugin building up slots in the UI to follow, but it reminds me of try/catch blocks used in programming to handle exceptions. The simplest way to handle such "exceptions" would be to immediately drop the ability from the rotation if it fails the check (swallow the exception"), thus preventing the lock.

Just thinking out loud here, I don't know if it even theoretically or practically possible.

The reactive "If" check, as you mention, can simply be delayed by small amount of time right before the "If" if you expect that your previous ability generated the effect (I usually do it by inserting small delay right after the ability that I expect to produce the desired effect instead, but it is semantics). But I suppose it too, can benefit of a forced re-check of ready/usable, at least for some abilities, like hunter's merciful shot, or guardian's block and parry responses)

akourbat

Thank you for the reply, looking forward to any new feature, great plugin!

As to server lag, yeah - that's pretty much what I thought. For now, I am mostly using manual reset via keybound event. In some cases - like default gambit ability use, I switched to "advance when clicked" with about 1 sec delay right after and a little delay before.

Frustratingly even if rotation appears perfect on a training dummy, out in the wild with constant target switching and entering/leaving combat quite a few things do go wrong...

But will keep experimenting, thanks

Thurallor

That's strange. I would expect those two methods to be more-or-less equivalent. I'll do some testing to see if I can reproduce the issue.

I'm also working on a major feature addition (cf. our previous conversation) that should obviate the need for these "flag-setting" bars. Still in progress, though.

I think you have grasped the nuances of the issues around these "race conditions" that exist due to server and/or network lag. For an "if" slot, the conditional is evaluated

• when you click it, or if it's set to automatic:
  • immediately after you click the previous slot ("Advance to next slot with left-click"), or
  • after the clicked skill is executed ("Advance to next slot when skill is executed")
    • as reported by the Lua API (default detection method), or
    • as reported in the chat log ("Use secondary detection method").

However, if there is some result of the skill's execution that you want to check for, that result may not be detectable immediately. (For example, it may take some amount of time for a buff to appear on your character after the buff skill executes.)

One way to mitigate this would be to add a delay before the "If" slot, to give time for the state change to occur/be detected before the condition is evaluated.

Or, you could turn off the "automatic" feature of the "if" slot and require it to be manually clicked, so you can manually deal with lag issues.

You might also try using the "secondary detection method", which may be a bit slower due to chat server lag.

The only other approach I can think of would be using a continuously-executing bar to continuously evaluate the condition and emit user events that cause other bars to appear/disappear.

I guess ideally you'd be able to specify that an "if" slot should be continuously reevaluated until the next skill is clicked. That would potentially cause a lot of overhead, as the rest of the bar would need to be reprocessed every frame, so the appropriate slots can be drawn to the right of the cursor. I'll think about this more.

akourbat

FWIW - I could not achieve reliable execution as per your example, sometimes it worked, sometimes did not. My guess would be that bars that need to be reset by user events to execute LUA script (setting variable that is picked up by main sequence) are nor being reset unless that bar has somehow been made "active" (either by click or by manually triggering its LUA action while editing it. That's just a guess though.

However, it works if you make these bars "auto-running", and instead of resetting it I now set "start-running" event behavior. Then after LUA action I added "self-shutdown event", and assigned "stop-running" behavior to this event. After limited testing, it seems much more reliable now.

General question - sometimes my rotations (on other chars too) locks up, attempting to cast an ability that is already been cast and is on CD, or it becomes unusable (greyed-out") for some abilities. That happens despite the "if" checks around such abilities verifying that that they are ready and usable. I think it mostly happens due to server lag (I have ~120 ping from where I play), but also maybe the ability state change occurred after the "if" check passed and before I clicked on it.

What would be preferred way to deal with this - should I put problematic abilities on "execute when clicked" rather than usual "when executed" and some custom delays to allow execution? Any hint would be appreciated.

Thurallor

Skills can only be triggered by mouse clicks (or by hotkeys, if they are assigned to your quickslots). That is an intentional design choice of Turbine/SSG which cannot be bypassed by a plugin. SequenceBars will move the slots under your mouse so you can click them in sequence, but cannot click them for you.

NazTheEternal

Hi there,

Really excited to use this plugin as I restart my journey in LOTRO as a Warden this time.

I attempted to set this up so that my skills trigger one after the other all the way until my gambit is set up, but for whatever reason, I cannot get it to trigger the second skill in the chain.

Am I missing something in my setup? Do I need to understand LUA scripting to be able to do this?

Thanks in advance!

Thurallor

Yes, that should work fine.

akourbat

Hi again,

Can I set more than one LUA variable via single LUA action? Something like "aoe=true; singleTarget=false;". Or I need two separate LUA actions for this example to work?

akourbat

Sure, understood. And your continuing work on the project is much appreciated.