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... 
James Edward Gray II
On Aug 30, 2005, at 7:47 AM, Sy wrote:
I look for months for a ruby mud client or at least something that can
script in it and I come up dry..
Sy wrote:
I look for months for a ruby mud client or at least something that can
script in it and I come up dry.. a side-comment on mud engines
themselves generates huge interest. =)
Well a ruby mud client might be 2 or 3 lines of code considering there's a somewhat useful Telnet class already in the standard library.
--
J Lambert
James wrote:
On Aug 30, 2005, at 7:47 AM, Sy wrote:
I look for months for a ruby mud client or at least something that can
script in it and I come up dry..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
> I look for months for a ruby mud client or at least something that can
> script in it and I come up dry..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. =)
> 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.
Gah! =)
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.:
On 8/30/05, James Edward Gray II <james@grayproductions.net> wrote:
On Aug 30, 2005, at 7:47 AM, Sy wrote:
You talked me into it. We'll try it out this Friday.
James Edward Gray II
On Aug 30, 2005, at 8:56 AM, Dave Burt wrote:
James wrote:
On Aug 30, 2005, at 7:47 AM, Sy wrote:
I look for months for a ruby mud client or at least something that can
script in it and I come up dry..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.
Great. MUD wrestling and MUD slinging on the Ruby list.
-- Matt
Nothing great was ever accomplished without _passion_
On Tue, 30 Aug 2005, Dave Burt wrote:
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.
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
On Aug 30, 2005, at 10:12 AM, Sy wrote:
On 8/30/05, James Edward Gray II <james@grayproductions.net> wrote:
On Aug 30, 2005, at 7:47 AM, Sy wrote:
I look for months for a ruby mud client or at least something that can
script in it and I come up dry..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. =)
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
--- Sy <sy1234@gmail.com> wrote:
Btw, as an aside.. vwmc doesn't use the telnet
library by choice..
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
I'm more afraid of shocking and appauling myself.
I'll consider it.. but some other stuff is making me itchy right now..
On 8/30/05, James Edward Gray II <james@grayproductions.net> wrote:
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.
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.
On 8/31/05, agemoagemo@yahoo.com <agemoagemo@yahoo.com> wrote:
--- Sy <sy1234@gmail.com> wrote:
> 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.
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
> 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.
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
:D.
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
I'm not a MUDder, but I'm working on a project that probably already does a lot of what you want. It's called 'silkscreen' -- here's its minimalist web page:
http://silkscreen.sourceforge.net/
In a word, it's designed to be an uber-scriptable text mode environment, where you can run different sorts of applications in nonoverlapping windows. The first such application is a terminal emulator like GNU screen, so that you can run a shell.
And once you're running a shell, you could telnet to a MUD server.
I haven't actually written any scripts in silkscreen yet, but it wouldn't be much work to support an interface like:
TerminalWindow.add_line_callback { |window, line|
if line =~ /you are hungry/
window.insert_keypress("eat\n")
end
}
If you're interested, download silkscreen and give it a try. Let me know what you think.
I'm working on silkscreen all the time -- right now I'm working on scrollback support.
Josh
On Aug 31, 2005, at 1:30 PM, Sy wrote:
On 8/31/05, agemoagemo@yahoo.com <agemoagemo@yahoo.com> wrote:
--- Sy <sy1234@gmail.com> wrote:
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.Does this mean that a "mud-telnet library" ought to be made, to help
various other clients with these intricacies?
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.
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?
On 8/30/05, dave.burt@gmail.com <dave.burt@gmail.com> wrote:
> 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?
> > 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* 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)
--- Greg Millam <ruby-talk@lethalcode.net> wrote:
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Wait a second.. does this mean that I could also have a shell and have
MUD-style scripting functionality with *any* pure-text console
application from bash to .. anything?
that's.. huge..
whoa
On 9/4/05, Joshua Haberman <joshua@reverberate.org> wrote:
http://silkscreen.sourceforge.net/
In a word, it's designed to be an uber-scriptable text mode
environment, where you can run different sorts of applications in
nonoverlapping windows. The first such application is a terminal
emulator like GNU screen, so that you can run a shell.And once you're running a shell, you could telnet to a MUD server.
Sy wrote:
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 Ruby Quiz - Drawing Trees (#40) for an example summary.
James would undoubtedly appreciate your writing the week's summary.
Cheers,
Dave
agemoagemo@yahoo.com wrote:
(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
> * 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 libraryI 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.
On 8/31/05, agemoagemo@yahoo.com <agemoagemo@yahoo.com> wrote:
In essence, yes. And your scripts could do things like open other terminals and send keystrokes to them. Or add color to data as it goes by (like compiler output).
There are a couple caveats. It could be hard to set up the triggers you want, because your terminal doesn't necessarily know what a "line" of input is. We can look for a "\n" in the input, but that might not always work. Consider an IRC client that has an area when you edit your text. When you hit "ENTER," the client will send your text to the channel and clear the text area, but might never send a "\n" to the terminal. But you might be able to build some kind of heuristic that looks for outgoing "ENTER" keypresses.
Josh
On Sep 3, 2005, at 6:01 PM, Sy Ali wrote:
On 9/4/05, Joshua Haberman <joshua@reverberate.org> wrote:
http://silkscreen.sourceforge.net/
In a word, it's designed to be an uber-scriptable text mode
environment, where you can run different sorts of applications in
nonoverlapping windows. The first such application is a terminal
emulator like GNU screen, so that you can run a shell.And once you're running a shell, you could telnet to a MUD server.
Wait a second.. does this mean that I could also have a shell and have
MUD-style scripting functionality with *any* pure-text console
application from bash to .. anything?