< :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
--- Greg Millam <ruby-talk / lethalcode.net> wrote:
> > > 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.
Still, if you don't do something to filter them out
they'll just get stuck on the screen. What that would
look like, I have no idea. And I'm hoping it doesn't
add enough overhead to cause a problem. (If it does,
any sort of trigger arrangement is probbaly doomed...)
The main issues I've run into causing problems between
MUD and straight telnet are the lack of prompts after
most output, and the prompts that don't have a newline
at the end.
(I wish I could find a function that would be like
"Okay, give me *everything* that I could read from the
socket right now." Or even just a way to check how
much
is waiting on the socket... Pretty much everything
I've
ever tried to do with sockets would be easeir with
that.)
> > Does this mean that a "mud-telnet library" ought
> to be made, to help
> > various other clients with these intricacies?
It's probably a good idea, but I don't think I'm going
to be the one to do it. ^_^;
> 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.
A nice idea, but it seems to be difficult to seperate
color parsing and such from the GUI, since different
GUIs are likely to require vastly different ways of
implementing them. (Fox, for instance, looks like it's
going to be a real pain to do it in. And I'm not sure
implementing some of the MXP tags would even be
possible.)
(Admittedly, I also don't particularly *like* MXP, so
I'm not thinking too hard about it. IMO if the MUD
doesn't like the possiblity of someone having their
client alter some of the MUD output, the MUD shouldn't
be sending it to them...)
The only way around this I see would be to make some
sort of "universal" set of codes for describing colors
and such, convert all the MU* output types to that,
then pass it to the GUI which handles it as necessary.
> > I already see various distinctions:
> > * The GUI
> > * The console app
> > * The mud-scripting engine
> > * the underlying mud-telnet library
I don't quite see the seperation between GUI and
console app. To me, running in an ordinary prompt
window or something is just another GUI (albeit one
with some rather strict limitations).
For the rest, I'm kind of trying to keep things
distinct when I can, but I'll probably place getting
the thing working at a higher priority. ^_^;;
> 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.
I'm starting to wonder what either of you means when
you say "scripting engine".
I read that as "the code that handles client-side
aliases, triggers, etc."
> > 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?)
I suppose my first question would be "... And why
would
you want to reverse it again?" `.`
The simplest and most ludicrous idea I can think of is
to make all your markup tags palindromes. ...Of
course,
that wouldn't help with substitution. But hey, that's
why it's called a stupid idea.
> 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.
>
Do any MUDs really use that height/width stuff? At
least on the one I spend my time on, height is
something that if you care about it, you use a command
to say how many lines you want, and if your terminal
isn't wide enough for the lines it sends, that's your
problem.
A library to handle MCCP would be a nice thing.
> * A library for strings w/ markup, and manipulating
> them.
This could probably be useful for things other than
MUDs as well, if you could configure it to handle
multiple types of markup. (Which I'd guess you could.)
The question is, how do you do it? I can think of a
few
ways, but nothing I can't think of a way to break too.
-Morgan. (Taria@Aardwolf)
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs