Zugg Software :: View topic - [2.20] ANSI codes not displaying as they should

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I'm sure this has been posted in other threads, but I cannot find an appropriate place to add this info, especially for the current beta.

I was getting prompts where the first stat (health) was displaying as gray rather than green. I captured the packets and made a screenshot. Hope this helps!

Packets in text form
Packets in raw form

Posted: Wed Mar 26, 2008 2:32 pm

Both files seem to be empty :S

Posted: Wed Mar 26, 2008 3:29 pm

I see this as well. Probably an Iron Realm specific issue.

Posted: Wed Mar 26, 2008 4:58 pm

Yeah, I'm not getting anything from your links either.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I fixed the files now. I didn't realize they were still being written to when I uploaded them. I truncated them and uploaded them again. (How do you stop #DEBUGFILE without closing the session?)

Posted: Wed Mar 26, 2008 5:36 pm

Enter the command again with no params. I'll add that to the help if it's not already there (I thought it was).

Wizard Joined: 22 Mar 2007 Posts: 2320

Yes, this has been reported. You'll notice that the problem only occurs when a command from the client to the mud happens between a line coming from the mud and the following prompt. That's the only significant thing about it that I've been able to see. As soon as another color code comes from the mud, subsequent colors are correct. I've been seeing this since the 2.0x betas, I think.

It's definitely not an Iron Realms issue, as I'm on Dartmud which uses ansi colors but not MXP.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I could've sworn that I did a #DEBUGFILE to stop the recording, but maybe I didn't...

It's not just the ANSI prompt that causes oddities, either. I did a command to display the contents of my rift and got a very unsettling result. It looked like the code for black-on-black got somehow stuck because not only did I not see my rift contents, I didn't see anything after it for a few dozen lines. I had to move in a direction to get the colors to return to normal. The text was all there because I could highlight it. I can't reproduce it reliably, or I'd post that one, too.

Posted: Thu Mar 27, 2008 1:34 am

I'm beginning to think I have every single one of the display type issues I've seen mentioned on the forums.

Larkin, the disappearing text has another topic already started:
http://forums.zuggsoft.com/forums/viewtopic.php?t=29511

I'm able to reproduce that effect pretty easily and I sent in a raw debug log with it logged for Zugg's viewing pleasure. He replied back on the thread saying he had it, but hadn't looked at it yet.

Wizard Joined: 17 Jun 2006 Posts: 1201

Chuckle...

http://forums.zuggsoft.com/forums/viewtopic.php?t=29354&highlight=

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I knew it was posted before, and I just couldn't find it. Thanks for helping me aggregate the discussion, guys. Smile

Posted: Thu Mar 27, 2008 7:26 pm

OK, this specific problem in Larkin's debug files was *not* an IRE issue. So I think there are several bugs causing ANSI color issues that I need to pin down. I was able to reproduce the specific issue that was causing Larkin's color to get reset to gray at the beginning of the prompt. The bug was at a pretty low level in the ANSI display routine, so it's possible that this will also fix some other issues like this. But this was *not* the same as the packet boundary issue, and I don't think it was the same as the bug that sometimes causes ATCP text to be displayed in the main window. I'm still trying to pin those down.

The bug itself was pretty simple...an index into one of my arrays that was starting at zero instead of one. Changing this fixed this specific problem, and hopefully doesn't break anything else as a side effect. But this low-level code is very tricky so I'll have to wait until I release the next Beta to see if it's really fixed for everyone.

Now I'll move on to the packet boundary and ATCP stuff.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Awesome! Thanks, Zugg.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Version 2.21 is far better with ATCP and ANSI codes now, but I just noticed this and thought it worth mentioning. The word "mounds" appears gray when it should be cyan like the text before it.

I use the "wrapwidth 0" setting on Lusternia, so there are no added CR/LF characters to do the server-side wrapping. The colors being displayed in CMUD seem to be effected by its own wrapping or something like that.

Posted: Mon Mar 31, 2008 7:31 pm

I was able to reproduce this finally. I had to turn off the Indent value for wrapped lines, and then get my font set the same so that it would wrap at exactly the same spot. So this was very tricky, but hopefully I can fix it now. There was a previous bug reported with the ANSI color of wrapped lines, but I wasn't able to reproduce it from the other post. So thanks for the dump of the exact MUD text and the sample screen shot that went with it. Those are the kinds of detailed pieces of information that really help when trying to reproduce a tough bug.

Posted: Mon Mar 31, 2008 8:03 pm

Found it! This was an interesting one...

When CMUD wraps a line, it needs to determine what attribute records are used on the wrapped part of the line. Each line in CMUD has a list of attribute records used on the line. So when "mound" is moved to the next line, the attribute record for it needs to be copied to the list for the next line too.

But CMUD also has some optimization regarding attribute records that are not used for any text. For example, if the MUD sends [32m33m then since there is no text with the "32" attribute, no attribute record for that ANSI code is added to the line. CMUD does this by keeping track of how many characters in the line use the specified attribute. If CMUD receives a new ANSI code and the "count" for the current attribute record is zero, then the current record is overwritten with the new ANSI code info.

So, when CMUD wrapped the line, it made a copy of the attribute record for "mound" and put that into the next line. But the "count" property for this newly copied record was zero. In your specific case, there was an [37m code right after the word "mound". When CMUD saw this, it also saw that the "Count" of the current attribute record was zero, so it overwrote the current attribute record with the new 37m code (which is the code for gray text).

The fix was to properly count the number of characters in the wrapped line that referenced the new attribute record copy so that the Count property wasn't zero.

This bug would be triggered anytime a line wrapped when there was an ANSI code after the wrapped text, so it could be responsible for several other reported ANSI problems. Also, it looks like this same bug was also present in zMUD.

Anyway, it should be fixed for the next version.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Awesome! Thanks again. Smile