Zugg Software :: View topic

Beginner Joined: 26 Feb 2009 Posts: 27

Recently our MUD's project has involved some VT102 on a test port of ours and we're encountering some issues specifically with CMUD.

Testing on Putty or older versions of ZMUD appear to render no negative effects but logging in from a session of CMUD with no previous settings crashes the client a great deal and once in (if you continue to click keep running) produces an undesired result. If someone could log into our test port and try to tell us how we can improve this for CMUD users it'd be great.

contact me on AIM at p0s3ur or by e-mail at mikeymalach@gmail.com for the site and port if you can help.

Posted: Thu Jul 09, 2009 4:27 pm

First, please try the 3.08 Beta version of CMUD since it has a few ANSI and VT100 bug fixes in it. I'll definitely contact you for the host and port so I can test this. Fixing all VT100 issues is very high on my priority list right now.

Beginner Joined: 26 Feb 2009 Posts: 27

Updated and tried again. Same issues but this time I sent the error reports. There's quite a few.

Newbie Joined: 09 Jul 2009 Posts: 6

Hi there I code/run the mud in question that we're having the issues with. Last night I started venturing into making a static prompt that sticks to the bottom of a client's screen using VT102 based escape codes and the TELOPT_NAWS negotiations. The sequence of events is when a client first connects its sent the AIC DO TELOPT_NAWS, client returns properly and then properly sends the right values for the rows/columns but I did notice Cmud puts a line return on the main window when its replying either the first WILL or the actual window values during the sub negotiation. This is something I haven't noticed any other clients doing during that phase.

So far though really so good, but when Khana and I got through the login process to where the mud next starts sending VT102 escape sequences to setup the scrolling and cleariing up the lowest three lines of the screen for our prompt thing that's when cmud would just crash multiple times. Strangely for myself it only happened the very first time I logged in with the 2.37 client and every time since it and the 3.08 both pass through those sequences without issue. Cmud is acting on the escape codes properly though and for the first while it behaves just like it should with the scroll window being set from top to -3 from the bottom and stuffing the three reserved bottom rows with the text and colours all good. But then after either it seems a certain amount of text, colour or escape codes are passed to it Cmud just starts to really mess up the colours without any particular pattern. Its just really mixing the codes at random and using ones that aren't even in the ones that should be on screen. I've only seen it do that with foreground and background though, didn't see any of the misc ones like underlines or blinking etc.

Any ways its being fed these VT102 escape codes:
\x01B[K - Clear to end of line, I used that to refresh each of those three lines beneath during each refresh.

Then to do the switching around I used this function:
void send_to_char_xy(CHAR_DATA *ch, int col, int row,const char *str)
{
printf_to_char(ch, "\x01B[%u;%uH%s", row, col, str);
}
Its used to write the three lines of the prompt as required and then I also use it to move the focus of the window back into the scrolling area and that seems to be quite successful with all the clients. Again this works pretty flawlessly with other clients like Putty, raw linux shell telnet and the Zmud family. One other mention though is I noticed is Cmud as well as Zmud both doesn't do very long inputs too well with this setup we've got, they will both commonly eat the output of the wrapped line you type so you don't see it but the command does make it through to the mud and is executed so its just a visual thing. I'm pretty sure its something to do with the the clients' outputting and it spilling from the assigned VT scrolling area into the 3 'reserved' prompt lines beneath it. I noticed that if I reserved another line between them it happened much less frequently.

Sorry for the book but I hope this helps :)
-Ragnar of Xaos

Newbie Joined: 09 Jul 2009 Posts: 6

Update and a good one. :) I constructed a toggle for us to turn on and off the VT codes and upon doing so it clears out the garbage colour. Like its still getting messed up but by turning off the VT codes the garbled codes are gone as soon as they've been over-taken by other stuff on the screen. Toggling VT codes back lets you run around again for a bit before the colours start to go crazy so the client definitely doesn't like the combination for sure.

Posted: Thu Jul 09, 2009 9:32 pm

I also got some log files from Khana on this, but it looks like I'm going to need to log in to see it happen for myself. As you said, it seems to work properly to start with, so I'm only going to find the problem when logged on and playing with it.

Your method of using NAWS to discover the terminal height and then setting up the scrolling region and then switching between the main region and the bottom three lines should be fine. I'm assuming you are using the \x01B[1,40r code to set up the scrolling region where "40" is whatever you want the main height to be?

Scrolling regions are one of the most complex parts of the VT100 code and they are a bit flaky and not well documented. I thought I had them nailed in zMUD and CMUD, but apparently not. It's odd that CMUD is working differently from zMUD since they share a lot of the same (old) VT100 parsing code. And I'm not sure what would cause the colors to start getting corrupted like that either.

But if regular telnet and Putty can handle this, then CMUD should be able to also, and this is an area of great importance to me right now (since our new TeSSH product is supposed to compete directly with PuTTY). So I will try my best to get this fixed asap.

Can you tell me the commands to use on the MUD to toggle the VT codes off and on? (or send me a PM if you don't want it public)

Posted: Thu Jul 09, 2009 9:44 pm

OK, I learned a bit about this. I *was* able to log in and reproduce the problem.

One thing I noticed is that when creating a new character on the MUD, the MUD never seems to send the ESC[1;r code to set up the scrolling region properly. Or else the cursor is messed up somehow because the health bar keeps scrolling with the regular text. When I reconnected to the MUD, then it worked properly.

But as you said, after a while it starts messing up the colors in the lower 3-lines where the health bar is. I've got a log capture of it messing up and I hopefully I'll be able to determine what's causing the colors to get messed up like that. I'll post when I know more.

Posted: Thu Jul 09, 2009 9:54 pm

Btw, already noticing one thing that will potentially be a problem: you are one of the MUDs using the newline sequence LF CR instead of the proper CR LF as required by the Telnet protocol. If you are going to start using Telnet option negotiation and VT102 stuff, then you really need to pay attention to the proper telnet protocol standard. It requires a CR LF line termination. That probably explains the extra line that you said you saw during the option negotiation.

In a lot of ways, CMUD is like Firefox and PuTTY is like Internet Explorer. I mean this in that CMUD tries to pay close attention to the protocol standards, even if some servers don't implement them properly. PuTTY has a lot of kludges and tweaks for various systems to try and render stuff properly even if the protocol isn't followed. CMUD requires stricter adherence to standards.

And while CMUD *does* have a kludge to handle LF CR instead of CR LF just because it is so common on MUDs (for some historical reason unknown to me), there are cases where that might still cause trouble, especially when doing something like Telnet option negotiation.

Please try to fix this if you can. Someone really screwed up on this a long time ago in some code base that MUDs keep using over and over again, and I'd like to get it fixed wherever possible.

Posted: Fri Jul 10, 2009 1:22 am

OK, I think I found the cause of the problem. It's actually two issues. CMUD can store up to 256 different color "styles" per line of text. Usually this is plenty. One problem is that the ESC[K code to clear the line is not clearing the attribute buffer. So each time you move the cursor to the 3 lines in the bottom and clear it and then print text, the previous styles are not cleared. Depending upon the number of ANSI codes used on the line, it only takes about 30 times before the 256 limit for the line is exceeded, at which point you start getting random styles (buffer overflow).

The other bug is that normally CMUD should only create a style record for a "complex" style, like an MXP tag. For a pure ANSI code, CMUD has a way to store the ANSI code directly instead of creating a new style record internally for the line. So the fact that CMUD is creating a bunch of style records anyway is also a bug.

It's only because of the combination of these two bugs that you are seeing the random colors effect as you overflow the style buffer for the bottom lines.

Messing with the ANSI color code stuff in CMUD is pretty tricky. Hopefully I can fix this without introducing any new bugs. I can certainly fix the issue where clearing the line should clear the style buffer for the line. Figuring out how to keep CMUD from creating an entire style record in the first place is a lot trickier. I don't remember if I started doing that in the past to support some other style feature or not. I will try and be careful when fixing this to not screw up the rest of the ANSI color stuff.

Newbie Joined: 09 Jul 2009 Posts: 6

Posted: Fri Jul 10, 2009 3:47 am

I think I've got the bug fixed in for the next CMUD beta version.

Yeah, zMUD didn't have this problem because zMUD didn't have "styles". The way zMUD handled attributes was a bit different, and when Styles were added to CMUD, it required some changes in the low-level attribute handling.

I decided not to mess with the fact that CMUD is creating a "rich" attribute record instead of just using the raw ANSI color value. I think I remember that this was done so that people could change their default text style, which could involve changing the default background color of the text. So when the MUD sends something like ESC[31m to change the foreground color, the background color is still the color of the default style, which can be any 24-bit color value and not necessarily an ANSI color (like 0 for black). So I think this is why CMUD always creates a rich color attribute now whereas zMUD never did.

What I *did* fix was to clear the unused style records when clearing a line. So now it doesn't overflow the 256 style limit within a single line. I logged into your MUD and tried it and it seems to work great now.

It's a little slow in moving from room to room and I don't know if that's the MUD or something in CMUD. Maybe I'll try it in old zMUD just to see how it compares. I need to make sure I didn't add something that is horribly inefficient causing a big slowdown.

One quirk that I noticed is that sometimes when the screen scrolls a lot (like when speedwalking through rooms), the prompt in your fixed 3 lines at the bottom of the screen sometimes shows briefly on one of the lines above. Almost like CMUD is scrolling the entire screen, then repainting it, so that the prompt momentarily gets displayed a few lines above before the repaint happens. It's just a visual quirk as far as I can tell. I've added it to the bug list to look at, but not before the next beta version. I'm really trying to get this next beta ready for tomorrow and this particular bug added a lot of time today. But that's ok, because it was important to fix. So thanks for working with me on this.

Definitely let me know if you continue to see any VT100 problems in the 3.09 or future versions. Not many MUDs are using VT100 these days, so it doesn't get as much stress testing as I'd like to see.

Newbie Joined: 09 Jul 2009 Posts: 6

That is fantastic news and wow very fast turn-around time on the fix. :) The slow-down on walking between rooms btw is based upon the character's abilities vs the terrain just to aid with anti-rapid-escape scripts in PK or predator mob situations so that's probably all you were experiencing there, as I'm immune to the wait states it flies along all good for me so definitely no worries on that front its a thing that's native and intentional to Xaos's engine. I consider it an honour to have helped you with this, Zmud has always been the most prevalent and effective client in the mudding community and to have worked directly with you to help ensure your work continues to drive the client-side of mudding forward is extremely satisfying for me. :)

Oh btw I fixed the \n\r vs \r\n thing throughout my entire source with the shell command "sed -i 's/\n\r/\r\n/' *.[ch]", needed to do it twice strangely to catch a few stranglers but well certainly that'd be a boon to any other mud coder looking to ensure the best compatibility on that front. I'll let you know if any other vt things turn up, it was my first venture into that side of telnet client/server development and so far its been very rewarding, between it and the awesome MXP protocol I see great things coming. :)

PS: My prankster nature is saddened that download on demand for sound via MXP is by default off on the clients, but I must agree its not something I should be capable of inherently being able to do either based on what I wanted to do with it. I get enough fun out of messing with idlers using the push image options available already :P

Cheers!
-Ragnar

Posted: Fri Jul 10, 2009 4:12 pm

Newbie Joined: 09 Jul 2009 Posts: 6

Hi Zugg, think I've encountered another issue with this setup; I couldn't trigger on anything within those three prompt lines with either Cmud or Zmud until I'd changed the mud's output to include line returns at the end of them. I was trying to just rely on the 'prompt' trigger check box to scan on incoming text but it seems to be skipping this area. Its the first time I've indulged in using that particular check box as well though so I'm not sure how functional it is, if its just known to be testy say no more.

ED: If you wanted to see this for yourself I've put the testport up again and put a line return on the first and bottom line while leaving the middle without. Also if relevant I've moved the vttoggle command into our config one so it'd be 'config vt' to toggle the vt102 support mode on and off.

Posted: Thu Jul 16, 2009 4:41 pm

Yep, that's a known issue. Normal triggers all require a newline at the end of the line. Prompt triggers only fire on the last text given in a network packet, although you can also add IAC EOR codes to the end of the line to force the prompt trigger to detect the text as a prompt. Otherwise CMUD/zMUD has no idea how to trigger on that text.

Since you are talking about the lines in the non-scrolling part of the window, it shouldn't hurt to add a CR LF to the end of the lines that you send to cause normal triggers to fire. Or, as I said, you can try adding IAC EOR

Newbie Joined: 09 Jul 2009 Posts: 6

no problem then, I'll just keep the line returns and call it day.

Beginner Joined: 26 Feb 2009 Posts: 27

It doesn't appear as if 3.09 has fixed the VT102 color issue.

Posted: Sun Jul 19, 2009 3:26 am

Can you be more specific please? I don't see it corrupting the colors on your MUD anymore, so you must be referring to some other problem that I missed.

Beginner Joined: 26 Feb 2009 Posts: 27

For me it's precisely the same issue.. I'll try reinstalling the software, it took a long time to load so something may have gone awry.

Sorry about the vague description.

Beginner Joined: 26 Feb 2009 Posts: 27

I've done a quick reinstallation and I am experiencing the same random bleeds. Should I attempt to completely uninstall then reinstall the client?

Posted: Sun Jul 19, 2009 5:17 pm

The long load time is the new version converting your package files. See the note about this in the Beta forum. There will be a patch later next week that will add a conversion progress bar so that it doesn't look like CMUD is hung.

I'll log on and try the MUD live again to see what I find. I made a capture log file the last time I logged on that replicated the random color bleeds, and that log file works perfectly in 3.09 for me, but maybe there is still some difference between doing it live on the MUD vs read the raw log file. The 3.08 version certainly showed the color bleed easily using the log file, so that's why I thought it was fixed.

Beginner Joined: 26 Feb 2009 Posts: 27

I appreciate the effort Zugg. Thanks!