Good catch, thank you.

I'm really tempted to split TelnetClientinto two classes; TelnetLineClientand TelnetCharacterClientand add an argument to TelnetServer to specify which to use. This would make everything a lot less kludgey design-wise. Authors would code for one client or the other, not both. The downside is clients like Tinyfuge that don't support LINEMODE wouldn't work at all with character servers.

I think that is being a little overly strict. "Be strict in what you send, lenient in what you accept" – dealing with misbehaving clients is kind of a fact of life. It's really not that hard to approximate "true" line mode by simply looking for lines in the input you receive, like what many MUD servers currently do. It might make sense to not implement the character mode in the same way as the line mode, but – if I'm not mistaken – almost all of the telnet stuff is the same whether you're in line or character mode. So I would have one layer that does generic telnet stuff, that goes off to another layer that either does character mode, or "line mode" – be it "true" line mode or not.

The problem is you cannot fake character mode. Faking line mode is easy and you could make shallow use of it for things like tab completion, but to really take advantage of character mode you kinda half to cut bait. Plus, it just feels fugly having multiple methods pulling from the same input buffer in conflicting ways – one that requires zero interaction and another that requires very elaborate juggling and immediate feedback to the typist. What did their key do and what should they see on the screen? Wouldn't keypresses be more suited to an event handler?

That's one of the reasons I asked if Stoli imagined himself switching modes on the fly. I wasn't sure what to do with partial input buffers if the coder decides to switch to character mode. I'd probably give them a purge buffer method but that's not giving them a feature because it's useful but because things are disjointed. Even letting the coder know that the LINEMODE dance failed is complicated.

Here's some prior work and observations on various clients:
http://teensymud.kicks-ass.org/wiki/show...
http://cryosphere.net/telnet
http://www.graysage.com/cg/MUD/CGMud/tel...



The ideal mechanism of operation for what I envision is a sort of half linemode/character mode, where line editing and echo are client side, yet all other "special" keys are sent immediately without EOL terminators. (i.e. function keys, arrows, tabs, CTL and ALT sequences). That is just a small issue of the client entering character mode and faking it, allowing a limited set of ASCII characters to be entered first to an input buffer to be editted before being sent.

The irony is that most GUI mud clients get in the way and prevent mud servers from implementing user friendly TUIs…they instead limit muds to CLI interfaces (or some specific mud client plugins or protocol) . OTOH using Telnet standard clients allow muds to implement more complex and user friendly TUIs.

My test for good client is that it can log into a unix/dos shell and run midnight commander and ctetris.

For my purposes, switching ability wouldn't be necessary, since I would like to use character mode stuff like command history and autocomplete throughout the MUD. However, I could see it being useful for someone who wanted to implement something like a character mode editor that switches into character mode when it starts and back to line mode when editing is complete. I'm pretty sure that most current MUD clients today would puke at that kind of telnet negotiation, though. :(

Yeah, I was thinking along these lines, as well. By having players connect with "normal" telnet clients (like PuTTY), I could then present a more consistent interface. Basically, something like a BBS or an old DOS application, as opposed to a continuous scroll of text.

It's not that they'd puke at the negotiation (some would), but rather that they all have their own ideas about command line editing and display, cobbled up because MUD servers have been stuck using line-mode (if even that) for so many years.

Ideally, you want not just character mode, but full termcap/termlib support so you can do exactly what the unix login process does, identify the terminal and setup a full environment, and then use high-level things like curses at will.

Synchronizing and communicating between spawned child processes would be a PITA. And unfortunately curses in its current form is single process and single user.
The idea is to negotiate character mode, terminal and terminal size. Then you use a library that functions similarly to curses, possibly better designed for this task.

I don't think communication would be any more or less difficult than it is now. You would spawn a child process for each connection, but it's no different than threaded I/O of any kind. Lock the buffer when you pull from the socket and dump new data on. Parent locks the buffer when it pulls data off the buffer. The reverse for output. I suppose you could use local sockets instead, but I don't see a reason unless semaphore locking is broken.

Curses… yeah. There is a semi-thread-safe version of curses, but even then it's a bit grumpy. Has anyone made a socket-specific version yet? Seems like it would be useful.

I'm making a couple changes to the ANSI color shortcuts that I wanted anyone using them to be aware of. A user was kind enough to point out a problem with my design – everything was a two-character command except setting background colors which causes a problem if you set a foreground color right before a word that started with a lowercase 'b'.

^r = red foreground.
^rb = red background.

So a string like "The orc ^rblungeons^w you for 50 points" would set white text on a red background.

I'm going to change everything to use two-character codes so background colors will be set by ^[0-6] like so;

( '^0', '\x1b like so;

( '^0', '\x1b[40m' ), # black background
( '^1', '\x1b[41m' ), # red background
( '^2', '\x1b[42m' ), # green background
( '^3', '\x1b[43m' ), # yellow background
( '^4', '\x1b[44m' ), # blue background
( '^5', '\x1b[45m' ), # magenta background
( '^6', '\x1b[46m' ), # cyan background

Bold on and off will be ^! and ^. instead of ^! and ^1.
Underline on and off will be ^U and ^u.
Inverse on and off will be ^I and ^i.
Reset will be ^~
and ^^ will escape a caret.

I apologize if this causes anyone a lot of string editing. I'm still testing but will probably commit the changes today.

I still dislike the one-character colour token system, and would never consider using it on a new game that isn't trying to be compatible with some Dikuism.

Why not just use brackets with words in them? Much easier to read, much easier to expand to other purposes, or make generic so users can choose their own output formats.

This [red]red text[reset] is [damage]painful[reset], but you can expand it with more words in , but you can expand it with more words in [[brackets].
If you want backgrounds, how about [bg:red]?

But, that's just my 2 cents. :)

I like them as short as possible. It breaks up the text less and I don't have to split up code lines that exceed 79 columns as often – another personal preference. The usage is entirely optional and the default send() method of the Telnet class doesn't process them, making it pretty simple for a Miniboa user to code their own.

I support both. But the one-character tokens are so much easier and faster to parse that I almost always use them instead of the word tokens (string parsing is one of the biggest bottlenecks in my mud, because I make such extensive use of dynamic descriptions). I also find the one-character tokens more readable, particularly in text containing a lot of colour, simply because they're more concise.