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). However, it still doesn't take the next logical step of abstracting away the actual log lines into objects where everything is already parsed.

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 this still doesn't answer the question of why an individual trigger should be remotely concerned with a regex in the first place. Or - for that matter, why we're even using Regex rather than just splitting on | characters and mapping them to fields. Splitting may result in somewhat reduced average-case performance, but improves worst-case since you don't have to worry about user-supplied, poorly-optimized regices. You also gain significantly more performance than you lose via this approach, by virtue of only parsing a given line once, no matter how many triggers you have.

Regices also have poor serparation of concerns. The regex lets you choose the desired event type easily, but for conditions past that, such as filtering to a particular ability ID, it could be done in the regex, or in the code. Leaving both options open just leads to inconsistency.

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.