--- 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