Is your feature request related to a problem? Please describe.
The default trigger for SPELL_CAST_FAILED doesn't offer a way to filter by fail reason (parameter 15 for CLEU with that sub event), making the whole thing largely pointless for most applications.
Usually you'd like to see if it failed because of LoS/not enough Mana/CD not ready/etc.

Describe the solution you'd like
Add a drop-down where you can select one of the various failedTypes to filter with.
Or at least an edit box where you could enter it, but that's a bit iffy because I doubt the usual user would know where to look for how these are spelled.

Describe alternatives you've considered
Making a custom trigger for it. Not an option for most users I'd say.

Additional context
I've seen a handful of people request help for auras doing that to some degree over the past 2 months or so in the discord, since they can't figure out the custom approach.

If I read the documentation at https://warcraft.wiki.gg/wiki/COMBAT_LOG_EVENT correctly failed type is a localized string, and can have one of these values: https://www.townlong-yak.com/framexml/8.1.5/GlobalStrings.lua#12934

If I read the documentation at https://warcraft.wiki.gg/wiki/COMBAT_LOG_EVENT correctly failed type is a localized string, and can have one of these values: https://www.townlong-yak.com/framexml/8.1.5/GlobalStrings.lua#12934

That's correct, and that's what I ended up doing every time I made one of these auras for people: check if parameter 15 is SPELL_FAILED_LINE_OF_SIGHT or whatever they wanted.

But that's the problem; right now you need to make a custom trigger for that. The default combat log trigger is largely useless in that sense.

If there was a drop-down for it in the default trigger, they could do it themselves.
Purely from a functionality standpoint I don't see a reason not to bake that in as an option for the default trigger. It's available, and it's the thing you'd want to check for when looking at failed spell casts beyond just checking if something failed at all.

Yeah, that makes sense to me.

I can also totally see the effort being involved to reach a suitable solution not being worth it for something that, at least from what I've personally seen, only 5 people had issues with.
Especially considering that the solution with custom code isn't hard to reach. It'd even be a nice way to get into the whole topic for someone new I guess.

Well, there are serveral issues with that:

• These are localized strings meant to be used for display to the user, not meant to be used in comparisons to decide which error it was. They aren't even unique, though the ones that are most relevant are probably unique.
• There are also around 1000 types, so we can't possible put them all in an combobox. We would instead have to use a subset of them with all the problems that entails. E.g. selecting the right subset, keep the subset up to date.

And looking at the discord the SPELL_FAILED has not come up often. If the API that blizzard provides is this medicore, I would require more demand before I'd want to commit to the maintenance burden.

So imho requiring custom code for this is perfectally fine.

These are localized strings meant to be used for display to the user, not meant to be used in comparisons to decide which error it was. They aren't even unique, though the ones that are most relevant are probably unique.

Does using the global strings, e.g. SPELL_FAILED_LINE_OF_SIGHT instead of " target not in line of sight", not fix that though?

There are also around 1000 types, so we can't possible put them all in an combobox. We would instead have to use a subset of them with all the problems that entails. E.g. selecting the right subset, keep the subset up to date.

Is an edit box with the auto complete feature that was implemented for API a possibility? User starts typing in "mana" and gets recommended all the mana related errors in their language and can choose it themselves. That'd still lead to problems if these errors are indeed not unique like you said, but then the user can just try it out.

Probably a lot of work for a small thing though.

(Did it make sense to type this in any fashion, or do you not see closed issues at all?)

using the global strings means making a "translation" table between an invented id from weakauras to the entry in the global table. that alone means that there must always be an eye kept on those error codes

We could store in the data the global string key (and then compare against exec_env[SOME_KIND_OF_STRING]), so that's not exactly a problem.

That there's hundreds of types is the main blocker, though. We would certainly need to implement a new control if we don't wish to be insanely selective about which strings we provide to the user - shared media dropdowns already create noticeable performance problems with merely dozens of options, a 1000 item dropdown is completely imptactical.