Mudlet Question?

MisterWildCard

I created a label ( https://hastebin.com/likijetede.js ), and I cannot, for the life of me, figure out how to make it pull up my target. Just says
Target: target()

Am I missing something?

Also, is there a way to temporarily highlight my target? So, if I target Paul, Paul is in red or orange font anywhere it pops up? It seems like it would be part of the target alias, but that is also beyond me, as mine currently looks like: https://hastebin.com/lehopopuqe.makefile

Thanks!

EMDA

I think you might want to try changing:

message = [[<span><center>Target: target()</center></span>]]

to:

message = [[<span><center>Target: ]] .. target() .. [[</center></span>]]

and see if that works any better. Right now you're just sending the text "Target: target()" to the label. This will require your target() function to return the value of your target variable, otherwise you'll want something like [[<center>Target: ]].. target .. [[</center>]] instead, assuming 'target' is right variable. It's been a long while since I've used Mudlet so that might not be totally accurate, though.

I was going to go to the Mudlet API to refresh on tempTriggers for your second question and it turns out their first example handles your exact question.

MisterWildCard

Ooooh!
Thanks for that! 

Maruna

You don't need the () when calling the target variable. Unless you have a function called target() in which case you should probaby change that. Can't have a variable and a function with the exact same identifier name.

EMDA

EDIT: I only needed to say it once!

EMDA

EDIT: I only needed to say it once!

EMDA

EDIT: I only needed to say it once!

Illidaen

For some reason, I can't always capture every target's long name when trying to echo certain things they do and I'm trying to find the right wildcard(s) for it. Like for example:

A female tangutan has cured the effects of Frozen.

Some mobs with multiple matching words work fine for the echo go through, and some don't.  Can anyone check what I should have instead for this?

^(?:A|An) (.*) has cured the effects of Frozen\.$
cecho("\n<gold>|+|A STACK OF FROST CURED|+|")

Indi

Please post examples of lines that do not fire.

Tye

 (.+) has cured the effects of Frozen\.$
^(?:A|An)

That ought to work.

Illidaen

Not sure what he means, but it didn't fire for me.  Also, thanks for that, Tye!

Quell

Don't capture (?:A|An). You're going to run into a mob with a name that doesn't follow the format, and your triggers will be useless all over again. Just use (.+) to capture the whole name, there's no need to be afraid of it.

Indi

He's not capturing A or An. The ?: makes the grouping ( ) only for grouping and not for a capture group. 

Although, it's  easier to do:
An? 

For that matter, why bother with regex at all? He's not using the capture group for anything.

has cured the effects of Frozen

As a a sub string and be done with it.

Jonathin

Because that is lazy. Complexity is the key to making sure it works, right? ^(?:[A])(?:[n])?

Eta: that is facetious. It is probably a good idea to not use that

Avymos

@Indi said:

He's not capturing A or An. The ?: makes the grouping ( ) only for grouping and not for a capture group. 

Although, it's  easier to do:
An? 

For that matter, why bother with regex at all? He's not using the capture group for anything.

has cured the effects of Frozen

As a a sub string and be done with it.

Quell was referring to the fact that mob names don't always start with a/an, and that line won't trigger at all in those cases. Not to the fact that capturing a/an separately would be pointless.

+1 point for pedantry, though.

Indi

Avymos said:

+1 point for pedantry, though.

Was just being helpful with regex... quell possibly didn't know about ?:

Maybe he/she does, and it was just worded unclearly. Hard to say, and doesn't actually matter because other people are reading and someone may find it helpful...

My post shows an easier way to achieve (A|An), and a way to achieve what Quell suggested without using regex at all.

Not everyone who posts is trying to one-up the people that posted previously. A help question isn't a competition.

Maruna

Probably shouldn't use substring triggers on their own, outside of multi-line triggers (which are combined with exact match/begin of line types, generally). It's generally bad practice. Even if it's a pretty obscure line, that is unlikely to pop up in other places, it's still an awful habit.

Indi

I tend to agree with you, Maruna, though in this case the substring version is more efficient and functionally identical to:

^.+ has cured the effects of Frozen\.$

Maruna

A substring is never 'more efficient' than a regex check, by virtue of substrings checking every part of a line to see if there's a match.

That's like saying using a weedwhacker to trim your lawn, is more efficient than just using a lawnmower.

Indi

Maruna said:

A substring is never 'more efficient' than a regex check, by virtue of substrings checking every part of a line to see if there's a match.

That's like saying using a weedwhacker to trim your lawn, is more efficient than just using a lawnmower.

You need to talk to the mudlet devs (vadi essentially), who say otherwise.

Substring types do not engage the regex engine at all, and while they are slower to reject than 'begin of line substring' type, the regex engine deals with wildcards etc. The trigger engine rejects substring types faster than regex types.


Also, in the regex pattern being discussed, opening with:
.+
The text part is acting like a substring type anyway. All the downsides you refer to while also using the slower regex engine.

Maruna

Indi said:

Also, in the regex pattern being discussed, opening with:
.+
The text part is acting like a substring type anyway. All the downsides you refer to while also using the slower regex engine.

Except it's not. The carat at the start automatically makes it not act the way you're describing it; if something at the start of the line doesn't match, then the trigger doesn't need to check anything else. Whereas a substring trigger would run through the entire line, if it's not part of a multi-line trigger.

Checking against defined parameters is more efficient than checking against everything that shows up.