Zugg Software :: View topic

Apprentice Joined: 18 Feb 2007 Posts: 190

this is how minimap should look like, and does - 1 of 10 times

Posted: Tue Oct 28, 2008 4:20 pm

The script debugger window cannot handle the packet boundry in the middle of the ANSI color sequence. Notice in your second example how the first packet ends in ESC[0;33 and then the next packet starts with the "m" that was part of the previous ANSI code?

The main CMUD window has lots of special code to handle packet boundaries like this. But the script debugger does not (because it immediately tries to display the line received from the MUD without waiting for any subsequent lines that might finish the ANSI codes).

So as long as it's only effecting the script debugger, this is normal and a very low priority to fix (if it's even possible to fix).

Apprentice Joined: 18 Feb 2007 Posts: 190

thanks for reply
well, it also affects capture window and whats in %line

it also appears that i somehow disabled mccp while it showed as enabled in options... proper enabling it fixed packet splitting problem

Posted: Tue Oct 28, 2008 8:10 pm

It shouldn't be effecting capture windows or %line unless you have some sort of trigger that is doing something else to this. Triggers normally don't fire until a newline is received from the MUD and then the actual text on the screen is extracted and passed to the trigger. And in the above case, once the newline is received the packet boundary issue has passed and the text on the main screen is correct. So I'd need to see the exact capture or %line issue that is causing the problem.

If you turned on ATCP or was playing with that, then CMUD would automatically disable MCCP since IRE MUDs have problems when ATCP and MCCP are turned on at the same time.

On the timing, remember that the script debugger window effects the timings. In the case you showed it required color switching in the middle of the red text, which makes it slightly slower just because it has to call the Windows TextOut routine twice and change the text color in between (which is slower than just outputting a single black line of text). Also, timings along the 10ms order are *very* subject to other things that Windows might be doing at the same time. 10ms is a single "tick" in Windows, so timings at that low level are very suspect to all sorts of things. But in general, the more ANSI or MXP parsing that CMUD has to do, the slower the line will be displayed.

Also, depending upon your Refresh Amount setting in your preference it might have been doing the screen update at that time. For example, if you set Refresh Amount to 5, then CMUD only actually refreshes the screen (or scrolls it) every 5 lines. So the first 4 lines will get handled really fast, and then the 5th line will be slower because of the update.

Apprentice Joined: 18 Feb 2007 Posts: 190

Posted: Tue Oct 28, 2008 10:40 pm

waitcr="true" is the default value for the property, so that's why it isn't shown (XML export only shows properties that are different from the default). So it should have only been triggering on newlines. Otherwise you'd see a "prompt=true" also (for prompt triggers).

zs.line actually just retrieves the value of the %line variable. You might try the %line(0) to retrieve the current line from the screen. It's possible the %line internal variable isn't being set correctly. Not sure why the zs.cap wouldn't work though. It fetches the line as displayed on the screen and then puts it into the capture window. Since CMUD recreates the ANSI color from whatever is displayed on the screen, it shouldn't have been effected by any packet boundaries.

Apprentice Joined: 18 Feb 2007 Posts: 190

cheers, i keep that in mind if i encounter it again

aah, there is also gagon at work there, that sheds some light?