A better way to do this is via perl lookahead and lookbehind regular expressions.
However, that only works if you have one of the recent zmud Versions, 7.01 onwards I think, that feature perl syntax triggers. 7.04 has them.
Say you want to color "in" but only if it's not inside a word like "inside", you'd do this:
(note how it says #REGEX, rather than #CW or #TR, you need to use regex so zmud knows you want a perl trigger. Alternatively select "perl regular expression" in the trigger editor)
Basically what you do here is tell zMud that the trigger should match the word "in", but only if there's no letters directly before (?
If you can't use perl triggers for some reason, you'll have to supply a number of delimiters that might follow the word you want to trigger, because it'll not always look like " in " but could also be "in," or "in!", which won't all be matched with { in }.
A way to do this without having to create a whole bunch of reflexes each with a different delimiter is to supply a delimiter list, like this:
However, this method has some drawbacks, for one you'll get in trouble if the word you want to color can also come with a linebreak right before or after it.
Also if you use the code above you'll not only color "in" but something like "in," or "in?". Granted, if you have spaces as delimiters, that doesn't matter, unless you color the background aswell, which you want to do apparently. duh.
If you can, use the lookahead and lookbehind trigger, it works much better than the delimiter list thing. Plus it's so much more elegant
-David
However, that only works if you have one of the recent zmud Versions, 7.01 onwards I think, that feature perl syntax triggers. 7.04 has them.
Say you want to color "in" but only if it's not inside a word like "inside", you'd do this:
CODE
#REGEX {(?
(note how it says #REGEX, rather than #CW or #TR, you need to use regex so zmud knows you want a perl trigger. Alternatively select "perl regular expression" in the trigger editor)
Basically what you do here is tell zMud that the trigger should match the word "in", but only if there's no letters directly before (?
If you can't use perl triggers for some reason, you'll have to supply a number of delimiters that might follow the word you want to trigger, because it'll not always look like " in " but could also be "in," or "in!", which won't all be matched with { in }.
A way to do this without having to create a whole bunch of reflexes each with a different delimiter is to supply a delimiter list, like this:
CODE
#CW { in{ |,|.|!|?}} bold, green
However, this method has some drawbacks, for one you'll get in trouble if the word you want to color can also come with a linebreak right before or after it.
Also if you use the code above you'll not only color "in" but something like "in," or "in?". Granted, if you have spaces as delimiters, that doesn't matter, unless you color the background aswell, which you want to do apparently. duh.
If you can, use the lookahead and lookbehind trigger, it works much better than the delimiter list thing. Plus it's so much more elegant
-David
Zaltan, you're lame 
(Yes, Zaltan, and maybe others, might know what I'm talking about it, but most of you won't...)
(Yes, Zaltan, and maybe others, might know what I'm talking about it, but most of you won't...)
An imposter!Too bad you don't have your automobile to drive away in now.
On another topic - what's up with all these new emoticons? They're too... animated. E.g.:
:cm:
@Zarquan: Sure, if it does what you need...
Me I dislike how adding delimiters to a trigger pattern that gets colored will color the delimiter along... that's a bit messy especially if you have a bracket as a delimiter. zMud has a few bugs with coloring things, sometimes it colors too much, or the same number of letters just one line below the line it actually triggered...
(On a sidenote, I -think- the perl regex pattern matches faster than using zMud's %s-like wildcards, which might be interesting on large systems, I haven't actually ran benchmarks though. Just my impression)
Basically, try go with the easiest solution that does what you need, the more complicated the more likely it'll screw up... (I personally do think having a lookahead/lookbehind is pretty simple but meh)
@Daganev: That's the kind of triggers that made me figure out the perl stuff in the first place I've been trying to do neat name coloring for years and perl does it just perfectly 
Same syntax as before, just replace "in" with (?:@listofnames)
-David
P.S. on a related topic, has anyone of you figured out a way to do something like this:
#TR {{@guildnames|@allies}}
{#cw %if(%ismember(%1,@guildnames),6,%if(%ismember(%1,@allies),10))}
(What I'm trying to do is having a single trigger that matches for all names of importance, guildmates allies citizens etcwhatnot, and then have the trigger decide which list that name comes from and how to color it)
Problem with that kind of trigger is, zMud only really gives the correct matched parameters the first time the trigger fires on a line, but if it fires again on the same line then it'll give the parameters as before, rather than the parameter it fired on now.
Like, if Nikua is my enemy and Visaeris is my ally, and I have a line like this:
Nikua viciously jabs a rapier into Visaeris!
I'd end up coloring both Nikua and Visaeris as enemies, because the trigger first matched Nikua and found him an enemy, then matched Visaeris and got the wrong parameter and found him an enemy again...
Anyone know how to do this?
I'm currently using a separate trigger for every names list and put those into stacked classes to determine which coloring should show up dominantly (allies should be colored as allies even if they're citizens too, etc)
Me I dislike how adding delimiters to a trigger pattern that gets colored will color the delimiter along... that's a bit messy especially if you have a bracket as a delimiter. zMud has a few bugs with coloring things, sometimes it colors too much, or the same number of letters just one line below the line it actually triggered...
(On a sidenote, I -think- the perl regex pattern matches faster than using zMud's %s-like wildcards, which might be interesting on large systems, I haven't actually ran benchmarks though. Just my impression)
Basically, try go with the easiest solution that does what you need, the more complicated the more likely it'll screw up... (I personally do think having a lookahead/lookbehind is pretty simple but meh)
@Daganev: That's the kind of triggers that made me figure out the perl stuff in the first place
I've been trying to do neat name coloring for years and perl does it just perfectly Same syntax as before, just replace "in" with (?:@listofnames)-David
P.S. on a related topic, has anyone of you figured out a way to do something like this:
#TR {{@guildnames|@allies}}
{#cw %if(%ismember(%1,@guildnames),6,%if(%ismember(%1,@allies),10))}
(What I'm trying to do is having a single trigger that matches for all names of importance, guildmates allies citizens etcwhatnot, and then have the trigger decide which list that name comes from and how to color it)
Problem with that kind of trigger is, zMud only really gives the correct matched parameters the first time the trigger fires on a line, but if it fires again on the same line then it'll give the parameters as before, rather than the parameter it fired on now.
Like, if Nikua is my enemy and Visaeris is my ally, and I have a line like this:
Nikua viciously jabs a rapier into Visaeris!
I'd end up coloring both Nikua and Visaeris as enemies, because the trigger first matched Nikua and found him an enemy, then matched Visaeris and got the wrong parameter and found him an enemy again...
Anyone know how to do this?
I'm currently using a separate trigger for every names list and put those into stacked classes to determine which coloring should show up dominantly (allies should be colored as allies even if they're citizens too, etc)
That's odd... I've always had that issue, with all versions of zMud I've used so far... I don't even think it's a zMud thing, other clients seem to do the same... If a trigger provides parameters, it'll only "feed" the parameters once and if the trigger fires again on the same line, the "old" parameters are still used... I just tested it again, same thing. *cringe* that sucks.
I couldn't even solve it by using temp triggers that run an alias that create a new temp trigger so it's actually a new trigger that gets executed every time... then I just run into trigger loops. And delays won't work here 'cause that'd mean zMud won't match it again on that line.
And reparse/within lines multistates don't work 'cause zMud ends up matching the first instance again and again. gah.
I couldn't even solve it by using temp triggers that run an alias that create a new temp trigger so it's actually a new trigger that gets executed every time... then I just run into trigger loops. And delays won't work here 'cause that'd mean zMud won't match it again on that line.
And reparse/within lines multistates don't work 'cause zMud ends up matching the first instance again and again. gah.
