Zugg Software :: View topic - [2.18] MXP Colors Bleed Across Multple Lines

Novice Joined: 18 Dec 2006 Posts: 47

I'm having an issue with MXP aliases such as the following:

#mxp ~<color lightgrey darkblue>* %-1 *~</color>
#CR

When they are executed either in triggers, or by directly calling the alias, the color often bleeds onto subsequent lines until another #MXP command is encountered. Sometimes this fixes the problem, or continues to highlight all lines in the new color.

Posted: Mon Jan 07, 2008 3:29 am

I tried this for quite a while and didn't encounter any problems. Something more complex must be going on, perhaps an interaction with another MXP trigger, or with certain contents of the %-1 variable?

Novice Joined: 18 Dec 2006 Posts: 47

I've been playing around with this trying to figure out how to recreate it, and haven't had much luck as far as determing what's causing it. Here are a couple of examples.

1. Text goes all black after a blank line. This doesn't seem MXP related, but may help indicate the root problem. At times all text on the screen except for the commands I'm entering turns black. It is still there, as CMUD is still processing it, and it can be copied and pasted elsewhere. This seems to happen most often after a command that would result in a blank line, such as 'qwho' with no one in the area as shown here.

2. This time, I finally got the highlighting to break, and the rest of the text to turn black at the same time. This is the first time I've seen this. This lasted for about a minute or so, before finally fixing itself. No special color command was executed before this corrected itself... I'm not sure what happened. The reason for the highlighted lines is that I have a trigger that whenever it sees the value currently stored in @targ (my current target) that it will highlight that word. In this case, vampire is the target, and should be the only word highlighted (as shown in the first line.)

Posted: Mon Jan 07, 2008 11:36 pm

I would need to get a dump of exactly what the MUD sends when this happens. You can use

#DEBUGFILE test.raw test.txt

to create dumps of the raw MUD text and then send me the two files when you see this problem occur. Otherwise this kind of problem is almost impossible to pin down.

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

I see this with CMUD line wrapping as well. I've tried to pin it down but can't lay my finger on it.

out ( 39) 01/10/08 17:16:42:358 : say seems to be where a space happens?<CR><LF>
in* ( 405) 01/10/08 17:16:42:812 : <ESC>[0;1;37m<ESC>[0;1;36mYou say, in the dark language of the cow '<ESC>[m<ESC>[1;30m<ESC>[33m<ESC>[37m<ESC>[m<ESC>[32m<ESC>[m<ESC>[1;32m<ESC>[37m<ESC>[m<ESC>[33m<ESC>[32m<ESC>[33mseems to be where a space happens?<ESC>[m<ESC>[1;36m'<LF><CR><LF><CR>

This wraps all in brown as it should.

out ( 15) 01/10/08 17:16:47:249 : say test test<CR><LF>
in* ( 376) 01/10/08 19:50:53:374 : <ESC>[0;1;37m<ESC>[0;1;36mYou say, in the dark language of the cow '<ESC>[30m<ESC>[33m<ESC>[37m<ESC>[m<ESC>[32m<ESC>[m<ESC>[1;32m<ESC>[37m<ESC>[m<ESC>[33m<ESC>[32m<ESC>[33mtest test<ESC>[m<ESC>[1;36m'<LF><CR><LF><CR>

When wrapped I get a brown test then a cyan(default color) test in the line above. The wrapping occurs after the space on the first word test.

I'll keep my eye open.

Edit: pasted wrong attempt!

Posted: Thu Jan 10, 2008 7:15 pm

I see this at times as well, but I have no reliable way of reproducing it.

Posted: Thu Jan 10, 2008 7:28 pm

I took some time and logged it and took a screen capture just as Zugg requested. I e-mailed it to support.

Newbie Joined: 10 Mar 2008 Posts: 7

I am having similar issues it happens quite often, and only with zMUD. It goes away once I start doing things. The colour codes are kinda new used to just colour many lines of output. It happens consistently. All the other colour triggers and text from the mud work fine.

Posted: Mon Mar 10, 2008 5:27 pm

If it only happens in zMUD and not CMUD, then it's likely one of the hundreds of bug fixes from zMUD to CMUD. Please only report CMUD problems in this forum, thanks.

ReedN: I still have your test files and still plan to look into this, but I don't know if it will be fixed in the next version or not yet.

Posted: Mon Mar 10, 2008 9:36 pm

Martym -- that particular issue is with bad implimentation of user colors in Discworld, someone didnt reset the color on thier titler string

if you type in 'term mxp' it should go away

This is a discworld only fix for the discworld only problem

Posted: Thu Mar 27, 2008 1:31 am

This certainly happens on Cmud. I never saw this happening on Zmud and the files I sent in are from Cmud 2.18.

Posted: Thu Mar 27, 2008 5:43 pm

ReedN: I was not disputing your error. As I said, I have your test files and your issue is on the bug list. But the specific issue that martym posted about is a different issue and is a Discworld issue as mentioned by shalimar. Even though it might look like the same issue to you, it's not.

Posted: Thu Mar 27, 2008 7:38 pm

Btw, just testing this thread again. I tried the stuff TonDiening posted and couldn't get it to fail in v2.20. I tried resizing the window so that it would wrap between the two "test" words, but I never got it to display in cyan instead of brown. So if that problem still exists in v2.20, please create a new post with more debug dump details.

But I also need to rant just for a bit...Have you guys taken a close look at the raw input from TonDiening's dump? Look at all of that extra ANSI code crap that isn't doing anything at all. Stuff like:

<ESC>[30m<ESC>[33m<ESC>[37m<ESC>[m<ESC>[32m<ESC>[m<ESC>[1;32m<ESC>[37m<ESC>[m<ESC>[33m<ESC>[32m<ESC>[33m

What is the purpose of all of those ANSI codes? Looks like whatever MUD is outputting this stuff really has some code problems. They are changing colors and then resetting them without ever outputting any text between the color changes. Looks like the code base for this MUD is really messed up.

Also, I noticed the <LF><CR> in the dump instead of <CR><LF> which also tells me that this is one of those MUDs who don't even understand the basic Telnet protocol and are sending LFCR instead of CRLF. CMUD handles this, but it just amazes me that MUDs with this kind of problem still exist and are running and nobody has ever cleaned it up and fixed it. It's the kind of sloppy server coding that really annoys us client developers!

Posted: Thu Mar 27, 2008 8:01 pm

Btw, I just found the packet boundary bug. And I don't think it was related to the problem where ATCP text sometimes gets displayed.

The specific packet boundary bug that I just fixed only occurred if the MUD sent a series of *more than two* ANSI codes, and the packet boundary occurred before the semicolon of the final code. For example:

Packet 1: <ESC>[1;31
Packet 2: ;40mtext

Since this only happened when the MUD sends more than 2 codes (which is rare by itself) and then only when the packet was broken in exactly this spot, this was a pretty obscure bug and I doubt very many people were running into it. Fortunately I had a very detailed debug dump from someone that showed this problem.

ReedN: The dump that you sent didn't have any packet boundary issues and it looks like it was the same as the original poster in this thread, which should be fixed by the other ANSI bug fix that I found today. You'll have to wait and test it in v2.21 and see if it works better.