Still looking for a Ruby MUD client

[James Edward Gray II]

I've been screwing around...
http://sourcery.dyndns.org/teensymud/index.html

and

Have a look at my mud,

http://rubymud.reyn.co.za/
http://rubymud.reyn.co.za/images/stories/twopiOG.png for the class
diagrams.

Though I'v learned quick alot since starting it.

These are both neat projects. Thank you both for sharing!

James Edward Gray II

 

[David Vallner]

require 'socket';require 'yaml';def q x;$m.find{|o|o.t==&&x==o.n};end
def a r,t;$m.find_all{|o|t==o.t&&(!r||r==o.l)};end;def g
z;a(nil,).each{|p|
p.p z};end;class O;attr_accessor :i,:n,:l,:e,:s,:t;def initialize
n,l=nil,t=:r
@n,@l,@i,@t=n,l,$d+=1,t;@e={};end;def p s;@s.puts(s)if @s;end;def y m
v=$m.find{|o|@l==o.i};t=v.e.keys;case m;when/^q/;@s.close;@s=nil;
File.open('d','w'){|f|YAML::dump $m,f};when/^h/;p
"i,l,d,g,c,h,q,<exit>,O,R"
when/^i/;a(@i,).each{|o|p o.n};when/^c.* (.*)/;g "#{@n}:#{$1}"
when/^g/;a(@l,).each{|q|q.l=@i};when/^d/;a(@i,).each{|q|q.l=@l}
when/^O (.*)/;$m<<O.new($1,@l,);when/^R (.*) (.*) (.*)/;$m<<d=O.new($1)
v.e[$2]=d.i;d.e[$3]=v.i;when/^l/;p v.n;(a(@l,)+a(@l,)).each{|x|
p x.n if x.s||x.t=};p t.join '|';when/(^#{t.empty? ? "\1" :
t.join('|^')})/
@l=v.e[$1];else;p "?";end;end;end;test
?e,'d'||begin;$d=0;$m=[O.new("Home")]
end;$m=YAML::load_file 'd';$d=$m.size;z=TCPServer.new 0,4000;while
k=z.accept
Thread.new(k){|s|s.puts "Name";s.gets;l=$_.chomp;d=q
l;$m<<d=O.new(l,1,)if !d
d.s=s;while s.gets;d.y $_.chomp;end;};end

My brain just melted and started dripping out of my ears. Now I have to
go get a tissue and clean up all that mess - I hope you're happy and
proud of yourself...

 

[Dave Burt]

If we can write a Ruby MUD in 15 lines, surely we can do the same for a
scriptable client, eh? It's really not a hard challenge to cook one up.
I can't believe we haven't talked you into it yet...

Sounds like a great Ruby Quiz idea to me. Then we'd have half a dozen Ruby
MUD clients with enough creative ideas for a MUD client to rule them all.

Cheers,
Dave

 

[James Edward Gray II]

Sounds like a great Ruby Quiz idea to me. Then we'd have half a
dozen Ruby
MUD clients with enough creative ideas for a MUD client to rule
them all.

You talked me into it. We'll try it out this Friday.

James Edward Gray II

 

[Matt Lawrence]

Sounds like a great Ruby Quiz idea to me. Then we'd have half a dozen Ruby
MUD clients with enough creative ideas for a MUD client to rule them all.

Great. MUD wrestling and MUD slinging on the Ruby list.

-- Matt
Nothing great was ever accomplished without _passion_

 

[Sy]

On Aug 30, 2005, at 7:47 AM, Sy wrote:
=20
=20
If we can write a Ruby MUD in 15 lines, surely we can do the same for
a scriptable client, eh? It's really not a hard challenge to cook
one up. I can't believe we haven't talked you into it yet...

I wouldn't presume to consider my newbie self able to do what others
appear to have taken years to do. Also, considering I'm not satisfied
with what I've used so far I think I'd tie myself up in knots with the
attempt. =3D)

=20
You talked me into it. We'll try it out this Friday.

Gah! =3D)

Btw, as an aside.. vwmc doesn't use the telnet library by choice..


Oh, and my dumbass server setup is up again. I had to use a dark
force point to make it work.:
http://jrandomhacker.info/mw/index.php/Vwmc

 

[James Edward Gray II]

I wouldn't presume to consider my newbie self able to do what others
appear to have taken years to do. Also, considering I'm not satisfied
with what I've used so far I think I'd tie myself up in knots with the
attempt. =)

No, what that means is that it's the one sure way to get what you
want.

I say give the quiz a try next week. You might surprise yourself.

James Edward Gray II

 

[Sy]

No, what that means is that it's the one sure way to get what you
want.
=20
I say give the quiz a try next week. You might surprise yourself.

I'm more afraid of shocking and appauling myself.

I'll consider it.. but some other stuff is making me itchy right now..

 

[dave.burt]

I'm more afraid of shocking and appauling myself.

You can do it! And even if you can't, someone can help you, and you'll
have learnt something along the way.

Even if you're not going in for the upcoming Ruby Quiz, please submit a
feature list. What is inadequate about VWMC and other existing clients?

Cheers,
Dave

 

[Sy]

=20
You can do it! And even if you can't, someone can help you, and you'll
have learnt something along the way.
=20
Even if you're not going in for the upcoming Ruby Quiz, please submit a
feature list. What is inadequate about VWMC and other existing clients?

I haven't the time to embark upon such a thing, which is why I wanted
to use a Ruby client to get into gameplay scripting stuff to further
spur me on.

I'll write some notes on this regardless.. it'll help refine my needs
so I can contribute more effectively to vwmc.

http://jrandomhacker.info/mw/index.php/Ruby_Telnet_Client

Perhaps what I could do is to try out everyone's entry and do a little
writeup on my experiences. Does anyone do this sort of thing for
these quizes?

 

[Dave Burt]

Perhaps what I could do is to try out everyone's entry and do a little
writeup on my experiences. Does anyone do this sort of thing for
these quizes?

Yes.

1) The Quiz is posted on Friday.
2) Solutions are allowed to be submitted from 24 hours after the quiz is
published.
3) Somebody inspects the entries and produces a "summary" before Friday,
looking at one or more approaches to the problem, usually highlighting
interesting implementation details.

See http://www.rubyquiz.com for FAQ.

See http://www.rubyquiz.com/quiz40.html for an example summary.

James would undoubtedly appreciate your writing the week's summary.

Cheers,
Dave

 

[James Edward Gray II]

Yes.

1) The Quiz is posted on Friday.
2) Solutions are allowed to be submitted from 24 hours after the
quiz is
published.

One minor correction. 24 should be 48.

3) Somebody inspects the entries and produces a "summary" before
Friday,
looking at one or more approaches to the problem, usually highlighting
interesting implementation details.

See http://www.rubyquiz.com for FAQ.

See http://www.rubyquiz.com/quiz40.html for an example summary.

James would undoubtedly appreciate your writing the week's summary.

Always! Be sure and let me know if you intend to do this.

James Edward Gray II

 

[Guest]

Btw, as an aside.. vwmc doesn't use the telnet
library by choice..

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.

-Morgan


=09
____________________________________________________
Start your day with Yahoo! - make it your home page=20
http://www.yahoo.com/r/hs=20
=20

 

[Sy]

=20
The main reason that I, at least, am using net/telnet
is to let it's preprocessing function handle telnet
control codes.
=20
Most of the rest isn't usable, due to the various ways
that (in my understanding) MUD output breaks the
telnet spec.

Does this mean that a "mud-telnet library" ought to be made, to help
various other clients with these intricacies?

I already see various distinctions:
* The GUI
* The console app
* The mud-scripting engine
* the underlying mud-telnet library

The scripting engine and telnet library ought to be external to one's
mud client project.. just adopted as modules. Even the GUI should be
an abstraction above a more generic console app.

 

[Greg Millam]

The main reason that I, at least, am using net/telnet
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
.

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

* 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

 

[Guest]

=20
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=20
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=20
"Okay, give me *everything* that I could read from the

socket right now." Or even just a way to check how
much=20
is waiting on the socket... Pretty much everything
I've
ever tried to do with sockets would be easeir with
that.)

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.
=20
If we do employ such a thing, we might want to make
it support multiple
connection types (i.e: MUDSocket::MXP?)
=20
* 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=20
color parsing and such from the GUI, since different=20
GUIs are likely to require vastly different ways of=20
implementing them. (Fox, for instance, looks like it's

going to be a real pain to do it in. And I'm not sure=20
implementing some of the MXP tags would even be=20
possible.)

(Admittedly, I also don't particularly *like* MXP, so=20
I'm not thinking too hard about it. IMO if the MUD=20
doesn't like the possiblity of someone having their=20
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=20
sort of "universal" set of codes for describing colors

and such, convert all the MU* output types to that,=20
then pass it to the GUI which handles it as necessary.

I don't quite see the seperation between GUI and=20
console app. To me, running in an ordinary prompt=20
window or something is just another GUI (albeit one=20
with some rather strict limitations).

For the rest, I'm kind of trying to keep things=20
distinct when I can, but I'll probably place getting=20
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.

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

I'm starting to wonder what either of you means when=20
you say "scripting engine".

I read that as "the code that handles client-side
aliases, triggers, etc."

=20
Whatever the client library, the protocol
(mxp/pueblo/ansi/etc) should
be a separate library for general use, yes.
=20
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.
=20
That is, say you have: "You see a <red>goblin</red>
here, attacking
<yellow>you!</yellow>"
=20
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=20
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,=20
that wouldn't help with substitution. But hey, that's=20
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?
=20
* Telnet MUDServer socket library that deals with
height/width/etc. MXP
and Pueblo are neat, but I never use 'em

* Telnet MUDClient socket for the same purposes.
=20

Do any MUDs really use that height/width stuff? At=20
least on the one I spend my time on, height is=20
something that if you care about it, you use a command

to say how many lines you want, and if your terminal=20
isn't wide enough for the lines it sends, that's your=20
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=20
MUDs as well, if you could configure it to handle=20
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)



=09
____________________________________________________
Start your day with Yahoo! - make it your home page=20
http://www.yahoo.com/r/hs=20
=20

 

[Dave Burt]

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

socket.read will do that.

Socket < BasicSocket < IPSocket < IO

IO has lots of other indispensable methods when dealing with sockets.

Cheers,
Dave

 

[Sy]

=20
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.)
=20
(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...)
=20
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.

=20
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).
=20
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).=20
Frankly, I never really got to like mice anyways..

I'm starting to wonder what either of you means when
you say "scripting engine".
=20
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. =3D/

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

 

[Morgan]

socket.read will do that.

Socket < BasicSocket < IPSocket < IO

Are you sure about this?

I just did a little code in a couple irb windows to test this. socket.read
called with an argument doesn't seem to return until it gets as many
characters as the argument specified. And without an argument, it
doesn't seem to return... ever. (Or at least, not until I tell my server to
close the socket. Which kind of defeats the purpose.)

Now, socket.recv, that's a method I've managed to make some use of,
since it'll come back with what it has if I call it with a number larger than
the amount of data available. There are still times when "get everything"
would be nice though, and that doesn't supply it.

-Morgan

 

[Morgan]

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.

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

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

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.


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