Why I Made This

This has moved: see here

The current solutions each have advantages and disadvantages.

Triggernometry makes it very easy to whip up quick triggers. However, where it falls flat is making triggers that are more complicated. You can bodge things like loops into it, but it's overall not going to be the best tool for the job. As a trigger gets more and more complex, at some point you'll hit the point where you say "I wish I was just writing code rather that trying to do this in a GUI" point. There are some other pain points - it is harder to debug than code with a proper debugger+IDE, triggers lack automated testing, and while you get expression-level validation, you don't get validation for things like variable names.

It is also poor in terms of code re-use. Making a function or framework that other people can use is doable, but more complicated and hacky than it should be.

Regardless, it is unlikely that this could replace Triggernometry, but it's clear that there's room for at least Triggernometry plus something else.

Cactbot, with its triggers being written in JS, makes it easier to write complex triggers, and even offers some degree of state management (most things should not carry over from pull to pull). Overall a very good design for what it does. However, if anything, it doesn't take the good ideas far enough.

Both suffer from the issue that parsing log lines is treated as being every trigger's job, when in reality, it should just be done once and parsed into a convenient object. Cactbot provides some nice functionality for programmatically creating the regices, but we can take the idea a step further by providing rich objects rather than strings pulled from the log line, especially since these can include more data than is actually in the line. For example, NPC IDs and such can be included directly in the parsed object. There's no inherent advantage to using regex, it's just what was initially used and stuck around.

Regex also isn't entirely self-sufficient, as in, there are conditions that the regex alone can't implement. For example, filtering to just the current player (without hardcoding a specific name into the regex), or filtering based on player job. Thus, you need conditions outside of the regex as well, so the question becomes: if we have a condition system that can do everyone, why do we also need a condition system (regex) that strictly does less on top of it?

Then, there's the bespoke ACT plugins, like the Jail plugin. These are, in my opinion, severely lacking in functionality, and suffer from re-use issues as well. For example, what if I want automarks, and a personal callout? Setting up two separate triggers for that would make it prone to getting the logic or priority inconsistent between the two, leading to wrong callouts.

What I aim to do here is not necessarily make triggers get "more cheaty", but rather just take existing functionality and make it work better. Or, in some cases, just make it actually work.