From: agemoagemo@... Date: 2005-09-01T13:11:28+09:00 Subject: Re: Still looking for a Ruby MUD client --- Greg Millam wrote: > > > 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 goblin > here, attacking > you!" > > 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 :D > > * 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) ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs