Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ General ➜ Using the "\x1b[2J\x1b[H" Screen Clear Control Sequence with MUSHClient
Using the "\x1b[2J\x1b[H" Screen Clear Control Sequence with MUSHClient

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

Pages: 1 2  

Posted by Kayle   (5 posts)  Bio
Date Tue 13 Oct 2009 07:16 AM (UTC)
Message
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.):
void medit_disp_sex( DESCRIPTOR_DATA *d )
{
   write_to_buffer( d, "50\x1B[;H\x1B[2J", 0 ); //This is the screen clear
   d->character->print( " &[olc1]0&[olc6]) &[olc2]Neutral\r\n" );
   d->character->print( " &[olc1]1&[olc6]) &[olc2]Male\r\n" );
   d->character->print( " &[olc1]2&[olc6]) &[olc2]Female\r\n" );
   d->character->print( "\n\rEnter gender number : " );
}


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:
write_to_buffer( d, "\x1b[2J\x1b[H", 0 );
   send_to_desc_color( "\r\n&r+&z---------------------------------------------------------------------------&r+&D\r\n", d );
   send_to_desc_color( "&z|&w                       Input Accepted. Verifying.                          &z|&D\r\n", d );
   send_to_desc_color( "&r+&z---------------------------------------------------------------------------&r+&D\r\n", d );


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.
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #1 on Tue 13 Oct 2009 08:40 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #2 on Wed 14 Oct 2009 04:40 PM (UTC)
Message
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.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #3 on Wed 14 Oct 2009 07:59 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #4 on Wed 14 Oct 2009 08:29 PM (UTC)
Message
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.
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #5 on Fri 16 Oct 2009 03:55 AM (UTC)

Amended on Sat 17 Oct 2009 04:23 AM (UTC) by Nick Gammon

Message
Shadowfyr said:

Yeah, we have gone over this before and not gotten much cooperation.


This is mainly because of the design issues.

Kayle said:

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.


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #6 on Sat 17 Oct 2009 04:16 AM (UTC)
Message
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.
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #7 on Sun 18 Oct 2009 04:14 PM (UTC)
Message
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.
Top
Posted by Cage_fire_2000   USA  (119 posts)  Bio
Date Reply #8 on Tue 20 Oct 2009 08:24 PM (UTC)
Message
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.

Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #9 on Wed 21 Oct 2009 12:14 AM (UTC)
Message
Cage_fire_2000 said:

Again, this might tick some people off that they're losing all their scrollback.


Most people.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #10 on Wed 21 Oct 2009 01:00 AM (UTC)

Amended on Wed 21 Oct 2009 01:12 AM (UTC) by Twisol

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

for i=0,GetInfo(280)/GetInfo(241) do
  Note()
end


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:

Quote:

212 - Output font height
241 - The height, in pixels, of a character in the output window, in the current output font.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #11 on Wed 21 Oct 2009 07:46 PM (UTC)
Message
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.
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #12 on Wed 21 Oct 2009 09:22 PM (UTC)

Amended on Wed 21 Oct 2009 09:24 PM (UTC) by Twisol

Message
Shadowfyr said:
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?


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.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #13 on Wed 21 Oct 2009 09:47 PM (UTC)
Message
Twisol said:


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:

Quote:

212 - Output font height
241 - The height, in pixels, of a character in the output window, in the current output font.



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

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #14 on Thu 22 Oct 2009 12:22 AM (UTC)
Message
Ah, okay. Just curious :)
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
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.

60,692 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

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

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home