Zugg Software :: View topic

Wizard Joined: 14 Aug 2004 Posts: 1269

First, the way I use %linecol in zMUD is to reset the colours back to what they were at the start of the line in a #SUB (and that is what the documentation suggests it should do). So this is how I would expect it to work in CMUD (and zMUD) for all commands (#SUB, #ECHO, #SAY, #SHOW, etc.).

1.

Posted: Mon Sep 03, 2007 9:31 pm

The problem is that %linecol only supports ANSI color codes. The default text in CMUD 2.x is a "Style" pointer (that's what the 12288 value is). A "Style" cannot be converted to an ANSI color value and cannot be used in the %ansi function.

I'll see if there is something I can do to improve this, but that explains the change and why it isn't working now.

Not sure why #SHOW causes a -1 to be returned, but I'll also look into that since that does sound like a bug.

Edited: The reason why #SHOW returns a -1 is that %linecol is being expanded as an argument to #SHOW before any text has been displayed. So this is normal. There isn't any way to determine the color that the line will be before the text is sent. So %linecol can only be used within a trigger, sorry.

Posted: Mon Sep 03, 2007 9:56 pm

OK, I have fixed %ansi so that it can handle values like 12288 for styles. So, CMUD will still return %linecol=12288 in your above examples, but using it in %ansi will no longer cause the black on black text.

A trickier problem is trying to use the Line Color in a Color Trigger. The Line Color in the trigger options can only be set to an ANSI color. And the "default text" on the screen no longer corresponds to any ANSI color. So you cannot set up a Color Trigger to match lines that start with the default text color. You can only create a Color Trigger to match other lines that start with the non-default color.

There is no way I can fix this to work like zMUD. zMUD used an ANSI color value of 10 (light green on black) for it's default color value. When you modified the default text color in the Color Scheme, zMUD was actually changing the ANSI foreground and background color mappings for ANSI color 10. With Styles in CMUD, CMUD no longer uses ANSI color 10 for default text. CMUD is able to generate it's own "style reference" (the 12288 value you discovered) to link to a specific Style record.

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Tue Sep 04, 2007 12:08 am

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Tue Sep 04, 2007 12:38 am

Nope, there is no way to handle MXP color triggers. There are no ANSI codes for the color triggers, so there is nothing for %linecol, and no ANSI control code you can put in your ANSI trigger. The only way to handle MXP color triggers is via an MXP Trigger directly.

The main problem with all of this is that there isn't an easy way to represent an arbitrary text and background color. Each color is a 24bit value, so the combined text and background color needs 48 bits, which isn't easily stored in a 32-bit based system like Windows. ANSI Color was an encoding to represent 16 foreground and 8 background colors with some extra bits for bold, italic, etc which all fit within a single 16-bit value (original ANSI actually fit into a single 8-bit value without any of the attribute bits, back in the days where each character on the screen was a single 8-bit ASCII code, along with a single 8-bit ANSI color code).

CMUD extended the 16-bit ANSI value to a 32-bit value by adding special bits that tell CMUD to use the lower word as a pointer into the style-list for the current line. I extended that even more in CMUD so that there is a bit to point to a global style list (for stuff like the Default text style).

But there isn't any standard for storing full 24-bit (or higher) foreground and background colors. In HTML, you use a text value like #RRGGBB for each color. But the database field that is used to store the "Trigger Color" value is only an Integer field, not a string field, and not anything larger. So CMUD can only store a 32-bit integer for the Trigger color. And there isn't any standard syntax for specifying the full color within your trigger pattern like there is for ANSI %e[xxm color codes.

So, yeah, someday I'll have to expand the internals of CMUD to handle more than just an ANSI Color value for the Trigger Color. But that's not something that is easy or quick to do. So it isn't going to happen any time soon.

Wizard Joined: 14 Aug 2004 Posts: 1269

I see. This brings me back to an idea I thought of when I was writing this post a few days ago in the Changes to MXP Triggers in v2.0 thread. I didn't post the idea because it didn't seem compatible with the way things are right now, but it struck me as much more powerful than the way MXP Triggers currently work. Basically, it involves taking the principle of your new Telnet triggers (sort of) and applying it to MXP. So you mark the trigger as an MXP trigger, but instead of putting one tag (and optional arguments) into the pattern, you put the entire raw text into the pattern, so for example:

Posted: Tue Sep 04, 2007 1:39 am

This might be something I can think about for the future, but it's a bit more complicated than you mentioned.

First, there is no way to allow more than one MXP tag. MXP Triggers fire on the closing tag. So your above trigger would fire on the , and if there were any other MXP tags after that on the same line, you wouldn't see it in this trigger (you'd get separate MXP triggers for each other tag).

The tricky part is that the syntax:

Wizard Joined: 14 Aug 2004 Posts: 1269

Actually even just allowing nested MXP tags in the pattern would cover many situations.

Hmm, I see, but %0 doesn't help if you want to test something outside of the tags. Can you use #IF(%line LIKE /regex/) for that? For example, I would want to test that the line started with a <.

Posted: Tue Sep 04, 2007 6:59 am

Yes you can, the syntax is #if (%line =~ "%/regex/%") {}.

Posted: Tue Sep 04, 2007 5:02 pm

Fang: Actually, CMUD 2.x supports the new syntax that Seb quotes. You can use /regex/ within a LIKE expression as a shortcut for "%/regex/%" and you can use the LIKE keyword instead of =~ (which is easier to remember for some people). So

Wizard Joined: 14 Aug 2004 Posts: 1269

Actually %line doesn't work when the MXP or pseudo-MXP tag is right at the start of the line - %line contains the value of the previous line when this is the case! This is the case 100% of the time in my MUD. Sad

Bug?

[EDIT: Actually %line contains the previous line even when the MXP tag is not at the start of the line.]

If you do allow capturing the text from embedded tags, maybe that should be an option? Some people may not want to have to strip out other MXP tags...

Posted: Tue Sep 04, 2007 9:45 pm

Actually, yes, you are correct. The normal %line variable is intended for use within normal triggers when the CRLF has already been received. So, in a normal trigger, %line returns the correct data. But in an MXP trigger, the CRLF hasn't been processed yet, so %line still points to the previous line.

You should be able to use the new %line() function with an argument of zero to return the current line: %line(0). This function returns the nth line, where 0 is the current line, 1 is the previous line, etc.

If I capture the raw embedded text with other tags, it will be accessible via some other mechanism. So %0 will always return the data with the tags stripped. I'll probably add an additional record to the %mxp variable to store the raw data. Maybe %mxp.data or something like that.

Posted: Tue Sep 04, 2007 10:23 pm

%mxp.data is now implemented in v2.03. It returns the full data, including embedded MXP tags. It does not contain any ANSI or other control codes however.

(what can I say...I was bored doing bug fixes and wanted to add something fun. See, you too can get your favorite feature added to CMUD! :)

Wizard Joined: 14 Aug 2004 Posts: 1269

%line(0) works! Very Happy

Nice, but, well, as MXP is currently implemented MXP triggers are not very useful to me, so I won't be using %mxp.data in v2.03, unless you also implement a way I can send MXP Line Tags to CMUD from CMUD (or point me in the right direction if it is already possible). Wink

I just tried:
#mxp %char(27)[~#6
I was hoping this might put me into "lock secure mode" so that my XML tags where the closing tag is not on the same line as the opening tag will work. But it doesn't seem to. I have defined the tags as OPEN anyway, but that doesn't seem to be enough.

Anyway, I think that MXP Line Tags are the only part of MXP that cannot currently be done via the #MXP command, so it would be really nice to fix that! Cool

Wizard Joined: 14 Aug 2004 Posts: 1269

Hmm, just to check... If I made a prompt trigger on something like "^<room", then that should fire right away, and I could put CMUD into lock secure mode in the value of that trigger, so that the </room> works some lines later?

Posted: Wed Sep 05, 2007 12:52 am

The first argument of the MXP command is the "z" mode. It defaults to 1 for secure mode. So if you wanted to send a line tag with a tag value of 20, you should be able to do this:

#MXP 20 {mxp stuff here}

Let me know if that doesn't work.

Wizard Joined: 14 Aug 2004 Posts: 1269

Ooooh! #mxp 6 is the business! Very Happy

And quite dangerous! Hehe. [Edit: How dangerous really though? I had a look through the spec and the worst commands for abuse are probably the relocate, sound, music, image and frames tag and, to a lesser degree the dest tag - is that about right? These can be disabled on the client, except that there is a bug meaning that doesn't work.]

I didn't know about that first argument to the #MXP command - that's a change from zMUD, right? It's not in the zMUD documentation.

Now I need to find a secure way to switch modes...

It seems like a prompt trigger on something like "^<room" doesn't work - do prompt triggers need a special char from the mud to determine they are a prompt? How do I get a trigger to fire before the end of a line when it isn't a prompt line?

Hmm, now it's gone all weird! (I made a line trigger to switch to #MXP 6 and an MXP trigger to turn it off with #MXP 0.) It's got permently locked into secure mode and #mxp 0 or 1 won't get it out of it.

Is there any way to see which mode you are in? #mxp does nothing on it's own - it could display which mode you are in...

Wizard Joined: 14 Aug 2004 Posts: 1269

Ah! I see: I need to use #MXP 5 to turn off #MXP 6.

But it seems that #MXP 6 doesn't take affect straight away. It only works on the second paragraph of MUD output. I would half expect it not to work on the current line (if it were even possible to make it fire), but it doesn't seem to work on the next line either. I suppose this is because the MUD sends several lines of output at once, and they are all parsed for MXP before my trigger fires on the first line to switch it into locked secure mode? So in fact, I would need to turn locked secure mode on when I issue a command that may result in some XML? Hmm, that's not going to work very well, since not everything is in response to a command I issue...

Posted: Thu Sep 06, 2007 5:24 pm

For a prompt MUD trigger, just use the same "room" as the trigger name. You don't need the ^ or the < character. Just put "room" in the pattern, and enable the Prompt option for the trigger. That will cause your trigger to fire when the opening tag has been received. It fires when it receives the > character. For example:

Posted: Thu Sep 06, 2007 5:25 pm

Btw, I seem to have lost your original purpose for doing complicated stuff like this. I really wouldn't recommend that you lock CMUD into MXP secure mode like that. What is it that you are really trying to do here? Seems like there should be a cleaner way to do it.

Wizard Joined: 14 Aug 2004 Posts: 1269

Hmm, the problem with the prompt MUD pattern trigger is that it doesn't even fire, even if I just have "room" as the pattern. I guess you mean a prompt MXP trigger, which I hadn't tried - I had forgotten that prompt MXP triggers fired on the opening tag. That does fire, but the problem with that is that I can't check if it starts at the beginning of a line - for a simple security check.

What I am trying to do is to get CMUD to recognise my MUD's XML tags as MXP tags. Currently all of these tags start at the beginning of the line except the </prompt> tag (which is at the end of my prompt). This means the closing tag is never on the same line as the opening tag (except for the prompt tag). And that means I have to be in MXP secure mode for CMUD to accept the tags. So I need a way of entering MXP secure mode during, or as soon as possible before, the opening tag and leaving MXP secure mode right when the closing tag arrives. (This is why I suggested the other week an option on MXP triggers to fix them to the beginning or end of a line, like ^ and $ do with patterns.)

%line(0) with a prompt MXP trigger returns the line above, so that can't be used to determine if the tag started at the beginning of the line. (%line(1) returns the line above that.)

Any other suggestions welcome of course.

Posted: Fri Sep 07, 2007 12:01 am

Yes, you need an MXP Trigger with the Prompt option set. Normal triggers will never see any MXP tags.

OK, I can understand better what you are trying to do now. So it would be better if you could define those "user" tags (the XML tags from the MUD) in a way where CMUD wouldn't close them automatically at the end of a line (sort of what Secure mode does)? Since Secure mode opens up all sorts of abuse possibilities, it seems cleaner to just make a list of tags that you want CMUD to extend beyond one line in Open mode. Would that help?

I'll see what I can do with supporting ^ at the beginning of an MXP trigger pattern to test if it occurs at the beginning of a line, and maybe $ for the end of the line. I can see where this would be hard to determine within your script, but CMUD certainly has this information internally.

Anyway, so would it be a problem if you had to tell CMUD about which tags you wanted to allow via something like this:

#MXP <!ELEMENT MyTag MULTILINE>

where "MULTILINE" would be a new argument that tells CMUD to allow the tag to cross multiple lines in Open mode?

Wizard Joined: 14 Aug 2004 Posts: 1269

I see.

No problems with defining elements like this:
#MXP <!ELEMENT MyTag MULTILINE>

Currently I have been trying:
#MXP <!element prompt FLAG="Prompt" OPEN>
#MXP <!element room OPEN>
#MXP <!element name TAG=10 FLAG="RoomName" OPEN>
#MXP <!element description TAG=11 FLAG="RoomDesc" OPEN>
but I can easily change that!

$ for the end of the line is not so important for me right now, since, as I said, my MUD only has the </prompt> tag at the end of the line (well prompt actually) and that is on the same line as the <prompt> opening tag. So I wouldn't need it, but there may be other people whose MUDs do have xml tags at the end of lines, or my MUD may one day change their XML tags.

But ^ for the start of the line would be awesome!

Will the element TAGs and FLAGs work? This would make it easier for people to set-up their mappers - mine works pretty well now (in zMUD at least), but I spent a long time on my scripts, and it could still be better.