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.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUDs
➜ General
➜ 'Immediate' input mode
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Thu 10 Aug 2006 09:37 PM (UTC) |
Message
| It occurred to me that a MUD could behave somewhat like a Unix shell, with things like tab-completion for commands. So, you could type 'invento<tab>' and it would come out as 'inventory'.
For this to work, the MUD would have to process input character-by-character, like a shell, as opposed to only processing after a newline is received. Also, the MUD client might need to support some kind of basic cursor control, perhaps at least just to move the cursor back to the beginning of the line. This would be important if the player pressed backspace, since the MUD would have to remove the character typed from the client's screen.
The main advantage I see is for things like tab-completion, or like vi 's Ctrl-D, which gives you a list of available completions.
For instance, you could type goto 24<ctrl-D> and it would list all vnums that start with 24.
Does anybody else think this would be nifty? I don't believe MUSHclient supports cursor movement so this probably wouldn't work in MUSHclient, but I think there's a fair amount of potential as a general concept. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Conner
USA (381 posts) Bio
|
Date
| Reply #1 on Fri 11 Aug 2006 07:06 AM (UTC) |
Message
| Yeah, it'd be very nifty, but just think of all the havoc it'd create and fun you could have when someone mistypes something and, for example tries to 'say' something that otherwise begins with a command that they really didn't want to perform.. as an example, if they're playing a smaug mud and they're intent was to ask a group member if they're ready to kill a mob but they left off the word say in their haste so the mud recieves 'kill m?' and decides to have the character now illegal pk their group member who's name happens to begin with M... and that's just the quickest easiest example I could think of. *snicker* |
-=Conner=-
--
Come test your mettle in the Land of Legends at telnet://tcdbbs.zapto.org:4000
or, for a little family oriented medieval fun, come join us at The Castle's Dungeon BBS at telnet://tcdbbs.zapto.org
or, if you just want information about either, check our web page at http://tcdbbs.zapto.org | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #2 on Fri 11 Aug 2006 07:36 AM (UTC) |
Message
| I don't think this is a great idea, mainly because of speed, and also because you are moving something that can largely be done at the client end, and making the server do it.
MUSHclient already has tab-completion, and you can make a custom list (words like "inventory") so that it can tab-complete commands, as well as recent words in the output window.
The reason I think it would be slow is because of network latency. Say that there is a 100 ms delay for a network packet to get from you to the server (and another one to get back again). That is 0.1 second each way, which you don't really notice if you type a whole command, and it reacts half a second later.
However imagine that the server also takes around 0.1 second to process a character from the client (because it is doing something else the exact moment the character arrives).
Now you are typing: "go north" (8 characters). For each character there is a 0.1 second network delay, a 0.1 second server response time, and a 0.1 second delay while the response it sent "display 'g' on the screen".
Now our 8-character command is taking 2.4 seconds to process (8 * 0.3 seconds).
In fact, this sluggish behaviour is exactly what I see when I use my shell account on my (hired) web server. It is very annoying.
The whole idea of sending a character at a time is also making very poor use of internet bandwidth. For the client to send individual characters, each one must be in a packet with something like a 20-byte packet header, so that is a 21 byte packet, 20 bytes of which is overhead.
It is a nice idea to see the available vnums like you suggested, but perhaps a simple command at the server end would achieve the same result? Or with a bit of consultation with the client (eg. triggers etc.) it could download all available vnums (say, at the start of a session) which are stored locally. Then a simple keystroke could invoke a menu that displays them along the lines of what your idea.
Things like the Lua utils.listbox function would let you populate a list with matching vnums, and then let you select one. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #3 on Fri 11 Aug 2006 03:25 PM (UTC) |
Message
| Conner: I'm not sure if that'd be a problem with this system and not a problem already, right?
Nick: I've rarely had such bad latency when communicating with a server, but it does happen from time to time, yes. Whenever I work on the Darkstone code it's on the remote server and things work pretty well. Furthermore you don't have to wait for the round-trip before typing the next character, so you'd really be getting the final result displayed 0.1 (or 0.2) seconds after you've finished typing, not NumChars*0.3 seconds.
I hadn't imagined this as a permanent input mode, but rather something you could turn on or off when you needed it. It's really not the same as client-side completion, because that often picks up words I really don't want -- it's not context sensitive. I might want to type something like 'look m<tab>' and have that expand to the things I can look at starting with 'm', not all words the client has ever seen with 'm'.
The important part here is that the server is the one aware of the context of the commands, not the client. I suppose that the server could communicate all of this information to the client, but that's supposing an awful lot of implicit communication, in fact, it would basically require a new extension protocol of sorts. The immediate mode, on the other hand, really requires just two things of the client:
- being able to send characters one at a time (or, being able to trigger the sending of the current contents, with a <tab> instead of a <cr/lf> at the end)
- having very basic cursor control, such as clearing the current line and moving back to the beginning of that line. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Conner
USA (381 posts) Bio
|
Date
| Reply #4 on Fri 11 Aug 2006 09:47 PM (UTC) |
Message
| Ok, I'll admit it is an issue that already exists, but something like you'd described would only exasperate the issue for the average player, maybe more so for the average immortal. On the other hand, if, as you said in this second post, it were togglable or only applied to context sensitive things, it'd actually be pretty cool. But as you also already pointed out, at that point you're talking about a whole new protocol already.
In the hypothetical sense though, yes, I think it'd be really nice (especially if it lacked the lag factor) to be able to type a command which took an argument and have the mud be able to autocomplete the argument for you based on what valid possibilities existed in context. To some extent, I think that's what MCP (?) was supposed to do, though in a more mouse friendly fashion. Unfortunately, my understanding is that no one ever really got the client support for it quite right to date. *shrug* |
-=Conner=-
--
Come test your mettle in the Land of Legends at telnet://tcdbbs.zapto.org:4000
or, for a little family oriented medieval fun, come join us at The Castle's Dungeon BBS at telnet://tcdbbs.zapto.org
or, if you just want information about either, check our web page at http://tcdbbs.zapto.org | Top |
|
Posted by
| Jon Lambert
USA (26 posts) Bio
|
Date
| Reply #5 on Sat 12 Aug 2006 05:13 PM (UTC) |
Message
| TeensyMud works in character mode. It translates most of the VTxx key codes input into a markup language. While auto complete is not in the current version, it can be easily added.
| Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #6 on Mon 14 Aug 2006 03:17 PM (UTC) |
Message
| Actually, what I described doesn't require a new protocol if the server is handling all this stuff. A new protocol is required if and only if the client needs to do some of the work, because then you need a way for the server to describe to the client what the possible interactions are. What I have proposed doesn't require a new protocol; it would make the MUD server behave like a shell run over telnet. The toggling would be client-side, and would only affect the chunks in which the client sends data over.
I'll have to look at TeensyMud and see how it takes advantage of this. I'm convinced that there would be several places where it could be very useful; here's another example:
mset guard c<tab>
This would then propose a list of completions for what you can mset on the guard that starts with a 'c'. This would not be possible with client-side completion, unless the client has seen all such options, and furthermore, the client would propose many completions that are not relevant (due to not being context-sensitive).
I think you're talking about MXP, which lets menus be associated with various words ('hyperlinks') in the MUD output. MXP, when supported, is supported well, it's just not supported by many clients. MUSHclient has nearly full MXP support; the only things it lacks, according to my understanding, is messing around with font sizes, and the frames business. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #7 on Tue 15 Aug 2006 01:07 AM (UTC) |
Message
| It is MCP, see this page:
http://www.moo.mud.org/mcp/
Mud Client Protocol - it has some sort of "out of band" idea where you could possibly do this sort of stuff - things that are not part of the main communication, not that I read a huge amount about it. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Jon Lambert
USA (26 posts) Bio
|
Date
| Reply #8 on Tue 15 Aug 2006 02:57 AM (UTC) Amended on Tue 15 Aug 2006 02:59 AM (UTC) by Jon Lambert
|
Message
| The markup is decribed here (although the code is the final doc):
http://teensymud.kicks-ass.org/wiki/show/TeensyMarkupLanguage
It's used as both input and output. Output is pretty obvious, TML is translated to VT codes. For input I have a VTxxx/Xterm state machine which translates input into TML that the Mud Engine will see as..
cast fi[tab]
or
[F8]
That is exactly what is sent to the parser.
BTW the Windows-style shell completion with [tab] being a selector that iterators through the list of possibilities is exactly how I plan to implement it. I prefer that to bash (so much so that I have my bash shells set up as Windows-style auto-completion ;) )
Anyway in order to it, you need to keep two pieces of information on the client, a flag that indicates they are in autocomplete mode which preserves their input buffer, and an active iterator on the auto-complete possibilities.
| Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #9 on Tue 15 Aug 2006 03:43 PM (UTC) |
Message
| That could work, then, if the server, when it receives the partial input followed by a tab, sent back a list of completions. The client, as you say, would need some kind of minimal support for changing the dictionary of tab-completions. One could implement a prototype in MUSHclient relatively quickly, using the Lua popup-box. This all doesn't sound too outrageous, and I think the idea has lots of potential.
I also like the cycling mode of completion rather than bash's, but my fingers have gotten so used to it that changing bash to use cycle mode would be rather hard. vi uses the cycling mode, and you can also press <ctrl-d> to get a list of all completions. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Jon Lambert
USA (26 posts) Bio
|
Date
| Reply #10 on Wed 16 Aug 2006 12:56 AM (UTC) Amended on Wed 16 Aug 2006 01:07 AM (UTC) by Jon Lambert
|
Message
| No I meant that data I mentioned is stored by the server on behalf of the client. Nothing is needed client side. I assume the client is a NVT and only need support VTxxx/Xterm, or at the minimum in this particular implementation of auto-complete (using TAB), the ability to send data in character mode including the TAB character.
Many mud clients apparently will not do character mode, i.e. sending data as soon as it's available, as opposed to a psuedo line mode, sending data when the user hits enter.
I've tested it with clients that support telnet protocol (SUPGA and ECHO options).... Telnet, ZOC, Reflection, PuTTY (http://teensymud.kicks-ass.org/wiki/show/ClientData)
AFAIK it will not work using MushClient. According to those who use Zmud, there is a character mode option and it will work with Zmud, though I have no way of verifying it since I will not use Zmud.
| Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #11 on Wed 16 Aug 2006 05:10 PM (UTC) |
Message
| It's true that MUSHclient doesn't do full xterm/VT support. Nick has discussed in the past the big issues it poses for things like logging and triggers, not to mention the internal architecture not necessarily being suited for it. Personally, I feel that if the user is willing to deal with messed up logs, then the user should be able to make that choice; it would allow for some very nifty features that MUDs could use, actually redrawing parts of the screen selectively and so forth.
But anyhow... the character mode should be fairly easy to support, at the least if it can send the current contents of the buffer with some character (e.g. <tab>) appended to the end.
I'm really excited about this stuff; I think that there is lots of potential in extending the input/output model of MUDs to be more modern. Having a great client like MUSHclient is a must, for client-side scripting and the like; but what I haven't seen much in the mainstream codebases (e.g. SMAUG) is more complex server-side interaction, such as what we're talking about now. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Jon Lambert
USA (26 posts) Bio
|
Date
| Reply #12 on Thu 17 Aug 2006 12:16 AM (UTC) Amended on Thu 17 Aug 2006 12:17 AM (UTC) by Jon Lambert
|
Message
| I think that there is lots of potential in extending the input/output model of MUDs to be more modern.
Heh. I once expressed this on TMC by insisting that teletype was dead and it was time to leave the 60's and enter the 70's and support these new-fangled devices called network vertual terminals running under a new fancy protocol called telnet.
Muds that run on BBSes always supported this, see MajorMud and LoRD.
| Top |
|
Posted by
| Conner
USA (381 posts) Bio
|
Date
| Reply #13 on Thu 17 Aug 2006 02:03 AM (UTC) |
Message
| Actually, not only have muds that run on BBSes supported it, most BBS software does too, and always has. |
-=Conner=-
--
Come test your mettle in the Land of Legends at telnet://tcdbbs.zapto.org:4000
or, for a little family oriented medieval fun, come join us at The Castle's Dungeon BBS at telnet://tcdbbs.zapto.org
or, if you just want information about either, check our web page at http://tcdbbs.zapto.org | 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.
36,710 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top