Re: Still looking for a Ruby MUD client

Sy wrote:

>On 8/31/05, [e-mail] <[e-mail]> wrote:
> > 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?

Not necessarily a new one, but for an arrangement like this to
work there has to be a consistent way for information to pass
through the system.

MXP is probably versatile enough to do the job, but as mentioned
before, I don't like it. ;) In particular, I'm not happy about something
using a delimiter character that can appear in normal MUD output.
I ran into issues before on a certain MUSH where the way certain
things were normally output got interpreted as MXP commands,
and would just disappear.

It should also be noted that a system for internal communication
within the client doesn't *have* to be something that could easily
be transmitted over a socket. It just has to work consistently and
do the job.


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

Well, I don't know about "nightmare", but there are some distinct
differences.

Looking at vwmc, for instance, adding a line of relatively normal
colored text (no blink or underline) uses this command:

self.outputBuffer.insert(self.iter,ci[:text],"deffont",fg,bg)

where fg and bg are values representing the text and background
colors respectively. (I'm not sure what the self.iter is for, but that
doesn't appear to be important - it looks like something that's
totally internal to the gui.)

Whereas to do something similar in Fox's FXText widget, I set
up a FXHiliteStyle object (conceptually similar to the structure
vwmc defines in parseansi.rb, though not containing the text) for
each color combination I'll be using, put them in an array, give
that to the FXText object, then use something like

thisFXText.appendStyledText(text, indexInTheStyleArraySortOf)

I don't believe this means I have to make an array of all possible
styles before I start doing anything. (Though it might be easier to
do it that way anyway... take about 64k of memory I think.) Still,
it's a distinctly different sort of process from what's being used in
the GTK program.

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

Hmmm. Currently, my code is littered with the remnants of things
I've tried and had them not work. ^_^;; Once I find something that does,
I'll sift through it and clean things out.

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

Extra windows to capture certain information and certain ways of
viewing scrollback are my main issues. Also, configuration is
generally much easier.

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

To at least partly help with this, I've been thinking about a way to support
at least a significant subset of tintin commands. (Which seems to be what
most of zmud's script language is.) The system translates those commands
into ruby code, to speed up execution.

(Not that I've written that part, mind you. But I think I know how to do it.)

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

I'm not quite sure why you'd want to do that, let alone how. `.`;

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

Personally, I find aardwolf's scroll setting to be useful sometimes,
but of course that's something that people can disable if they don't
want.

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

My experience with OLC suggests that the designers disagree with
you. `.`

> > 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.  =/

Apparently the person who originally came up with it disappeared
or something. <.< It seems to work quite well in the version
available now though, and since there's a zlib library for ruby
it ought to be possible.


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

Thinking about it more, how difficult this would be depends
on what things you want to work across tags.

Say, something like this. (MXP, even though I don't like it.)

something = "A <C red>red</C> and <C blue>blue</C> baseball bat."

something.reverse should give:
".tab llabesab <C blue>eulb</C> dna <C red>der</C> A"

However, what a normal reverse gives is:
".tab llabesab >C/<eulb>eulb C< dna >C/<der>der C< A"

If we unreverse the tags, we get:
".tab llabesab </C>eulb<C blue> dna </C>der<C red> A"

Still not quite right. Switch each pair of tags, and then you've got it.

But let's suppose you only wanted to reverse part of it. Well, you're
in trouble now...

something.somehow_reverse_just_the_part_thats_like("d and b") =>
"A <C red>re</C><C blue>b</C> dna <C red>d</C><C blue>lue</C> baseball bat."

In conclusion, you're in trouble now.

Of course, to do this you need a way of pattern matching across tags. Well,
that might actually be relatively simple...

Okay, let's try it on some ANSI.

For the moment, we'll pretend that + represents the escape character,
since I'm too lazy to write it out properly for this.

something = "A +[31mred+[39m and +[34mblue+[39m baseball bat."

This would actually work about like the MXP example...

So let's do something that doesn't.

something = "A +[31mred, +[32mgreen, +[39m and +[34mblue +[39mbaseball bat."

something.reverse should give us:
".tab llabesab+[34m eulb+[39m dna+[32m neerg+[31m der+[39m A"

And what does reversing just part of it look like?

It looks like Morgan fleeing in terror, that's what.

Now, I still don't know why you'd want to reverse anything. So, let's come
up with some ludicrous example for gsub, which was also mentioned.

something = "A <C red>red</C> and <C blue>blue</C> baseball bat."

something.gsub("red and blue", "ostrich") should give us something like...
"A ostritch baseball bat."

... But which parts are red and which parts are blue?

In conclusion, you're in big trouble.

Okay. The thing making this difficult is handling things that span across
tags. Running a gsub that matches something entirely within a single
tag won't produce problems, nor will reversing it, nor will anything else
you do to it that I can think of. Matching a pattern across tags I'm
pretty sure can be done, but it'll probably be a pain to do, and I'm starting
to wonder if there's any point to it. Substitution across tags is probably
doable if you can solve the pattern matching problem, but how do you
decide sensibly what ends up in what tag?

In conclusion,...

-Morgan.sendToWorld("flee\nflee\nflee\nflee\nflee\n")




-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.17/85 - Release Date: 08/30/2005