Re: Still looking for a Ruby MUD client

At 05:33 PM 09/01/2005, you wrote:

>This is getting to be a long conversation that's diverging from Ruby and
>onto more generic mud-related topics. But anyway:

*shrug* I'm not sure. I know I'm still looking at all of this with the intent
of learning things to help me write the client I'm working on. And since
it's in Ruby... `.`

>Whoops, I seem to have caused some confusion in my last reply. There's
>two things I had in mind here while writing that:
>
>1) I verged off a bit and discussed both client and server bits.
>(i.e: MXP, and having MXP deal with markup - and this includes color,
>html-like clickable links, even urls to sound files, etc.)

Yeah. Personally, I'm a little too old-fashioned for that stuff (despite
not being that old). Colored text is about fancy enough for mud output
for me.

(Now, since we're already getting sidetracked... ^_- )
(For reference puproses, pretty much the only MU* I've found that I'm
willing to spend time on is Aardwolf, so most of my experience will
relate to it.)

>2) I'm from a PennMUSH background. I used to be big on Smaug, Rom and
>other Diku-Derivatives up until I discovered Penn. Now I won't go back.
>:D. (Can you play scrabble, all forms of poker, boggle, chess, bridge,
>and many, many more games on a Diku? How about writing 'softcode'
>on-game to make almost anything imaginable?)

Would I *want* to play those things on the MU* is what I'd ask. `.`
Most times I'd rather use other specialized programs for those things.
(Also why I don't have much interest in social MUSHes - I consider
IRC more suitable for socializing.)

>MUSHes (PennMUSH, TinyMUSH, and Muxes) are not only entirely created
>online, but also entirely scripted online. They provide a very powerful
>scripting engine to its users that fairly resembles what you'd get if
>you had lisp with string interpolation and function(...) rather than
>(function,...) The "programming" available on Diku derivatives is like
>using old Apple ][e BASIC for making websites in comparison.)

I've actually tried doing some mush coding. It's pretty powerful, but
it didn't seem possible to do the things I wanted to without horrifying
monstrous long constructions with a few dozen brackets here and
there. I could have made what I wanted easier in mIRC script...

Not being familiar with Diku olc, I don't really know what it's like. (I'm
under the impression that Aardwolf's is fairly different. Not surprising
given that it's three generations descended from Diku...)

>On protocols:
>
>This is important to both the server and the client. Many users or
>clients would enjoy an ability to have certain lines of input flagged as
>for a certain purpose. For you mudders, this may be "shout"s or "OOC" or
>other channels. For MUSHers, we have explicit channels that begin with
><channelname>

Aardwolf's mostly look like
<playername> <channelname>: <message>

A few are more complicated, but mostly that's it.

>Now suppose your client wanted to filter shouts into a separate window
>so you can follow a global conversation while you're hacking a hundred
>monsters to bits. It would miss multi-line shouts:
>
>Joe the Slayer shouts, "This is a
>shout with more
>than one line!"

Do many MUs send them as actual multiple lines? On Aard, it appears
that most such things are sent as single long lines, to be wrapped at the
clients discretion. (Which is distinctly different from the way room
descriptions are done; I believe hardwrapping those is pretty much obligatory.)

(I think the only thing I've seen on a channel that uses hard-wrapping is
that imm-only curse-only social with the ascii art of the raised middle
fingers...)

>Your shout window would catch: 'Joe the slayer shouts, "This is a'
>
>Not too fun. Having some form of protocol *available* to (but not forced
>upon) the user is a Good Idea (tm). i.e:
>
><Chat: Shout>Joe the slayer shouts, "This is a
>shout with more
>than one line!"</Chat>

Maybe a nice idea, but probably something that needs to be taken up
on MU* design MLs before here. No point in writing a client to implement
it before there's someone who'll write a server to use it.

>On text manipulation:
>
>MUSHes provide ways for world-builders to customize the description of
>all the rooms at the same time. You can write "who" listings, combat
>systems, and more - all through string manipulation. String manip in
>'mushcode' is considerably easier to deal with than Ruby.
>
>For example, a common 'room parent' would be:
>
>@descformat room parent=[repeat(-,10)]r[wrap(%0,10)]%r[repeat(-,10)]

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

I'm not sure I could figure out what that did... ever, if I didn't already 
know.

>[snip]
>Terminal settings, or: "Why we should send width and height"

I was really more asking "Does anyone want us to", but this answers
that too...

>As for the terminal sending its width/height: users can access each
>other's terminal sizes by using width(<user>) and height(<user>). Plug
>that in to the above @descformat and use:
>
>repeat(-,sub(width(%#),2))%r[wrap(%0,sub(width(%#),2))]%r[repeat(-,sub(width(%#),2))]
>
>And all your rooms will have their descriptions cleverly hard-wrapped to the
>user's terminal size.

Hmmm. And that's done with standard telnet control codes, I believe?
Difficult to do with the current telnet implimentation. I don't believe there's
any way to tell it to respond to additional telnet commands other than the
ones that are built in.

What, I wonder, would something coded the way you describe do if the
client is unwilling or unable to provide that information?

And what happens if the size of their terminal changes?

-Morgan, fails saving throw to resist making a comment about how she
isn't sure she wants people to be able to see her sizes so easily... 


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