Using the "\x1b[2J\x1b[H" Screen Clear Control Sequence with MUSHClient

I've been fiddling with various bits of code lately, and OasisOLC happens to be one of them. OasisOLC uses a version of the Screen Clear sequence to clear the screen so that the "menus" are plainly visible without having to see previous menus. But while testing it on various clients, I've noticed that MUSHClient (version 4.40) Will parse out the code and then appears to ignore it. Where Telnet and zMUD will parse it and clear the screen before displaying the next set of output.

An example from a Smaug port of OasisOLC (in a slightly modified version of SmaugFUSS.):


The code I'm currently fiddling with is for a Menu-esque based Character creation sequence that makes use of the screen clear sequence to simulate a sort of Computer interface. For example:


As I said, zMUD and Telnet both handle this sequence in the expected manner. While MUSHClient 4.40 appears to just ignore the sequence. Is there anything special I need to do code-wise, or in the client to get it to register and react in the expected fashion or is this something that MUSHClient just isn't built for?

It's not a terribly huge deal if it doesn't work for people using MUSHClient, or really for any client, but I found it to be rather humorous and figured I'd make use of the code in the only place I could think of. As an aside, GMud handles it in a much more.. grotesque manner, even going so far as to display a partially parsed version of the sequence.

MUSHclient doesn't do terminal emulation, in the sense that it doesn't handle cursor movement sequences, or clearing the screen. After all, with thousands of lines of scrollback, you don't really want them cleared, so the most it could do is insert a few blank lines, which would be annoying when you scroll back.

I suggest inserting a couple of blank lines yourself before the menus, that should be adequate.

How hard would it be for a "clear screen" directive to cause the output window to scroll such that the next line is printed to the top of the window? I imagine that this might be difficult because you might need some notion of 'virtual lines': lines that take up space in the output window for the purposes of positioning the scroll bar and other visible text, but that otherwise don't exist, and are replaced by new lines as appropriate.

Well it would throw out the logic that translates physical lines (ie. when you click with the mouse) to where they are in the output buffer.

Yeah, we have gone over this before and not gotten much cooperation. lol Most telnet style clients that *support* this, and still maintain a back buffer, tend to treat the command like a "page break", much as word treats it. Scrolling won't "lose" the prior page, it just shifts the entire contents of the window up, so the next page starts at the top, or down, so that the "end" of the last page is on the last window line, as you scroll. The actual buffer is still intact.

Text positioning stuff, like moving the cursor, tends to work similarly, but it either a) presumes that you have a fixed window size, so knows how much will be "on screen" during the operation to save the result *or* b) any line that scrolls off the visible screen becomes "fixed" in the state it had at that moment. Its up to the server end to make sure that it isn't trying to change characters on a line that isn't there anymore.

Of these two, tracking a page break is probably fairly simple, since it only effects what is visibly on the screen, not the buffer, and thus shouldn't be a problem. If someone is trying to muck with some line that isn't any longer displayed, then its going to get pulled from the buffer anyway, not the visible screen, right? I never saw the problem here.

This is mainly because of the design issues.



So, MUSHclient isn't the only one that isn't cooperating?

OK, let's imagine that, as part of this menu sequence, a few menus appear in quick succession. As you scroll back, then if a particular menu is going to appear "on a blank screen", then it follows that each menu should do that, so what was once a nice screenful showing what you received is now truncated down to one menu at a time, with them flickering on and off as you scroll back.

I honestly think it would look ugly. Then you have the issue that when you click on the screen to select something, the calculations which relate the pixel position to somewhere in the buffer become much more complex.

[EDIT] Fixed second quote's author.

Hmm. Forget to set the second one to the correct author? ;) lol

But, yeah. That does represent an issue. Not sure "much more complicated" is accurate, but definitely not as simple as it was. The real question is, "how much more?". But, yeah.

To the original author: On the server side you could try to get the terminal-height (this is a telnet-negotiation) of the client and send that amount of Newlines.
It wouldnt put the next line on the top of the screen and would be kind of a workaround for Mushclient, but you would have "cleared" it in a way.

Well, it'd be possible/simple enough to make a plugin to clear the screen when the client receives that code, just by processing the incoming lines/packets. and then calling DeleteOutput() Again, this might tick some people off that they're losing all their scrollback.

Heck, I was just recently thinking if the client somehow remembered unsupported escape codes(maybe somehow in the style info or something?) or if you directly processed incoming packets/lines(also allowing it to go through regular processing so it'd still show up in scrollback) that it'd be possible if somebody had the time and motivation to actually code it to create a plugin to do terminal emulation in a miniwindow. You could create a miniwindow the size of the output window or maybe a bit smaller, maybe add a close/minimize button to the side and just draw the output to it allowing you to handle escape codes however you want while still retaining scrollback in the main window underneath. I don't think it'd be /total/ emulation, but it'd get the main stuff like clear screen, cursor movement, heck with the help of a timer, maybe even blinking that people have been wanting so long, etc. It'd be quite a bit of work though, so good luck to anybody who wants to go about it.

Most people.

Here's a simple solution I came up with (for Lua, but the premise is the same in any other language)



GetInfo(280) returns the current output buffer height, in pixels. GetInfo(241) returns the height of a single character in the buffer. Division results in the number of lines visible on-screen. Note() that many times... voila, clean slate.


EDIT: Hey, Nick, what's the difference between GetInfo(241) and GetInfo(112)? I get the same number for each, and their descriptions seem pretty similar too:

Wait.. If that is the entire buffer, then... Wouldn't it make more sense to have a "get size of output window", divide that by the height of the character, then only use "note()" to generate as many lines as needed for the window?

In any case, we do have the code now, so maybe it would just be more effective if we found someone that had an idea how to implement a real fix.

Isn't that exactly what I did? :P

EDIT: Okay, I said "output buffer height". I suppose that could be construed as "size of the whole buffer", but it's not; I meant the visible part, i.e. the output window. Try it, it works.

They are the same variable. It seems when I added 241, I didn't notice I already had done that.

Ah, okay. Just curious :)

Couldn't you just make mushclient interpret that sequence to scroll the window so all of the output that's received after it is displayed at the top of the screen? is there a way to do this with a plugin?

Certainly you could do that in a plugin. Search for examples using the plugin callback OnPluginPacketReceived.

You would need to use that because control sequences are processed by the client (however not before OnPluginPacketReceived is called).

A simple method would be to search for the string you mention, and then display a dozen or so blank lines. A more complex method would find the number of pixels in the output font height (using GetInfo) and the number of pixels in the output window, and calculate the number of lines you needed.

However I'm not sure it is really a great idea. If the screen clears often (eg. when you change rooms) then the output buffer is going to fill up rather quickly with annoying numbers of blank lines.

Still, you can do it if you want to.

Whoops, didn't notice this was page 2 of an old thread. In that case, my earlier comments apply as well. :)