MUClient and the telnet protocol thing

This is a bit of a rant, but we were arguing with a friend about this. Correct me if i'm wrong, but with telnet, you can place the cursor wherever you want, and you can send lines/characters even above lines that have been previously sent. Can you do that in MC?
Our argument was that you can't have a separator line, and send half the messages above and half below, like this:

Message #4
Message #5
------------------------
Message #1
Message #2
Message #3

Wouldn't the correct order be

Message #1
Message #2
------------------------
Message #3
Message #4
Message #5

?

You can in a client that has 'full' support for all ANSI features. ANSI provides means to reposition the cursor, move it up, down, left and right, or even store and restore positions. However, most clients that do this assume a fixed size screen that doesn't scroll and any scroll backed 'pages' it keeps are stored in the last state they where in before they where cleared. The do log all events though, including the orginial ansi commands, so you can play back the real events.

Mushclient however is a scrolling based system that assumes that there are no individual 'pages' and since games that use that method don't have distinct pages, you can't be entirely certain what line you are on in order to reposition the cursor. It was never intended to support such things. It wouldn't be impossible to do, but Nick has generally stated that it probably never will. If it did, it would require some serious modifications to the way things work now, including some way to straighten out how the buffered lines get handled so it would work.

The main problem here is that a cursor-based implementation does not really make sense with a line-based implementation. For instance, if your cursor goes to position row1/column1, and you overwrite the line there, what happens when you scroll back? Do you get to see what used to be there?

For the log file, yes, you could just say "things are logged as they are received without any repositioning" - in fact, you have to. Otherwise your whole log file would be just about one screen... :)

Cursor based implementations are nice for some things, especially when you want to minimize bandwidth usage (e.g. when using VI, if you change one line, you don't need to resend the lines around it)... but line based implementations are very useful for any kind of scrollback function. Try opening telnet, viewing man-pages, and use a scroll-back buffer... you get very strange results that don't make a lot of sense. You'd have to be willing to accept similarly strange results on MUSHclient scrollback features if you were to accept cursor repositioning.

The only kind of repositioning that could - probably - be implemented relatively simply (except for log files) would be the carriage return - e.g. go back to the beginning of the line - because, one would assume, if you're overwriting this line, it's because the old contents are obselete. This could be used for updating the prompt every now and again, without the user being sent or sending a message and having the prompt resent. This would save having many repetitive prompt lines, I guess.

The scrollback issue is the main issue i was thinking of when i said that repositioning was not possible... Just wanted to know if it can be done or not... Seems that I won the bet :P

Well Ksilyan, like I said, the programs I have seen in the past that allowed for both scrolling and screen positioning treated each 'clear' command as a 'page'. Once it recieved a request to clear the screen, all information in the buffer bacame fixed in that final state. The same thing happened as things scrolled off. If you could display 24 lines, then the moment the 25 line arrived, the one that scrolled off became permanent and fixed in what ever state it was in. Generally this is not an issue for text positioning, since it is usually employed for animation or similar things, where it makes more sense to playback the sequence from the log, not scroll back every for every single time the cursor moved. The log of course captured the raw data as an option, letting you replay the entire thing as it happened.

Really, there is no reason why any client can't do that same, simply making the line contents permanent after it enters the non-visible part of the buffer. However, it would likely require some extra code and it might make things a tad slower. I can't say it is needed, but it would be nice to have. Especially since I can install some old games, modified to work with TCP/IP, like TW2002 on my computer, but mushclient it useless as a client to talk to such games.

Of course such a thing is possible to "implement". There are however issues with it... for one, you need to start knowing how many lines are in your "page".

Here's an interesting problem. I take this from an ANSI-VT100 terminal control page:



Therefore a MUD can, in theory, send arbitrary positioning commands. How would it know how big your "screen" is? Would this be an in-game config option? And what if you made a mistake setting the size of your screen?

Here's another interesting question. What if your MUD displays at the top a "status box" sort of thing, and the text below it? And when the text "scrolls", the status box is redrawn at the top. Let's take an example:



OK, so the MUD sends just one more line now...




The MUD prints the status box on lines 1, 2, and 3, and prints an empty line on line 4. Therefore, the new line arrives ("Welcome to my mud again!") and shifts the text up one... which moves the first line of the BOX, not the text, outside the page buffer.

So under your scheme, that line now becomes permanent. The text lines will NEVER leave the "page" because they are never the ones on the top of the page. How do you handle this problem in a scroll-back client?

This has arisen about once every 6 months, but I will briefly comment again.

Repositioning the cursor is fine if you don't try to do things like:

* triggers
* logging
* scrollback
* gagging text

The list is endless. Sure, there are programs that support cursor positioning, but try using them for a MUD.

It is like saying that I have a sports car, but I saw someone else with a pickup truck that can carry a lot more goods (like a load of bricks). They can do it, so why can't you? Well, you either have a sport car or a truck - the designs are basically incompatible. Sorry.