Gammon Forum : MUSHclient : Suggestions : Escape Sequence support

Entire forum ➜ MUSHclient ➜ Suggestions ➜ Escape Sequence support

Escape Sequence support

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by

Eos USA (52 posts) Bio

Date

Sun 19 May 2002 07:35 AM (UTC)

Message

Can support for vt100, vt220 etc, escape sequences be added in?
Specifically I'd be thrilled to have the [2J clear screen made functional for the next release,
and Yes I do know there is a clear screen option. There is however no way for the mud itself to clear the clients screen and redraw the screen, or parts of it.
(http://www.fastlane.net/~generic9/vt220.html)

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #1 on Sun 19 May 2002 07:45 PM (UTC)

Message

This and other things where as I understand it left out due to the complexity of figuring out how to use them with a scroll back buffer. There are probably ways to do it, but they would likely require that the 'state' of the page be saved to the scrollback at the time the clearscreen is recieved, instead of everything recieved to that point. This is bound to seriously complicate things. lol I frankly have the same gripe about not having support for flashing characters and the fact that having 'show' italic, bold and underline have to be turned off or they override the 'normal' ansi behaviour. This is neither appropriate nor useful in many cases. All of these things will likely require a mjor rework of the way the client current performs.

Note to Gammon- One solution is as I say to treat a page clear as a 'save the state of things as they are now', basically ignoring any/all text positioning or other inconvenient attributes at that point and only saving the 'last' condition that the text had at the moment the command was recieved. Then in the log, if saving the ansi - log everything or in plain text - just log anything that changes the text positions as if it was followed by a newline (i.e. set the column the same by padding spaces, but ignore the vertical positioning completely). It isn't perfect, but I am pretty sure this is what the program Telemate I used to use 12 years ago to log onto BBSs worked. Now the flashing attribute though..... ;)

Top

Posted by

Eos USA (52 posts) Bio

Date

Reply #2 on Sun 19 May 2002 08:41 PM (UTC)

Message

Nick already has code defined to clear a screen. It isnt that hard to listen for the 0x1B escape sequence, and then call the clear screen function if the next two characters are 2J.
I was able to make a copy of TinTin do it in less than 12 lines, so I'm fairly certain Nick could do this without too much trouble.
The blinking on the other hand I agree with him entirely on. Its rather messy, cause it would have to cycle through the visible output to do it, and constantly. Not really hard, but definitely unpleasant.

Top

Posted by

Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #3 on Mon 20 May 2002 01:10 AM (UTC)

Message

Quote:

Can support for vt100, vt220 etc, escape sequences be added in? Specifically I'd be thrilled to have the [2J clear screen made functional for the next release.

I get asked this every few months, so I'll try to explain why it isn't practical.

In the old days - many years ago - dumb terminals (like VT100, VT200, TVI912 etc.) where just bits of electronics with a screen. They would display 24 lines of 80 characters, and that was that.

The early models just scrolled, so that when new text arrived, the previous stuff disappeared off the top of the screen and was lost.

Then later ones introduced the idea of "cursor addressing" (hence the "escape" codes), so you could put the cursor to anywhere on the screen (within the 24 lines, 80 columns).

To make this really useful, they also added "clear screen" so you weren't just overwriting previous junk.

However this concept doesn't really carry over very well to MUD clients.

MUSHclient doesn't have 24 lines, it has up to 500,000. Do you really want a "clear screen" to remove 500,000 lines of scrollback? The whole point of the scrollback buffer is so that you can review recent messages (tells etc.), recent room descs, and other useful stuff. To lose all of it at the whim of the server would seem a bit extreme.

If it doesn't clear all those lines, then what does it do? Say, the screen goes blank, maybe that could be done, but what happens when you scroll back? Say, each room started with a "clear screen". How do you represent those "clear screens" as you scroll back with the scroll thumb, or pressing "Page Up"? A whole lot of blank lines?

I'm sorry, but I don't see it working. MUDs are by their nature scrolling things. I can see what you are hoping to see visually, but I don't see how scrolling would work.

I also don't see how cursor addressing will work. For example, at present, MUSHclient evaluates triggers at the end of a line. If the cursor addressing makes the cursor jump from line 1 to line 5, then line 3 and then line 2, when does line 3 actually end? When does the trigger get evaluated?

Quote:

I frankly have the same gripe about not having support for flashing

I'll see what I can do about flashing text. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by Shadowfyr USA (1,791 posts) Bio

Date

Reply #4 on Mon 20 May 2002 01:26 AM (UTC)

Amended on Mon 20 May 2002 01:30 AM (UTC) by Shadowfyr

Message

Ok.. Again.. I used a program called Telemate a lot when playing on BBSs years ago. It displayed 80x24 or 132x50 or what ever mode you could convince the video display to switch into. I used a really odd 80x28 mode with mine. It also implimented a scrollback. The feature worked by treating eaverything in the scroll back as though it was a continuous scroll and 'only' cleared what was actually within the visible window when dealing with text positioning and clear screen. I think it also treated clearscreen as a sort of page break, so when ever you scrolled over one the page would clear and you would be looking at the bottom of the previous 'page'. Text positioning was handled by allowing it in the visible lines currently being displayed, but when the line scrolled out of this visible area the backscroll only save the 'state' of that line at the time it passed out of the visible area. In the log (when full ansi output was turned off) it simply treated each text command as a space padded string, so 'move right 2 and display XX' became:

'  XX'

In esence you don't need to 'clear' the entire buffer, just use as a page break that clears the screen when you scroll over it before continuing to display the buffer contents. It really doesn't make sense to clear everything anyway, since a 5000 line buffer could have 100 - 50 line pages, 200 - 25 line ones, or just about anything else.

The only minor quirk in this is that you need to treat the last page-up before a clrscr as a 'top of page' command or you end up missing those lines. It is possible to do though.

Top

Posted by

Magnum Canada (580 posts) Bio

Date

Reply #5 on Mon 20 May 2002 03:51 AM (UTC)

Message

Regarding ClearScreen only, you could put a tag like this:

[CLEARSCREEN]

...in the scrollback buffer and logs. Visually, the screen would clear, and the tag would not be visible, but if I scrolled up, the most recent line would have that tag, preceded by whatever text had been output before that, etc.

Optimally, such tags would be displayed in customized FG/BG colours (and font even), according to the users configuration.

Personally, I would expect there would be a configuration option to ignore such output from the mud, which I would do... for I agree with Nick, I don't want my screen cleared or the cursor to move around, it's not really appropriate for muds... which are closely related to IRC channels.

Also, I REALLY don't want the client to suffer a big performance hit because it is working to update flashing characters on the screen, etc.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #6 on Mon 20 May 2002 10:49 PM (UTC)

Message

Well, Magnum.. Appropriate can mean quite a few things. The map thing on AoD is not too different than one used on an old BBS game called Lands of Devistation. Is it appropriate? Another fairly popular one was called Tradewars 2002. 90% of everything in it was simple scrolling of one bit of info after another, just like a mud, but it also had a quirky 'theater' you could visit that played ansi 'movies'. As for performance hits... Eventually MXP is going to start being used more and will include pictures and possibly even animated GIFs. How flashing a bit of text can produce more overhead than that I can't imagine, but there is no real point to having MXP support in a client and simply assume that such a feature won't eventually become not mearly an interesting quirk, but a necessity. True, muds don't generally use such features, but that does not mean they are completely useless or that there are not some cases where they wouldn't 'enhance' the play, they just haven't been used often. I am not sure that it would produce much of a performance hit anyway, it depends a lot on implimentation.

This is sort of like the excuse I have heard from a number of people about why it is a bad idea to use an LPMud under windows. The arguement being that windows sockets don't work well, blah, blah, blah.. Only every atempt that has been made to port LPMud, MudOS, etc. has been some form of shoehorning code not designed for windows sockets onto a windows system. Of course it won't work right. This is the same thing. Shoehorning full ansi compliance into the existing output window code is bound to cause problems and won't work, especially since it would still need to be changed yet again when/if Gammon provides full support for addition MXP features. The other arguement is that making one that was easy to use would promote bad muds, kind of like interchangable parts in cars led to more drunk drivers....

I really can't agree with the idea that simply because muds tend to treat everything like IRC channels that this behaviour is the best, most appropriate, the only form of activity one should expect from them or is all that should be supported in a client. There have already been at least two people posting on these forums that think otherwise (as one has to assume, do the admins of those sites). 90% of the times cars only travel forward and they would certainly be much more effecient if they only had foreward gears, but what happens the other 10% of the time? ;) I doubt most people would consider the minor drop in performance that does result as equal to the inconvenience of not having a reverse gear. While I don't currently have a major problem with it, there are definitely others that do and there could be more in the future.

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

21,805 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top