From: Morgan Date: 2005-09-02T04:18:35+09:00 Subject: Re: Still looking for a Ruby MUD client Sy wrote: >On 8/31/05, agemoagemo@yahoo.com 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 red and blue baseball bat." something.reverse should give: ".tab llabesab eulb dna der A" However, what a normal reverse gives is: ".tab llabesab >C/eulb C< dna >C/der C< A" If we unreverse the tags, we get: ".tab llabesab eulb dna der 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 reb dna dlue 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 red and blue 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