About sending combination buttons

Some muds require of sending combination buttons to them, like: "Control + U", "Control + X", "Control + I", and so on.
I don't have any idea how to do with mushclient. Still need Nick's help.

Seems a bit strange. Do you mean inside a message? Or just on its own?

To do it on its own (ie. you press Ctrl+I and it sends it immediately) you could do this:



This makes an accelerator (Ctrl+I) which, when you hit it, sends Ctrl+I (hex 09) to the MUD.

You could make similar ones for the other letters. ("I" is the 9th letter, so "U" would be 21, and so on).

You would want to put this into a "startup" script (that runs on world open, for example). Make sure Lua scripting is enabled, and you have "/" as the script prefix.

/SendPkt (string.char (9)) -- Ctrl + I
/SendPkt (string.char (21)) -- Ctrl + U

I also want to send a ArrowUp, ArrowDown, ArrowRight, ArrowLeft, PageUp, PageDown, Home, End, Delete, Backspace, Space, Tab, Alt, Esc, F1...

May I get a table list?

Why do you want to send those? It is working against the way the client is designed somewhat. Those keys are supposed to scroll around your command window, not be sent directly.

For example, backspace backspaces the last thing typed in the command window.

Are you sure you want to use MUSHclient for whatever it is you are doing?

Try checking out PuTTY:

http://www.chiark.greenend.org.uk/~sgtatham/putty/

That would send all those keys directly.

I can think of some use cases where I would actually want to send those characters to the server. I mentioned a character mode a while ago where a MUD could implement shell-like autocompletion, which would require that characters be sent one at a time -- this is an immediate extension of that idea.

Now, maybe it is pushing the envelope a bit, but I would definitely like to have that power during, say, OLC.

Google for "ASCII chart" - you will find plenty.

Dec Hex Octal Binary Graphic Ascii Meaning
0 0 0 00000000 ^@ NUL (null)
1 1 1 00000001 ^A SOH (start-of-header)
2 2 2 00000010 ^B STX (start-of-transmission)
3 3 3 00000011 ^C ETX (end-of-transmission)
4 4 4 00000100 ^D EOT (end-of-text)
5 5 5 00000101 ^E ENQ (enquiry)
6 6 6 00000110 ^F ACK (acknowledge)
7 7 7 00000111 ^G BEL (bell)
8 8 10 00001000 ^H BS (backspace)
9 9 11 00001001 ^I HT (horizontal tab)
10 A 12 00001010 ^J LF (line feed - also ^Enter)
11 B 13 00001011 ^K VT (vertical tab)
12 C 14 00001100 ^L FF (form feed)
13 D 15 00001101 ^M CR (carriage return)
14 E 16 00001110 ^N SO (shift out)
15 F 17 00001111 ¤ ^O SI (shift in)
16 10 20 00010000 ^P DLE (datalink escape)
17 11 21 00010001 ^Q DC1 (device control 1)
18 12 22 00010010 : ^R DC2 (device control 2)
19 13 23 00010011 " ^S DC3 (device control 3)
20 14 24 00010100 ^T DC4 (device control 4)
21 15 25 00010101 § ^U NAK (negative acknowledge)
22 16 26 00010110 - ^V SYN (synchronous idle)
23 17 27 00010111 ^W ETB (end of transmission block)
24 18 30 00011000 ^X CAN (cancel)
25 19 31 00011001 ^Y EM (end of medium)
26 1A 32 00011010 ^Z SUB (substitute)
27 1B 33 00011011 ^[ ESC (Escape)
28 1C 34 00011100 ^\ FS (field separator)
29 1D 35 00011101 ^] GS (group separator)
30 1E 36 00011110 ^^ RS (record separator)
31 1F 37 00011111 ^_ US (unit separator)
32 20 40 00100000 Space
33 21 41 00100001 ! !
34 22 42 00100010 " "
35 23 43 00100011 # #
36 24 44 00100100 $ $
37 25 45 00100101 % %
38 26 46 00100110 & &
39 27 47 00100111 , ,
40 28 50 00101000 ( (
41 29 51 00101001 ) )
42 2A 52 00101010 * *
43 2B 53 00101011 + +
44 2C 54 00101100 , ,
45 2D 55 00101101 - -
46 2E 56 00101110 . .
47 2F 57 00101111 / /
48 30 60 00110000 0 0
49 31 61 00110001 1 1
50 32 62 00110010 2 2
51 33 63 00110011 3 3
52 34 64 00110100 4 4
53 35 65 00110101 5 5
54 36 66 00110110 6 6
55 37 67 00110111 7 7
56 38 70 00111000 8 8
57 39 71 00111001 9 9
58 3A 72 00111010 : :
59 3B 73 00111011 ; ;
60 3C 74 00111100 < <
61 3D 75 00111101 = =
62 3E 76 00111110 > >
63 3F 77 00111111 ? ?
64 40 100 01000000 @ @
65 41 101 01000001 A A
66 42 102 01000010 B B
67 43 103 01000011 C C
68 44 104 01000100 D D
69 45 105 01000101 E E
70 46 106 01000110 F F
71 47 107 01000111 G G
72 48 110 01001000 H H
73 49 111 01001001 I I
74 4A 112 01001010 J J
75 4B 113 01001011 K K
76 4C 114 01001100 L L
*****too much data*********


I searched this table for a long time, but it's hard to find out direction buttons...

Now yet I lack of:
ArrowUP, ArrowDown, ArrowLeft, ArrowRight

It would be better if also supplying: Home, PageUp, PageDown, End.

Directionals are sometimes done using the ascii, for some. For example, "line feed" is *technically* the same as down arrow, even though it doesn't end up working that way, instead replacing "carriage return", or the combo of the two, which as I said some place else, is *technically* the correct sequence. However, most telnet systems that used a character by character system probably use the "code" for a character, which unfortunately would screw up UTM-8 and Unicode, both. Why? Because, I am not sure what it would do with UTM-8, but in unicode a two character code in the "0 + X" set is the "standard ascii" letter for that, not a function key. The correct codes, if using something that doesn't know about Unicode/UTM-8 are the ones generated by the keyboard codes, and those are:

Up - 0 + 72
Down - 0 + 80
Left - 0 + 75
Right - 0 + 77
PgUp - 0 + 73
PgDn - 0 + 81
Home - 0 + 71
End - 0 + 79

Basically, there is no direct way to send them normally, and if you are using UTM-8 or Unicode, I am not sure they supply any way to send command codes at all, other than the basic set. Now, on Apple IIs, they did use the ascii for it, I think it was something like:

up = ?? VT maybe?
down = LF
Right = HT
Left = BS

Noting that BS does not "erase" a character, it merely moves you "back one space", so you can type over the last position. FF was used as a sort of PgDn, since that "scrolls" the entire visible page off the screen. It was the only way Apple IIs could "do" a clear screen. Other things like PgUp or Home/End, where a bit iffier. Maybe EOT for End, but again, no "Home", unless they where using SOH... Lets face it, modern clients, with all the fancy stuff they do, are not really meant to do character by character negotiation, or handle the use of things like PgUp/PgDn.

Now, this isn't to say you couldn't *if* you had a relatively modern keyboard (like all of them now), and you assigned the "keypad" set as ones to send to the mud, and the separate set as ones to "control the client". But, a) reading which is which is more complicated than just getting the basic codes, and b) in Mushclient the keypad is used for movement of the character. Mind you, turning on/off numlock isn't that hard, so, it might be possible. Its just more complicated, since the client doesn't know the difference, as far as I know, between the _|_ version of the arrows/paging keys and the keypad. I can't be sure though, since I don't know how the internals of the accelerators work, or if those "correctly" return the "state" of the numlock, or just the keycode, without testing the state first. In other words, the raw code might say, "Keypad home", but something else would be needed to check, "Is Numlock on?"

Can you please explain why you want to do this?

PageDown key causes an event that the program traps, and causes the page to scroll up or down.

There is no single "page down" ASCII character you can send to a MUD, although no doubt there is a telnet sequence (series of bytes) that some telnet servers will recognise.

This is so far removed from normal requests I get for MUDding, I am wondering if you are talking to a MUD at all. Can you tell me which one it is?

There are so many games embedded in telnet servers. Let me feel like just as I'm playing mud.

For me it is used primaryly for grabbing life information though. Whereupon it uses direction buttons often to manipulate this system.

So that you could easily read any information you want.

To sum up, I wish mushclient can do all the things that telnet can do. 'Cause recently I got a pet to feed

It's a foreign website. telnet ptt.cc

But it won't. Next thing you will want is cursor addressing of the output buffer. Stuff like clear screen, positioning the cursor to anywhere on the screen, and so on.

It isn't designed for that.


If you want a telnet client try PuTTY like I suggested, or something else along those lines.

I think you are my Aladdin's lamp - able to fulfill all my wishes! Are't you, my Nick?

Unfortunately for you, the issue of full telnet emulation has come up over and over again in the forums and due to deep-set technical reasons, it is quite unlikely that Nick will change that. (His reasons, incidentally, are good.)

Fortunately for you, MUSHclient is now fully open source, so you or somebody else is welcome to make this change. :-)

I want to try those telnet sequences! They could be recognized by some telnet servers, couldn't they?

If there is a possibility, I would like to take a try! May I have telnet sequences?

I know Nick is the best person all over the world and he never hurt anyone's little awaiting soul...

Nick Gammon:


Ocean:


You haven't exactly answered my question. If you tell me the name of one I can look at it and perhaps help you better.



Somehow I don't think this will work. Maybe we can send the telnet sequence (try Google for "telnet sequence arrow keys"), but MUSHclient is not designed to move the cursor around when the server responds to them.

It is the wrong program for the job. It isn't designed to do that. Try PuTTY or another program which is designed to handle (and send) telnet sequences.



Ah I see. Doesn't look like a MUD. A MUD client won't help you there.