Zugg Software :: View topic - [2.03] <send> tags in #SUBs within undefined MXP elements cause loss of ANSI col

Wizard Joined: 14 Aug 2004 Posts: 1269

This is a new problem not found in 2.02. My MUD has an XML mode that can be switched on that adds tags to certain blocks of text. But it still uses ANSI colour, not MXP or XML for colour.

I have some triggers that add a <send> tag around the first word on a couple of these blocks of text. In 2.03, when I turn on XML mode, with the XML tags not yet defined I notice that the ANSI color is lost from these lines. If I define the XML tags with the new MULTILINE parameter, the colour comes back, but that doesn't mean there is not a bug here, and many people will not yet know about this new feature or how to use it.

Let's take an example:

Trigger pattern:
(%x) narrates '(*)
Trigger value:
#SUB {"<send 'whois &text;' 'whois &text;'>"%1~</send~> narrates '%2}

With MXP debug off, some output looks like this:

CharX narrates 'anyone spare 30 goild for ssm' in Westron.
</narrate>

But it is in my default colour, rather than the colour it should be.

If I turn on MXP debug we see what is going on:

<send 'whois &text;' 'whois &text;'><narrate>CharY</send> narrates 'so was there an elf around lorien?' in Westron.
</narrate>

We see that the <send> tag has turned up BEFORE the <narrate> tag. I think this is what is causing the problem. In any case, it should not be the case, since the line actually starts with a <narrate> tag, and I am substituting a <send> tag right before the name of the character who is doing the narrating. So I would have expected this:
<narrate><send 'whois &text;' 'whois &text;'>CharY</send> narrates 'so was there an elf around lorien?' in Westron.
</narrate>

As to whether that in itself would have fixed the ANSI colour issue, I can't be certain of course. But if I define an MXP MULTILINE element for narrate (which sort of removes the narrate tags), the colour is fixed...

(I currently have no MXP triggers, although I do have some triggers that are currently disabled to SUBSTITUTE out (i.e. GAG) the XML tags which I would use before the MULTILINE parameter if I was in XML mode.)

Win XP Pro SP2

Posted: Mon Sep 10, 2007 8:50 pm

You can't trust the MXP debug output in this case. This is because your #SUB trigger is run after the entire line has been received from the MUD, and with MXP Debug turned on, your trigger is getting the tag as part of the text.

In other words, with MXP debug turned on, your trigger is getting "CharY" as the value of %1.

To test this on my system here, I need the normal #DEBUG files from

#DEBUG test.txt test.raw

that would actually contain the raw MXP commands being send from the MUD. This would allow me to replay the MUD output with your triggers to see what the problem is.

Or, you might just need to change your (%x) so that it doesn't match the starting tag.

Just always remember that normal triggers always pull the text to be matched from the screen itself. So if the tags are shown on the screen, then you are going to get them in your trigger text. Only MXP Triggers can pull the raw data before it gets to the screen.

Wizard Joined: 14 Aug 2004 Posts: 1269

"CharY" *should* be the value of %1, and indeed it is with MXP debug off. With MXP debug on, %1 is "<narrate>CharY" (minus the quotes). The trigger is working fine, except for the fact that the ANSI colour is lost *and* the opening narrate tag is not displayed when MXP debug is switched off, when the MXP element is undefined. I only just noticed that the opening narrate tag is also not displayed. This would be displaying in zMUD and in CMUD 2.02, and I would expect it to be displaying here too.

Hmm, in CMUD 2.02, %1 = "<narrate>CharY" even with MXP debug off. If I change the %x to %w, %1 goes back to "CharY" (but all the text following "CharY" becomes invisible - this issue was fixed in 2.03).

Debug files sent.