Timer Trigger - Match previous line(s) request

[Unknown021]

Currently, from what I can tell, the Trigger Properties of a trigger have a way to not only inspect a given line for a pattern match, but it can also consider the immediately previous line in the logs when determining whether a line matches or not. This is great in concept, but is restrictive in practice.

For my use case, I have a bunch of triggers setup to display countdown timers for my buffs/debuffs. I regularly run into two problems that could be solved with a little more robust previous line matching.

• My countdown timers are activated by others' spells. I almost never need to track durations of others' spells, and in more annoying cases it can restart my timers when I didn't actually refresh a buff. Haste is a good example of this - a lot of NPCs around the world will cast some form of haste on themselves or nearby NPCs, resulting in the "{s1} feels faster" trigger activating and starting a countdown timer even though it wasn't me who cast the spell.
• Some spell lines have the exact same output when the spell is cast, making it nearly impossible to have different triggers per spell. The Root line is a great example of this - my best root spell lasts for 1:48, so my countdown timer is set to that. However I frequently use the lowest-costing root spell for mana efficiency, and that one only lasts for 48 seconds. Both spells have the exact same "{s1} adheres to the ground." pattern to match on, so I can't setup 2 different triggers based on which spell I'm casting.

In both the above cases, you could theoretically fix the issues by examining the previous line to see if it's something like "You begin casting Haste" or "You begin casting Root" or "You begin casting Immobilize". The problem is the matching logic only trigger if the target line and previous line patterns are immediately adjacent in the log files. This is nearly impossible to happen in a spell-casting scenario, where there will be many seconds between the "You begin casting Root" and the "{s1} adheres to the ground" log entries.

It would be nice if there was a way to have a Match Previous Line option, but based on time range instead of just the immediately previous line. That way, triggers could be setup such that the trigger can match on "{s1} adheres to the ground" but only activate the trigger if there was a "You being casting Root" message within the last 5 seconds. I know there could still be edge-case scenarios where this still false-fires (I begin casting root, it fizzles or is resisted, but someone else also rooted withing 5 seconds so the mob adheres to the ground anyway). Additional NOT checks could be added but let's keep it simple since having the ability to match on a previous line within a time range would go a long way to weeding out false positives

Thank you!

[kauffman12]

The problem is that 5 seconds worth of previous lines could be thousands of lines. It's not really practical. The current previous line match doesn't have many uses but the handful of cases it is useful it doesn't have any negative impact on your triggers.

Unless you start basing your timers on your cast messages and use the end early matches for resists and worn off messages I don't think there's a good alternative right now.

You may need to wait for the environment variables people are asking for. Then you could add a trigger for your cast message that sets something like MY_CAST=true and then have the trigger that looks for 'feels faster' message have an additional check that MY_CAST has to equal true in addition to the match pattern. Then you could add a timeout on the variable. Maybe it only lasts 5 seconds. Maybe the trigger that sees the 'feels faster' message also unsets the variable at the same time. I don't know when I'll have this but that's the idea.

[Unknown021]

Alright, thank you for the explanation and reply! I'll see about adjusting my trigger to go off of my cast messages instead of the effect message

[Unknown021]

@kauffman12 hey I tried making my timers based on the cast message but that wasn't really working out either, so I decided to implement a solution for my issues locally. I implemented what I've called a Trigger Window where, if a value is provided and a line matches the window pattern, a countdown will start based on the provided Window Duration. If the main trigger pattern matches within that countdown, it triggers like normal - otherwise it will not trigger. This way I was able to setup triggers that would only be "active" during the X seconds it takes to cast my spells, so others' spells applying the same effects wouldn't trigger my timers anymore, and I could setup different triggers for spells that have the same application message.

If you'd like, I could make a branch and push the code and you could decide if you'd like to make it official.

[kauffman12]

Sure that sounds good for now. And it's alright, I'm still trying to consider all the things people are asking for. This is one case. Just be careful with sharing triggers with people if extra properties are being exported. It probably won't hurt anything but not sure.

[kauffman12]

So, I've gone through the discussions and requests I got on discord and I got a plan generated. It's going to be a bit more complicated to handle all these cases. Here's what I'm working with just FYI.

EQLogParser_Stateful_Trigger_Examples_and_UI_Summary.pdf

[Keliae]

I see this in the pull requests but have no idea to use that version. Would love to use this to differentiate my mezzes.