Zugg Software :: View topic - [2.27] #SUB and ANSI colored triggers wierdness

Wanderer Joined: 29 Jan 2008 Posts: 63

I run into this problem when I tried to dig this topic: ANSI colors
I decided to create a separate thread because I'm not sure what is going on.

Since a prompt from my mud is not terminated by "new line" the incoming text is often joined the prompt. I'm trying to make a trigger that splits it into two pieces, the prompt and the other text.
It looks like #SAY output falls into this category as well so it is joined the prompt line.
I'm trying to preserve text colors (and prompt colors) and I also need to process additinal text after a prompt as usual mud output, so I use #SHOW to mimic it.

Here is the regex trigger I'm playing with:

Wanderer Joined: 29 Jan 2008 Posts: 63

Can any gurus comment what's going on here? Why this trigger heavily changes its behaviour when I play with options?
Is it a bug or there are other explanations to it?

Posted: Wed Jun 18, 2008 5:35 pm

The answer, broadly, is "don't use #sub in ansi triggers". If you really need to use #sub, use a reparse state attached to the original trigger. Because there're characters in the trigger pattern that don't appear in the text on the screen (or something), it screws up the counting and causes the wrong text to be subbed. So don't use it.

Your third example is, I guess, because the subbed text causes the trigger to fire again. Not sure if that's a bug or not.

Wanderer Joined: 29 Jan 2008 Posts: 63

I tried to replace #SUB with #GAG and #SAY.
But it looks like say-text is processed by the same trigger again (and sometimes fall into a loop because of it). Why? I thought that #SAY text should not be parsed.
Or it's some kind of side effect of GAG/SAY pair?

Posted: Mon Jun 23, 2008 10:28 pm

#say is parsed. #print isn't.

Wanderer Joined: 29 Jan 2008 Posts: 63

Now I'm confused even more Very Happy

I tried to play with standalone #SAY and my triggers SOMETIMES don't fire at all (as they will fire on #SHOW).
However when I use #SAY after #GAG in my trigger above the script debugger pretends that say-text causes the this trigger to fire again and again.
What is the trick?

Wanderer Joined: 29 Jan 2008 Posts: 63

Hrm, it looks like say inserts ESC[1S before the text so ansi triggers with patterns like ^xxx do not fire and normal triggers fire.

Posted: Mon Jun 23, 2008 11:10 pm

Well, that's true! If you are using an ANSI color trigger and you put ^ at the beginning, you are telling CMUD to only trigger on text that has the default color. #SAY doesn't use the default color...it uses the command echo color style. The ESC[1S is this style code. So this actually allows you to create color triggers that only fire on #SAY and not other text. This is a feature.

If you want something to fire on text regardless of color, then don't use an ANSI color trigger.

Wanderer Joined: 29 Jan 2008 Posts: 63

By the way, what is the right way to print something with default color? Right now I'm using #PRINT ESC]0S.... but I feel like a haxor.

Posted: Tue Jun 24, 2008 6:43 pm

The #SHOW command will print in the default color. Using ESC[0S is a bad idea since that is an internal ansi code (not a standard) and might change. If you must use styles right now, then the more standard way to do it would be the MXP command:

#MXP <STYLE 0>text</STYLE>

This is the syntax that will be used when user-defined styles are implemented in the future. But for now, #SHOW should work fine.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Posted: Tue Jun 24, 2008 11:56 pm

Yeah, I always forget that HTML tags are enabled by default for me (as an Admin of the forum)

Wanderer Joined: 29 Jan 2008 Posts: 63

For my purposes I need some way to print text with default or other color which is not processed by triggers. #MXP/#SAY/#SHOW may not be very good for that.

Posted: Wed Jun 25, 2008 4:49 pm

OK, that's actually pretty simple then. Use the %ansi(reset) function to reset the color to the default. This works with #PRINT:

#PRINT {%ansi(reset)This text is in the default color}

That works and prevents you from needing to know the low-level escape codes.