Pattg-in-mn

Hi I am having a problem.
I just installed this plugin and i love it.
I have several characters and have it installed on them.

On one character I accidently hid it some how.
I have tried the shell commands, no go on showing it.
I have gone in the Plugin window and tried showing it in the option window, no go.
I have uninstalled it, deleted the folder in the plugins, and plugin data folder and reinstalled it, no go.
I have tried to copy this accident on my other characters but everything works according to directions and can always show the bar again.
What am i missing to fix this.
Thanks for any help.

Thurallor

Pattg-in-mn

1. Open the Plugin Manager.
2. Select SequenceBars in the list.
3. Click the "Options" tab.
4. Click the "Directory" subtab.
5. Right-click on the "Show" button next to the hidden bar.
6. If you still don't see the bar, it may be off the screen. Right-click in and choose "Find".

Thank you i will try that tonight

akourbat

Hi, for some reason on my guardian self-health based triggers never fire in combat. For example "Catch a Breath" is always skipped even though the conditions for its use could all be all true. Surprisingly morale checks for enemy targets work just fine, I use it on "Hammer Down" skill and it works as expected. Has there been some changes made recently to game's API that prevent such checks now? Or should I now target myself to check my own morale?
Regards,
Alex

UPDATE: I made it work by removing "skill is usable" check from "Catch a Breath", but am curious why it prevented the use of the skill in the first place. It lights up when there is a parry response ans I assumed this is what "usable" is. I works for me still, as this whole subsequence is predicated on parry response check, but would be good to learn if there is an explanation to the "usable" which I may have missed.

Thurallor

Your guess is as good as mine. My plugin merely exposes the IsUsable() function that is built into the API. Sometimes it works; sometimes it doesn't. It isn't documented anywhere, so we don't even really know what it is supposed to do. Use at your own risk.

akourbat

I see. Yeah, I was lulled by IsUsable() because for the most part it does what I assumed it was supposed to do. For example any other response skill aside from "Catch a Breath" work as expected when enclosed in "if usable". I figure just need more open world testing to verify my assumptions when building rotation chains. I dunno, maybe having a health check prevents any other api calls within the same "click" and is intended feature.

I also wondered if "usable" will return false if the skill is lit, but has a red dot on it, indicating that you could be at wrong distance or face in the wrong direction, but this appears not to be the case, unfortunately. Could be useful in some scenarios.

Regardless - super useful plugin. thanks!

akourbat

Whoa "...s Online\Plugins\Thurallor\Common\Utils\Utils_11.lua :61: stack overflow"!

I am trying a deep nested sequence of "if-else's" and here's what I get . The game kinda reacts to it negatively too bu micro-freezing. Any idea what my cause it? So it goes like "if hunter focus = this? -> do this, else do subsequence "A" which basically is also "if-else" but testing for different condition, and so on, about 10 degree of deepness all-in all.

Thurallor

Ha, nice going, you broke it.

Just kidding. 10 levels of nesting shouldn't be anywhere near enough to overflow the stack. That normally indicates infinite recursion, which shouldn't be possible, so there's a bug somewhere.

Please send me your .plugindata file at [email protected], and if you can, describe the exact scenario of how I can reproduce the problem.

The .plugindata file is usually at

Documents/The Lord of the Rings Online/PluginData/<account>/<server>/<character>/SequenceBars.plugindata

akourbat

I did some re-shufflings in the rotation and settled on using user events within the sequence resetting the rotation after each skill that has influence on generating/consuming hunter's focus (which is the main predicate used throughout the if-else tree). Before that I tried to use small delays instead of user events, that's when I got hit with stack overflow, but could be other things too. Sadly I did not save the problematic sequence, so the debug opportunity is lost... Current rotation appears to be working quite well too, as I cut down its depth to 7 and moved some stuff to their own bars, so I switch over to them when I need (user triggered via events), like AoE, Cure etc.

Thurallor

I'm glad it's working for you. SequenceBars automatically backs up its data, though. You should have backup files for the past 7 days, such as

Documents/The Lord of the Rings Online/PluginData/<account>/<server>/<character>/SequenceBars_backupn.plugindata

where n is a number between 1 and 7. So if you did want me to debug the issue, you could send me your backup file from yesterday. It's up to you.

akourbat

I sent the file as suggested. There was quite a bit of experimentation going on on that day, so I am not sure there is a easy way to single out which rotation was blowing up, but there we are.

My thought was if you have nested if-elses and nothing else in your rotation, i.e. the rotation on execution is supposed to end up yielding a single ability on each pass-through, then it somehow causes memory leak, i.e. not resetting when you click that single ability and the system keeps the original frame in memory, and keeps pushing new frames with each click. When I added events resetting the whole sequence after each ability used in if-else tree, the issue went away. Just my two cents.

Thurallor

Thanks, I'll take a look.

akourbat

I was fiddling with my Minstrel the other day and ran into memory issues too, when I went to around 8th degree of nested-ness with "is else". The game started seizing up and turned into a slide-show, however I have not seen "stack overflow" messages this time. I dunno, maybe it is just too many API calls on each click, especially when you are near the bottom of the logical tree, and the engine does not like it.... I guess I should flatten my rotations a bit.

Thurallor

I looked at your hunter setup and it seems you have a deeply-nested "include tree", on top of the nested conditionals. To help isolate the problem, please try eliminating the includes to see if it improves it. Then I'll know which direction to proceed in debugging.
1. Make a backup copy of your bars.
2. In each instance of including another bar, click the "Unlink" button to copy the contents of the included bar.
3. Try it and let me know what happens.

By the way, the .plugindata you sent me for your hunter has the "EVAL" user events being generated in many places. Is that the version that caused stack overflow? (In a message below, you indicated that you solved the stack overflow by adding this event, which triggers a reset of the bar(s).)

akourbat

Yes, each nested "if else" clause is a separate simple sequence with its own "if else", I thought that was the preferred way of structuring it to avoid a mess of "{{{}}}"s in one long sequence. "Eval" events were added after I got the overflow error and is what appeared to solve it for hunter.

I'll see about "unlink" option you suggest.

Meanwhile it occurred to me that maybe I am overcomplicating things in my rotation. The primary goal for me was having something one calls a "priority casting", where an ability with higher priority is always cast next when its conditions evaluate to "true". Normally. you place such abilities in the order of priority starting from the beginning of the rotation, highest priority being first and so on. I attempted to structure this via nested "if else" thus forcing the entire rotation to get re-evaluated each time it yields a result. Now, I am thinking about having a linear structure with "if thens" and just forcing it to go back to beginning after each action (like with "Eval" event for hunter). There'd still be a need for a few "if else" (e.g. when dealing with hunter focus condition), but I think that could at least eliminate deep nested tree. I'll post back when I test this idea. At least this could also help to cut down on API calls, as there'd be no need for some complex LUA condition checks (like "if focus >9 AND skill X is off cooldown"), and rather having outer "if" checking focus > 9, and inner "if" dealing with cooldown, so that inner "if" check can be skipped if outer is false, thus presumably lessening pressure on API (that is unless complex LUA calls also skip second check if first results in "false").

Update: I reworked the sequence for my hunter, essentially getting rid of all "if-else" clauses, and only having "if-then". I trigger the reset via user events after each skill, so that the rotation always resumes from the beginning and works its way through "if" clauses linearly, finding first skill that is available, triggering it, and then resetting back to the beginning again, and so on. No memory issues observed, and I am pretty happy how the priority system works now. Thanks.