Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, 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
|
Posting of new messages is disabled at present.
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,122 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,122 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,122 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,122 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,122 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.
61,728 views.
This is page 1, subject is 2 pages long: 1 2
Posting of new messages is disabled at present.
Refresh page
top