25 Jan, 2013, Telgar wrote in the 1st comment:
Votes: 0
So, I'm getting around to implementing multi-line text input for my MUD and was wondering if anyone has ever come up with something better than the Diku /s saves /a aborts /h help .. etc system.

The full text editor I am working on supports single-keypress, word-wrapping, scrolling, etc.. but this requires rather advanced VT-100 features which aren't necessarily available to all clients (thinking mobile in particular). So I need to implement a dumbed down version as well, and the obvious choice seems to be this old school Diku system, which, despite sucking quite a bit IMO, a lot of players may already be familiar with.

Anyone refine this further since?
25 Jan, 2013, Kaz wrote in the 2nd comment:
Votes: 0
Telgar said:
The full text editor I am working on supports single-keypress, word-wrapping, scrolling, etc.. but this requires rather advanced VT-100 features which aren't necessarily available to all clients (thinking mobile in particular).


I just want to say that, as someone who has implemented this character-mode experience, you have absolutely the right concerns. Only the traditional terminal clients (PuTTY, TeraTerm, xterm, etc.) and TinTin++, in my experience, have the necessary capabilities in place for the really VT-100-heavy stuff. Not to fault the other clients at all: they all do precisely what they're designed to do, and do it well.

So if you haven't designed from the ground up to have that sort of thing in place, I would agree with your initial conclusion: stay line-mode.
25 Jan, 2013, KaVir wrote in the 3rd comment:
Votes: 0
Other clients may offer their own text editors, like this.
25 Jan, 2013, Telgar wrote in the 4th comment:
Votes: 0
Kaz said:
Telgar said:
The full text editor I am working on supports single-keypress, word-wrapping, scrolling, etc.. but this requires rather advanced VT-100 features which aren't necessarily available to all clients (thinking mobile in particular).


I just want to say that, as someone who has implemented this character-mode experience, you have absolutely the right concerns. Only the traditional terminal clients (PuTTY, TeraTerm, xterm, etc.) and TinTin++, in my experience, have the necessary capabilities in place for the really VT-100-heavy stuff. Not to fault the other clients at all: they all do precisely what they're designed to do, and do it well.

So if you haven't designed from the ground up to have that sort of thing in place, I would agree with your initial conclusion: stay line-mode.


Designed from the ground up. Have transparent terminal emulation working for Linux / OS X / Windows clients. You can connect for a session on Mac OS, reconnect on Windows, and the state of you view is not lost. We have windows with automatic resizing, shaded backgrounds, popups, modal dialogs, scrolling panes, etc, etc… oh Unicode support and multiple code page support so that Unicode characters get transliterated to an appropriate displayed character. Thus box drawing works transparently on both xterm like displays and plain old Windows telnet.

So yah, I'm totally covered on the PC base. The mobile experience I will need the least common denominator I think, hence the question…
25 Jan, 2013, Telgar wrote in the 5th comment:
Votes: 0
KaVir said:
Other clients may offer their own text editors, like this.


While that is cool, any client I will be catering to will be either plain old telnet or an HTML5 enabled browser. Any other clients, Abandon all hope, ye who enter here.
25 Jan, 2013, Kaz wrote in the 6th comment:
Votes: 0
Telgar said:
Designed from the ground up. Have transparent terminal emulation working for Linux / OS X / Windows clients.


Very nice!

Telgar said:
You can connect for a session on Mac OS, reconnect on Windows, and the state of you view is not lost. We have windows with automatic resizing, shaded backgrounds, popups, modal dialogs, scrolling panes, etc, etc… oh Unicode support and multiple code page support so that Unicode characters get transliterated to an appropriate displayed character. Thus box drawing works transparently on both xterm like displays and plain old Windows telnet.


I'm currently using the SCO character set* for box drawing; I haven't gone the way of unicode yet. Impressive stuff. I wouldn't mind taking a look.

Quote
So yah, I'm totally covered on the PC base. The mobile experience I will need the least common denominator I think, hence the question…


I recall one of my players using a terminal emulator on iOS that almost worked. Well, worked well enough for him to use, at least, even if it wasn't that pretty. But as I, too, have a long-term plan for supporting less VT-100-capable clients, I'm also interested in this topic.

* See http://www.mudbytes.net/index.php?a=topi...
25 Jan, 2013, KaVir wrote in the 7th comment:
Votes: 0
Telgar said:
While that is cool, any client I will be catering to will be either plain old telnet or an HTML5 enabled browser. Any other clients, Abandon all hope, ye who enter here.

You don't need to explicitly cater to them, the clients support it automatically, although you could make it easier by providing a clear indication of where the description starts and ends, displaying a raw version of the description (i.e., with colour codes rather than coloured text), and allowing the entire description to be replaced in one go.

For an in-game editor, I actually prefer editing commands rather a separate mode, but that's just a matter of personal taste.
25 Jan, 2013, Telgar wrote in the 8th comment:
Votes: 0
Loathe as I am to post a link to this site, it appears to be the only way to get a graphic up..

25 Jan, 2013, quixadhal wrote in the 9th comment:
Votes: 0
To really support character-mode full-screen editing, with arbitrary terminal types, you need to find a way to use the system termcap/curses library in the same way telnetd, sshd, and login do. Unfortunately, that probably means forking a new process for each connection, allocating a pty device and binding its STDIN/STDOUT/STDERR descriptors to your socket, and of course having it maintain a pipe to the parent process so I/O can happen.

It might be worth looking at the telnetd source from BSD or similar… although it may be more convoluted than you'd need.

Otherwise, you can just assume ANSI as your lowest-common-denominator terminal type and only allow full-screen editing if the user has a terminal that you recognize as a superset of it, AND give them a flag to set to disable it, in case they're using a client that lies about the terminal type.
25 Jan, 2013, Telgar wrote in the 10th comment:
Votes: 0
quixadhal said:
To really support character-mode full-screen editing, with arbitrary terminal types, you need to find a way to use the system termcap/curses library in the same way telnetd, sshd, and login do. Unfortunately, that probably means forking a new process for each connection, allocating a pty device and binding its STDIN/STDOUT/STDERR descriptors to your socket, and of course having it maintain a pipe to the parent process so I/O can happen.

It might be worth looking at the telnetd source from BSD or similar… although it may be more convoluted than you'd need.

Otherwise, you can just assume ANSI as your lowest-common-denominator terminal type and only allow full-screen editing if the user has a terminal that you recognize as a superset of it, AND give them a flag to set to disable it, in case they're using a client that lies about the terminal type.


Yeah, I know. I do all that. For real, yo. I actually have a converter to take in termcap files and import the appropriate sequences to Javascript. I don't assume anything about user's terminal type, I have something similar to the termcap or ncurses library, only we aint cookin' with C, we are cookin' with Javascript.

Course, it is true that the first terminal type I have added support for is VT-100. Always a good choice.
25 Jan, 2013, Telgar wrote in the 11th comment:
Votes: 0
quixadhal said:
Otherwise, you can just assume ANSI as your lowest-common-denominator terminal type and only allow full-screen editing if the user has a terminal that you recognize as a superset of it, AND give them a flag to set to disable it, in case they're using a client that lies about the terminal type.


And that I do for sure, VTEDIT is the flag to determine whether you should use the fancy-dancy VT editor or the dumb simple line mode editor.
25 Jan, 2013, quixadhal wrote in the 12th comment:
Votes: 0
If you already fork processes with ptys, why implement your own termcap stuff when you could use the system curses library? AFAIK, the main reason people don't just uses curses in mud code is that it has to be forked (it has nasty global state info, and assumes stdin/stdout), and most mud servers are multiplexed I/O.
25 Jan, 2013, Telgar wrote in the 13th comment:
Votes: 0
quixadhal said:
If you already fork processes with ptys, why implement your own termcap stuff when you could use the system curses library? AFAIK, the main reason people don't just uses curses in mud code is that it has to be forked (it has nasty global state info, and assumes stdin/stdout), and most mud servers are multiplexed I/O.


LOL at the forking, I agree it makes the API suck. I don't need to worry about that. The entire MUD is run in Javascript. No forking for ptys required…
25 Jan, 2013, Scandum wrote in the 14th comment:
Votes: 0
MSDP is one way to deal with this, and I wouldn't mind adding a standardized format to the specification.

Diku line editing can be enhanced with the option to jump to specific lines, insert lines, delete lines, word wrap, and do a global replace.
25 Jan, 2013, quixadhal wrote in the 15th comment:
Votes: 0
Unfortunately though, you also can't use curses. Even if there was a javascript binding for it, curses requires you to fork to avoid global state collisions. So, I guess that explains why you have to re-invent the wheel again.
26 Jan, 2013, Telgar wrote in the 16th comment:
Votes: 0
quixadhal said:
Unfortunately though, you also can't use curses. Even if there was a javascript binding for it, curses requires you to fork to avoid global state collisions. So, I guess that explains why you have to re-invent the wheel again.


At one point I looked more deeply at the curses API, and there appears to be a way to handle multiple screens and possibly even multiple screen types without forking. It still involves global state however, you have to manually set and restore the active terminal type, so it precludes any threaded implementation apart from forking.

I also don't need to worry about rendering to dead-dumb clients. Most of the complexity of curses comes from it having to deal with things so ancient that moving to a given X,Y position might require redrawing the entire screen, work around random terminal emulation bugs, emulating fancy scrolling which requires in-memory buffering, etc.. and most of the heavy lifting done by curses is in the form of the termcap data it provides. So I can get away with a really light weight implementation that assumes a couple of minimal features and simply grabs the sequences needed for those features from something like "infocmp -L".

Scandum said:
MSDP is one way to deal with this, and I wouldn't mind adding a standardized format to the specification.

Diku line editing can be enhanced with the option to jump to specific lines, insert lines, delete lines, word wrap, and do a global replace.


How would MSDP help with this? (Mostly missing what the pronoun this refers to after having too many sidebars..)

Those are good suggestions. Also, since this is Javascript, I can trivially add arbitrary regular expression search / replace.
26 Jan, 2013, Ssolvarain wrote in the 17th comment:
Votes: 0
Scandum said:
MSDP is one way to deal with this, and I wouldn't mind adding a standardized format to the specification.

Diku line editing can be enhanced with the option to jump to specific lines, insert lines, delete lines, word wrap, and do a global replace.


Mmhm. Very handing for editing scripts, as well. Might overlook a typo or something in notepad and not want to delete and replace whole blocks of text at a time.
26 Jan, 2013, Ssolvarain wrote in the 18th comment:
Votes: 0
Telgar said:
the obvious choice seems to be this old school Diku system


Still the best, and faster/more flexible than a graphical editor.

It's sort of how veteran mudders use an actual client, while newbies need lots of boxes and brightly colored buttons.
26 Jan, 2013, Scandum wrote in the 19th comment:
Votes: 0
Telgar said:
How would MSDP help with this? (Mostly missing what the pronoun this refers to after having too many sidebars..)

MSDP would primarily help with MUD clients that have stated they won't add VT100 support, like mushclient and mudlet.

The client would indicate that the mud needs to report the EDITOR variable, if the MUD supports this, instead of opening an in-game text editor it would send out an editing request, something resembling:

EDITOR : { "FILENAME" : "bla.txt", "DIRECTORY" : "files\notes\private", TITLE" : "Re: Bla", "RECIPIENT" : "Bubba", "FROM" : "Pamela", "TYPE" : "PRIVATE NOTE", "BODY" : ">I miss you Bubba. XO Pamela\n" }

The client would use this to open an editor, and when the player is done it will send back the EDITOR variable with the adjustments, upon which the MUD would either post it, or keep it in draft form until the player enters the command to post it.
26 Jan, 2013, Rarva.Riendf wrote in the 20th comment:
Votes: 0
Ssolvarain said:
It's sort of how veteran mudders use an actual client, while newbies need lots of boxes and brightly colored buttons.


Veterans use a notepad on the sude then jsut copy paste in their client, a few line at once to not override the mud input limit :)
0.0/45