Zugg Software :: View topic - [3.10a] Bug: MXP Image + VT100 HOME+DEL_EOS

Novice Joined: 16 Oct 2009 Posts: 37 Location: Germany

Hello,

Many MUDs do a HOME+DEL_EOS to set the cursor to the top-left of the screen and delete the whole screen.

If a MXP Image was displayed beforehand, the DEL_EOS doesnt erase the image - I guess from some display buffer, since the image does change position after the HOME, going a few lines up, depending on where the output originally started.

I find that a DEL_EOS should also delete the image and not display it again.

Novice Joined: 16 Oct 2009 Posts: 37 Location: Germany

note: this also happens in zMUd.

Posted: Sat Oct 17, 2009 5:07 pm

I would need to see the exact MXP image command and then the exact ANSI cursor control sequences in order to reproduce this here and fix it.

But remember that images can span multiple lines. The image will only be erased if the first line of the image is still on the screen. If the first line of the image has already scrolled off the top of the screen, then moving the cursor to the home position won't delete the bottom part of the image.

Moving the cursor to the Home position and clearing the screen is generally not recommended unless you are using VT100 scrolling regions to fully control the screen and the scrolling. Mixing MXP images with VT100 scrolling regions has never been tested (obviously, since VT100's had no image capabilities).

However, if you are working with an image in a MXP popup window and trying to clear it, then give me the exact code you are using so I can try it. If the image hasn't scrolled, then it *should* be getting cleared.

Novice Joined: 16 Oct 2009 Posts: 37 Location: Germany

The exact image tag is:
<ESC>[1z<image fname="dawn.gif" url="http://avalon.mud.de/img/"><ESC>[7z<ESC>[1z</image><ESC>[7z<ESC>

The VT-Codes used to clear the line are:
<ESC>[H<ESC>[J
(home and delete eos)

Again, you can check this at:
avalon.mud.de port 17777 our developement mud.
To reproduce this please make sure that you see the banner at the init screen (you could see the garbage I refer to in the other bugreport). If you don't see the banner (if it hasnt downloaded yet) please reconnect (just reconnect, don't close the window). Then, when you are prompted for a name, please type in "zuggtest". It will send the VT-Codes and clear the screen. You will notice the image still being displayed and "moving up" a bit. This is what I meant.

Yes, mixing MXP images and VT display codes is a bit asking for problems ;) On the other hand, the combination of VT100 HOME+ delete to end of screen is a quite common way to clear the screen, I think, and it would probably not hurt clearing the image.

Novice Joined: 16 Oct 2009 Posts: 37 Location: Germany

Hm, please also note that the develmud-login will have some other issues as I have been working on it the last week. Please just ignore things like the login not responding anymore, etc.
The production mud obviously doesnt have these anymore.

Posted: Mon Oct 19, 2009 3:58 pm

Thanks very much for setting up the test account for both this and the other MCCP/MXP issue. That will help me track down the problem and I'll definitely check into it this week. I'll let you know when I'm done with the testing.

Posted: Mon Oct 19, 2009 8:04 pm

I don't see any IMAGE tag being sent by the test server. Could you confirm that this command is still being sent?

Posted: Mon Oct 19, 2009 8:06 pm

Also, when using a username of "zuggtest", it just says:

Novice Joined: 16 Oct 2009 Posts: 37 Location: Germany

Oh, thats our generic error message.

Ok, I updated the code, since you already tested for the MCCP bug, to a more current version. The bugs should be gone. Image-Tags are sent, I am positive. Albeit sometines the MXP initialisation takes longer due to latency issues and the prompt is too fast and skippes the MXP image. If that is the case, please simply reconnect and type the "zuggtest" or "zuggtest2" again (in place of a name). He will give you the test-case.

Posted: Tue Oct 20, 2009 8:17 pm

OK, I'm getting the image now and the two test accounts are working. Both reproduce the bugs that you reported. I'll be gone the rest of today, but will get back to this again tomorrow and track down the bugs.

The reason I wasn't getting the image was that it had failed the first time, so I have a zero-byte DAWN.GIF file in my Images subdirectory. I'm going to add that to the bug list too so that CMUD will go ahead and try to re-download an image file that is zero length.

Not sure about the synchronization issues that you are getting. My guess is that you are waiting for the result from the VERSION tag to see if the client supports images?

I notice that the first time I connect to the MUD, I don't get the image and I don't get the username/password prompt. But if I do a File/Reconnect, then usually both will appear.

Edited: Hmm, not always. There are still many times that I get the username/password prompt but still do not get an IMAGE tag sent to the client.

Anyway, definitely looks like some synchronization issues for you to look into on your end. In both cases ( image appears vs image doesn't appear), it looks like CMUD is properly sending the response to the SUPPORTS and VERSION MXP tags at the same places. But somehow the MUD didn't get that information and doesn't send the IMG tag in some cases.

Novice Joined: 16 Oct 2009 Posts: 37 Location: Germany

Yes, could be a synchronisation issue on my end. The feature (sending MXP image and waiting for some initiations) is not a week old. Btw it works like this atm: We wait for several telnet-negs: MXP, EOR and TTYPE at least, then also for the MXP SUPPORTS answer. With that the MUD can decide how/if to output the MXP stuff. There is also a time-out, because some clients do not answer to unknown telnet-negs. In that case MXP stuff will not be shown at the login-prompt.This time-out is 2s atm.
I even get >2s delays on my private network! So it may not only be a network latency issue, but maybe some system latency issue (sheduler/disk/swap/something) on either the server or the user-machine. My guess would be the latter.

Well, anyway, thanks for looking into it.
xtian@avalon

Posted: Wed Oct 21, 2009 4:45 pm

Novice Joined: 16 Oct 2009 Posts: 37 Location: Germany

Nah, I dont remember exactly, so I'd better say nothing at all.
I just remember that Tinyfugue doesnt answer to telnet-negs, that it already responded to, which can also be a problem. (except for NAWS obviously)

Posted: Wed Oct 21, 2009 8:09 pm

Actually, that's part of the spec. If a client has already negotiated an option, then it's supposed to ignore further option requests for the same state to avoid negotiation loops. For example, if you send "IAC DO Option" and the client responds with "IAC WILL Option" and then you send *another* "IAC DO Option", then the client isn't supposed to send a response.

However, that shouldn't require you to do any timeout delays since you are just negotiating for MXP once at the beginning.

But yes, you need to keep track of the state of each option on both the client and server so that you know what state each option is already in.

Posted: Wed Oct 21, 2009 10:12 pm

OK, I found the problem with the ClearScreen routine. The trick in CMUD is that because it wants to maintain the scrollback buffer, it never actually *clears* the screen. Instead, it just send enough blank lines to scroll the previous screen up (so you can still scroll back and see it).

The bug ended up being trivial: CMUD wasn't putting the cursor at the *bottom* of the screen before scrolling it. So it was just inserting X blank lines in the middle of the current screen since you positioned the cursor at the top of the page.

Fixed for v3.11