On 8/31/05, agemoagemo / yahoo.com <agemoagemo / yahoo.com> wrote:

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

You're describing the beginnings of a new telnet/mudding protocol?

I didn't realise it could be such a nightmare for the different gui
toolkits to deal with things.





> > > 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. ^_^;;

Yeah, making it work should always be a priority, but sometimes one
can plan just a little to make life easier for the eventual rewrite.

I too don't really separate the console and the GUI.. but once you
start thinking about things like sending certain output to certain
separate buffers it gets wierd.  I personally don't see anything
special about a GUI app at *all* until you start talking about
interaction with the mouse (or graphics, and maybe not even then). 
Frankly, I never really got to like mice anyways..



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

That's exactly what I mean by it.

The user would care about two things:

* The UI
* The scripting they'd have to learn

The UI can be separate from mud client to client.  The scripting
engine should be *the exact same* to reduce the overhead of porting
scripts, learning new skills etc.

It may not be "that hard" for simple scripts, but more complex scripts
that do wierd things like yank out a previous command from the command
history aren't exactly portable concepts.


> Do any MUDs really use that height/width stuff?

I personally feel that height and width should be irrelevant to the
server itself.  It should just throw streams of information and the
client should handle pauses and line breaks.  It's not that hard.

World-builders should, of course, still worry about certain standards,
which is a rant I won't get into here.. but long descriptions should
never be hand-wrapped.  That's just stupid.


> A library to handle MCCP would be a nice thing.

I agree.  Looking at the mccp stuff, it looks like it hasn't been
developed much in some years.  =/



> > * A library for strings w/ markup, and manipulating
> 
> 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.

I was also thinking this.  I would have thought that a few
semi-functional methods would already exist by now.

The first thing that leaps to mind is the wierdness which a wiki
engine does to work between wikicode, sometimes XML inbetween (see
coWiki) and eventual HTML output.

I've no idea if those thoughts are related to this problem though.