Zugg Software :: View topic

Posted: Wed Jun 11, 2008 12:36 am

Sorry, but I just did 40 messages and never got any problem here. I'm going to need someone else with a character on Achaea to test this.

Also, I assume you still have your triggers disabled? Maybe you can try logging into your Achaea account with a new, blank session so that we can be absolutely sure that none of your settings are interfering and causing this.

Posted: Wed Jun 11, 2008 1:27 am

I'm assuming you both set your prompt and checked with 'msgs' between each of the sent messages to check to see if it appeared. If that's the case then I'm deeply discouraged. I thought for sure I had a method you could reproduce.

By the way, I was using a completely blank session. Triggers were enabled but there were no triggers present in the session.

Posted: Wed Jun 11, 2008 1:31 am

I know there are other people that are getting this issue as well. It'd be really helpful if one of them could try my procedure to see if it is reproducible for them as well.

The next step in my mind is to install Cmud in a clean directory and create a brand new character (default settings) with which to test this on. Hopefully it was just a global/shared setting that is causing the issue. If not then I'll have to start digging into Windows settings.

Posted: Wed Jun 11, 2008 3:02 pm

I just don't understand this. How can this not be reproducable.

Posted: Wed Jun 11, 2008 5:08 pm

Yep, I did the full "config prompt all" and I checked msgs after sending each one.

What version of Windows are you using again? I looked in the thread but didn't see that mentioned. I know that Vista made some pretty significant changes to their networking stack, so maybe I'm just not getting the packet boundaries that you are getting. That might also be ISP or router dependent too.

In fact I turned on the Script Debugger and enabled the Raw Input/Output message and confirmed that when I do "msgs", then I get everything in one giant packet. Once I get to about 50 messages, then I can get it to start splitting packets, but it splits in the middle of the message output and not where the prompt is. So it seems to be very tricky to get this to break in the right spot.

I'm not sure why #SHOWPROMPT doesn't reproduce this, but I'll take a look at that.

Posted: Wed Jun 11, 2008 5:50 pm

OK, I think I have a clue what is going on now. It's a pretty obscure bug, but I think I have a way to reproduce it internally with some changes to the #SHOWPROMPT command. It's very tricky and I need to be careful that I don't make this worse with my fix. But hopefully it will work better in 2.27.

Thanks for the patience in helping to reproduce this. Ultimately I used your example #SHOWPROMPT command from the previous page of posts along with a change to #SHOWPROMPT. Turns out that #SHOW/#SHOWPROMPT were not *exactly* stuffing text into the network buffer. And while it was close, the difference ended up showing the problem.

Posted: Wed Jun 11, 2008 11:12 pm

Wonderful! I'll be so happy when I can finally put this bug to rest. What ended up being the issue, apart from the #showprompt in reproducing it?

Posted: Wed Jun 11, 2008 11:14 pm

Windows XP Professional
Version 2002
Service Pack 2

Posted: Wed Jun 11, 2008 11:36 pm

The issue was that there is a routine in CMUD to save/restore the current ANSI/MXP/MSP/ATCP/etc parsing "status". When CMUD is in the middle of parsing an ATCP message, for example, it has a flag called "InIAC" set to true. CMUD needs to save this state after each line from the MUD so that if you happen to output user text to the screen right then (like with a #SAY command or typing a command on the command line), then CMUD won't think that the text or command is part of the MUD's ATCP packet that it hasn't finished. When the next line from the MUD is received, CMUD restores the parsing status and continues.

If the parsing status isn't restored properly, then it can lose track of the fact that it is still in the middle of parsing ATCP stuff.

Originally, this was all written to handle ANSI parsing to handle packet boundaries in ANSI control codes. But the ANSI control codes are parsed when the line is written to the screen, whereas the IAC/ATCP stuff is parsed when the packet is actually retrieved from the network.

So, the problem was that the parsing status was getting restored too late. It was getting restored before the line was written to the screen, but wasn't restored when the line was actually received from the MUD.

Posted: Thu Jun 12, 2008 1:53 am

I'm amazed by the quantity of work that goes on behind the scene that I know little about.

Your comment got me thinking about how it is possible for me (with the correct timing and packet content) to split the received text between a room name and a room description with a sent command.

Usually I see this:

Room Name
Room Description
Room Exits

With an #ok triggered off the Room Name and a packet break in the right place, Cmud will send the next travel direction so that it splits the room name and the room description so I see the following:

Room Name
My command - Travel Direction
Room Description
Room Exits

From your description of what's happening it seems that you specifically plan for interruptions such as what I am observing with the room name and description being split by my entered command.

Do you have to save the state like that because you can't be sure if there is a further packet coming? Simplistically I'd say just wait until the rest of the information is received and then send the command, but perhaps due to network interruptions and the uncertainty of receiving a packet it may halt Cmud from sending indefinitely while the lost packet never actually arrives. From my example above I wouldn't mind, actually I think it would be better, if the command just occurred after the room exits. But I'm dabbling here in things I'm sure I don't fully comprehend. I'm sure there are issues here I'm not aware of.

Posted: Thu Jun 12, 2008 5:40 am

Yep, it's also very important to allow that kind of breaking for speed. In old versions of zMUD, for example, your travel direction would end up coming *after* the full room description, which would make it seems more laggy. Even if the actual command was sent to the MUD after the room name, if it was echoed later, it made the client appear slow. Lots of people complained about that, and some other clients actually made false claims about how "slow" zMUD was, even though it was sending the actual MUD command as soon as possible.

Same thing if you press a macro key...you expect to see that macro text echoed right away when you press the key, and not several lines later.

But you never ever want to "wait" for the MUD to send something that might never come. That's fundamental to network programming. The network must be treated as an unreliable beast that might never send the packet that you might be waiting for. That is why zMUD and most other clients are "trigger-based" (which mirrors Windows itself, which is "message-based", as in "I press a key and Windows sends the key message to the application, which then does something with it"). It's much more difficult to have sequential scripting like the #WAITFOR command in CMUD (it requires full multi-threading, which is why zMUD didn't have commands like that). Some clients try a simple approach to sequential scripting and WaitFor commands because threading is difficult and complicated and end up with a slower client that can only handle pretty simple stuff (zMUD actually did that with it's #wait command, which was easily broken).

And yes, with many MUDs, there is actually no way to tell the difference between the end of a packet and the MUD prompt. Some MUDs mark a MUD prompt with an IAC EOR or IAC GA code. But many do not. So you mostly need to assume that the end of a packet is the end of a MUD prompt. But as you've seen, the end of a packet can come at any time. And it can depend upon many factors, not just the MUD server code. That is why you were getting packet boundaries that I wasn't getting. I can be computer-specific and even ISP-specific.

Handling packet boundaries that appear *anywhere* in the input stream, even in the middle of ANSI codes or ATCP is one of the complexities that many other clients do not handle.

Anyway, yes, there is a huge amount of this stuff behind the scenes. CMUD is 1.5 million lines of code now. It takes only a day or two to throw together a "simple" MUD/telnet client these days, but it takes years and years to get the details right. It took about 5-6 years of fulltime work to get zMUD stable. It's taken me 2 years of fulltime work to get CMUD stable with the advantage of being able to use some zMUD code (like the mapper) and learning from what I did in zMUD. That's why you see a lot of simple clients that mostly do the same thing, but very few advanced clients because it's very easy to underestimate the amount of work really required.

Posted: Fri Jun 13, 2008 10:29 am

I was going to report back that this was totally fixed, but I saw one bleedthrough. This was already a difficult bug to exercise before your fix and it's neigh impossible for me to get it to show again (which is great). So for all intents and purposes you fixed the bug I reported. If I see any more bleedthrough and can capture it I'll post it up.

Thanks for fixing this!

Beginner Joined: 26 Apr 2007 Posts: 29

From playing around a bit in Achaea it seems indeed fixed! Thanks alot, great work.