< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous (in thread)
N :the next (in thread)
|<:the top of this thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
> > The main reason that I, at least, am using net/telnet
> > is to let it's preprocessing function handle telnet
> > control codes.
> >
> > Most of the rest isn't usable, due to the various ways
> > that (in my understanding) MUD output breaks the
> > telnet spec.
Very little is used in most muds. Some will use TelnetGA (those with
proper prompts, for example). Most will use terminal height/width, but
not much else.
> Does this mean that a "mud-telnet library" ought to be made, to help
> various other clients with these intricacies?
A MUDServer / MUDSocket, perhaps? That strictly provides network interfaces.
If we do employ such a thing, we might want to make it support multiple
connection types (i.e: MUDSocket::MXP?)
* MXP: Developed by zmud, supported by a few clients, fairly useful.
* Pueblo: The protocol that's so bad, it makes MXP look good.
* Straight-up ANSI/Telnet: using ANSI escapes for colors, etc.
> I already see various distinctions:
> * The GUI
> * The console app
> * The mud-scripting engine
> * the underlying mud-telnet library
This is a mix of tying together a mud engine and client. How closely
tied together they are varies from game to game.
> The scripting engine and telnet library ought to be external to one's
> mud client project.. just adopted as modules.
Should they even be included in the client? I know it's becoming popular
for more work to be done client side, but this still makes me feel iffy
:D.
> Even the GUI should be an abstraction above a more generic console
> app.
Whatever the client library, the protocol (mxp/pueblo/ansi/etc) should
be a separate library for general use, yes.
The single biggest problem I have in dealing with any mud server I've
written (and that's several: but all just 'toy' quality) is string
markup.
That is, say you have: "You see a <red>goblin</red> here, attacking
<yellow>you!</yellow>"
Practically any operation on the string (gsub, reverse, etc) would
thoroughly ruin the markup, regardless of protocol. (Ever seen an ansi
escape sequence in reverse?)
So what do I think we could do, as a community that would greatly ease
development of a mu* by anyone?
* Telnet MUDServer socket library that deals with height/width/etc. MXP
and Pueblo are neat, but I never use 'em :D
* Telnet MUDClient socket for the same purposes.
* A library for strings w/ markup, and manipulating them.
My two gold pieces.
- Greg
aka Walker @ M*U*S*H