Rakon wrote:I'd really like to see this functionality in Mudlet.
As it stands, I have a trigger in MUSHclient that matches a variable.
Match: \b(!@enemies)\b
Color: red
Regex: y
1. I have made an enemy highlighter demo package. It's somewhere in the package forum. I tested it with 2500-5000 names and had virtually no lag. It'll show you how to do this efficiently in Mudlet.
2. Mudlet has variable triggers too, as it lets you trigger on the return value of arbitrary Lua code. -> pattern type Lua function. This type of trigger will fire whenever the code returns true.
e.g. the trigger "if myImportantVariable == 2948 then return true else return false end" will fire when myImportantVariable equals 2948
Thank you for the responses, however I do believe naftali you missed the point of my post.
I do not want to output a list of enemy names. I already know the list of enemy names. I want to highlight any name from the list, in Mudlet, if it's shown in output. The reason I want a list/table and not a trigger for every single name is because I'd like to add/remove names from the list easily. I don't want to reecho the names when the name trigger is matched already.
Heiko:
Regarding 1) I'll look over your package again, and see what it does to make the highlighting efficient in Mudlet.
Regarding 2) Variable triggers, as I was mentioning meant triggers that match on the contents of a Variable.
IE, I'd like to be able to match '(@!target) applies some salve.$' , and only echo something that first grouping matches the contents of the variable 'target'. I'd like to be able to achieve it without using an 'if matches[2] == target' in every trigger I'd use the (@!target) on.
My enemy list highlighter (posted on forums) highlights all 1.8k of mhaldors enemies, just fine with no lag.
I don't believe in introducing the 'variable triggers' inefficiency for a lot of work when you can do it in a script just fine (and not die, it's not 100 lines of code). watching for variable chances and dynamically recompiling triggers isn't all that exciting.
maybe mush doesn't do that, it has a different sense of efficiency - it preprocesses, compiles and runs code for the trigger it matches. in mudlet, all code is pre-compiled and only the bytecode is run when a trigger matches.
I can understand why you don't want to implement the code to process a trigger based on variable information, as it's surely a lot of work and probably not totally efficient.
However, I haven't found an efficient way to highlight all occurances of a variable in a capture efficiently without using the dreaded "use a trigger to capture every single word that comes through the network and try and match it using scripting" method.
Also, using this method has brought up a question of trigger priority. Does a trigger firing stop other triggers from firing on that same line? What if I have four triggers that all want to capture on the word "the" (for some absurd reason)?
Will only the first trigger and the rest be ignored?
If not, how can you set up the order in which the triggers will fire? Is it random? What if i want trigger a to fire before trigger b?
Vadi wrote:tempTrigger is your solution, just create a trigger for every name - works faster than in other clients.
I've managed to get this working, but only to capture the -first- instance of the highlighted word, not all of them in a line. I've been stumped as to how to get this to capture -all- instances of the word on a line.
if you could send me a trigger showing me how this is done without a \b\w+\b trigger, I'd be grateful.
Vadi: It's great that you've released a package to do this for people.
Still asking how we can get it done on our own, without using another's code (that we might not want to have in our system, or don't understand how it works) and getting the same answer of 'I have a package that does this already' is frustrating.
How does your package work, what does it do that makes it efficient? Why do we have to use a temptrigger for every single name versus a regular expression? What if we want to (as Tsuujin stated) have more than one name highlighted on the line? What if we do not want to use a multitude of temporary triggers to highlight a simple word match trigger? What is the issue with the order of triggers, only matching once in order of 'visual appearance'? Why do temptriggers match in order of creation then? Do I have to create this list of temptriggers for the name highlighter every time I start a session??
Sort of related note as well, why do I have to explictly tell Mudlet to remember a variable for the next session in a script function, why is there it not done already, or at least a visual dialog to see variables easily?
I know this is 'The Mudlet Way', but why?? Is actually using a function of ~100 lines necessary to make the speed that much better for the end user??
I'm really tempted by the screencast you posted of output speed in Mudlet Vs MUSHclient, though without at least a few of these things working as expected, or at least in an easier fashion, I can't really justify switching from MUSH.
How does your package work, what does it do that makes it efficient? Why do we have to use a temptrigger for every single name versus a regular expression?
You want to create regular expressions on the fly? Go ahead, we have tempRegexTrigger... I didn't test it out, but substring matching is faster than a huge regex.
What if we want to (as Tsuujin stated) have more than one name highlighted on the line?
You call selectString multiple times, until you get a selection of -1, when your trigger matches. That way, your trigger matches once per line, but you highlight all words on that line. Takes 5min to look at the code to see that it indeed does work properly and not break as soon as the first match is found.
What if we do not want to use a multitude of temporary triggers to highlight a simple word match trigger?
Don't? Your choice.
What is the issue with the order of triggers, only matching once in order of 'visual appearance'?
There is no issue... that is their order.
Why do temptriggers match in order of creation then?
Sort of related note as well, why do I have to explictly tell Mudlet to remember a variable for the next session in a script function, why is there it not done already, or at least a visual dialog to see variables easily?
Because a) you'd have lots of junk lying around without a visual dialog and b) no visual dialog because unlike mush, mudlet doesn't implement an inefficient and cumbersome to use variable server. Mush doesn't display your lua variables, neither does mudlet.
