Zugg Software :: View topic

Beginner Joined: 01 Nov 2006 Posts: 27

Sometimes ansi colors are changing on me in the output window.

For instance... something that I know to normally be bold red, if i 'look' in a room over and over, every once in a while it will show up bold blue, or plain white, or cyan, etc.

I remember seeing this rarely before I upgraded to 3.31, but now it seems to happen much more often.

Posted: Thu Oct 21, 2010 5:36 am

I have been trying to track this bug for over a month now with no success. At first I thought that it was an MXP problem since this is where I discovered the problem, then I thought it was a problem with the %ansi function. Now I use raw TELNET control sequences and the problem persists. If you can show me some of the stuff you are sending to the output window and what the color transformation is I might be able to get some ideas. You are right about the release being recent, I saw it appear in 3.24.

Beginner Joined: 01 Nov 2006 Posts: 27

I also thought it may be setting related... so I disabled MXP and all the emulation modes except for ANSI emulation but it still happens. It even still happens with all my triggers disabled.

I'll try to get a screenshot later.

Posted: Fri Oct 22, 2010 4:38 pm

Run the Script Debugger window when this happens and enable the Raw Input/Output message. Then, when the colors get messed up, post a dump of the script debugger output within [code] tags in this forum post so we can see exactly what the MUD is sending to CMUD that is messing it up.

Beginner Joined: 01 Nov 2006 Posts: 27

Here is a good one, the "Four seaweeds are here." displayed properly in bold magenta:

Beginner Joined: 01 Nov 2006 Posts: 27

Good one with ANSI code same result as above post:

Posted: Sat Oct 23, 2010 3:18 am

I would like to note that the problem is not confined to input from the mud. It also happens when writing to a window using MXP DEST or #WINDOW. I have saved the string that the #WINDOW command sends to the window and confirmed that the color sequences are correct, however the display is not. What it sems to be happening is color migration. A previous (ansi) color sequence is kept and used for the next field and the ansi color sequence which should be used is ignored. I will also try to capture a screenshot of the problem and you can compare it to the string that was used by the command. Figuring out how the color migration works (can it be predicted?) is the reason I haven't posted anything on this problem for a while.

Posted: Mon Oct 25, 2010 5:00 pm

Sorry, but I really need the actual output from the Script Debugger window. Make sure all messages are enabled and then post the relevant output from each example again.

Beginner Joined: 01 Nov 2006 Posts: 27

Ok here it is i enabled everything in the messages drop down in the script debugger window.

Corret one, Four seaweeds are here shows bold magenta.

Posted: Wed Oct 27, 2010 5:14 pm

I can see where there is a network packet break in the middle of the text in the second example. Notice the first "i" packet ends in "[0;37;4" and the next packet starts with "0m". I think that might be the cause, but I still cannot make this fail when I test it here.

One more thing to try since it seems that you can reproduce this. After you connect to the MUD, type:

#DEBUGFILE test.raw test.txt

and then do whatever commands on the MUD to get it to fail. Once it fails with the incorrect color, exit CMUD and then send me both test.raw and test.txt files as email attachments to sales@zuggsoft.com. That should allow me to replay the MUD data directly here.

Beginner Joined: 01 Nov 2006 Posts: 27

Sent the requested email. Let me know if I can get anything else that will help.

Beginner Joined: 01 Nov 2006 Posts: 27

*bump* Did you receive the email I sent with the test files for this?

Posted: Fri Nov 05, 2010 5:06 am

I've been working on this problem for 2 months now. So I am going to tell you what I think the problem is and you can accept it or not.
GMCP just brings out the problem, it is not the source of the problem. The problem lies with the internal routine that both #WINDOW and #MXP use to paint the screen. What does GMCP have to do with it? The GMCP triggers are firing fast enough so that while the previous trigger that fired is having the screen re-painted, the trigger that has just fired invokes the same routine. This would account for the color bleeding if the TELNET command sequence for the color is stored in a static field. The concurrent passes through the routine would alternatively store into this field and when the next write is done the wrong command sequence is picked up (the color sequence requested by the other trigger). If you "single-thread" the GMCP triggers (disable the triggers until the current trigger finishes updating the screen or place the call to the write routine into a timer queue, which is equivalent since this method would also require for the timer trigger to be disabled) then this problem does not occur. If this is the problem, then en-queuing on the field containing the color command would prevent this problem. That is, all writes would have to single-file through the portion of the code which sends the color code to the screen. Note here that I am explaining why my old #MXP tests were having the problem. I have since switched to using the #WINDOW command and passing it the TELNET command codes for the colors. #WINDOW fails as miserably as #MXP did.

EDIT: Actually, this problem will arise even if the write is scheduled on a timer if the trigger that caused the write fires while the window is being updated when the timer goes off. The reason for this was outlined above. Example: char.vitals fires and starts to paint the window and the timer goes off and an a request to update generated by a deferred comm.tick trigger starts. The bottom line is that if the updates to the windows are not synchronous, the colors bleed.

Beginner Joined: 01 Nov 2006 Posts: 27

I'm not sure if you are talking about the same problem or not Anaristos. The one I am seeing occurs even with all triggers disabled, and I am not using MXP at all. I'm fairly certain it is not the MUD itself, because if I connect to the mud with Putty telnet, I never see this issue.

Posted: Mon Nov 08, 2010 5:49 pm

Anaristos, CMUD already handles all of that. Each code stream keeps track of it's own screen state for ANSI colors, etc. This is actually more needed to handle broken network packets where the network data can be split right in the middle of ANSI color sequences.

Also, writing to the screen is not threaded. The only thread that is allowed to access the screen buffer, handle repaints, etc, is the main application thread. So while I appreciate your thoughts on this, they don't reflect how CMUD or Windows works at all.

My personal guess is that there is still some sort of "buffer overflow" bug somewhere in the screen routines. CMUD has a limit on the number of color attribute changes per line (256) and the complex caching that CMUD does to reuse the screen memory buffer for fast scrollback is what usually causes issues like this. If the attribute cache for each line doesn't get properly cleared and eventually exceedsthe 256 limit after lots and lots of text is received, then color corruptions can start to appear.

I did receive the email from abascom with the text files, but I was unable to get it to fail when replaying the session. I have a test routine in CMUD that allows me to replay the raw #debugfile files, including the packet breaks. But replaying the files did not show any ansi color problem. I even lowered my scrollback size to 500 and replayed the file over and over again. So I'm still stumped as to exactly what is causing the problem and why it happens on some computers but not mine.

Posted: Mon Nov 08, 2010 9:00 pm

One more thing to try. See if you can reproduce the error on your end using the debug test.txt file that you sent me.

When you create the test.txt file using the #debugfile command, exit CMUD and restart. Load your session Offline. Then type:

#READ test.txt debug

on the command line and that should cause CMUD to read your debug file and display it. Tell me if this replayed text also shows the same ansi color problem. If it doesn't fail, then this is going to be really hard to debug unless you can provide a reliable way to reproduce it with a brand new character on your MUD that I can use.

However, if the replay shows the problem, then send me your exact screen size layout (number of rows and columns) along with the list of Preferences in your Session/Scrollback tab. This will allow me to set up my screen just like yours. The screen size effects how lines are scrolled and might matter when debugging weird scrollback cache issues like this.

Beginner Joined: 01 Nov 2006 Posts: 27

Ok I'll try this later. Is there an easy way to send you all my settings? Is it all stored in a file or two I can just attach to an email instead of going and writing them all down?

Oh and I should add I'm on CMUD 3.31 and Windows 7 64-bit.

Thanks.

Posted: Tue Nov 09, 2010 5:11 pm

You can send me your CMUD.INI file and the *.PKG file for your session. I'm using Win7-64 here too, so that shouldn't be a problem.

Beginner Joined: 01 Nov 2006 Posts: 27

I tried the debug replay and it did not show the issue. I will email my settings to you and a username/pass for a testchar I created on the mud I am playing and hopefully you will be able to see the same problem I am.

Posted: Sat Nov 13, 2010 5:31 pm

I got your email and will give it a try on Monday and let you know what I find.

Posted: Mon Nov 15, 2010 6:07 pm

I tried the MUD login that you sent me. I was still not able to reproduce the color problem. This tells me that the problem is related specifically to network packet boundary issues. Your network connection or ISP must be breaking up packets more often than my connection. So that is why I an unable to reproduce the exact conditions of your connection.

I'm really stumped on this one. The replay of the debug files should have reproduce the problem with packet boundaries. Playing live with your files should have reproduced any session-specific issue. I tried both v3.31 and v3.32 and didn't see the problem in either version. So I have no idea what to try next.

Posted: Mon Nov 15, 2010 9:36 pm

Does anybody know how I might modify my local network configuration to *increase* the chance of packet fragmentation? I tend to have a really good Internet connection so I rarely get packet boundaries. If there was a reversible way to cause my connection to start splitting packets, maybe I'd have a better chance to reproduce this problem?

Posted: Tue Nov 16, 2010 7:55 pm

Try lowering your MTU?

Posted: Tue Nov 16, 2010 10:41 pm

Do you happen to have the Windows command line (win7) for doing that? I don't really have time to spend hours Googling how to do this.

Posted: Wed Nov 17, 2010 2:39 am

You can usually control on you routers admin interface. It's on the main Setup page for my Linksys router.