11 Feb, 2009, David Haley wrote in the 42nd comment:
Hades_Kane said:
That's akin to asking why make closed doors not show up in the auto-exits… to make players have to go 'udnesw' in every room they enter? Or why have jump/crawl/climb exits… to make players have to attempt to jump/crawl/climb every exit? Or why have hidden exits… or why have some commands only work within specific contexts (like 'push button' or 'pull lever').
Why would you have anything that requires a little bit of description reading when they could just cycle through a massive list of commands in every room they enter?
Why would you have anything that requires a little bit of description reading when they could just cycle through a massive list of commands in every room they enter?
I think these are very different examples…! Presumably the descriptions tell you about doors, and other exits. If the exits are totally hidden with no indications of their presence at all anywhere, well, yes, I think that's pointless and only encourages mindless behavior. A hidden exit that is alluded to somewhere else entirely is very different from a hidden exit that is only revealed by poking at it. The latter encourages poking everything everywhere, which is tedious.
What you're suggesting though is entirely different. You're talking about sending text that the person highlights to read. What is your use case? Are you going to send hints that only become visible if you highlight the MUD output with your cursor? If you step back to any form of immersion whatsoever, this is a completely OOC hint with no story-world justification whatsoever. That is not necessarily a sufficient argument on its own, but it is a serious problem IMO.
If you are talking about giving hints about where "hidden text" is, why can't you give a hint to do something like "look under the rug" in some room? What is the point of some terminal color trickery when you already can integrate "hidden text" using existing features? If you aren't talking about giving hints about where to look for hidden text, I think that puts us back into the square of encouraging people to go highlight everything everywhere, or just mess with their terminal settings to fix the color.
11 Feb, 2009, quixadhal wrote in the 43rd comment:
I do like that idea, of auto downgrading the 8-bit colours into standard ANSI 16 support. :)
11 Feb, 2009, Hades_Kane wrote in the 44th comment:
Sandi said:
Well, once it's plugged into ROM. it really doesn't stand out as "bad" code. :)
I think what's broken is the concept. Or, really the name, "colour code". It's an output parser, and I keep repeating that in the hopes of getting people to do more with it. For instance, we have a Stock Market. Those are supposed to have a Big Board where you can see all the current prices. With 'color codes' that return prices rather than ansi escapes, you can do that with 'look' rather than a separate command. The benefit is the world seems more "real". In a similar vein, you ought to be able to eat pills and drink potions. Not hard to do, less confusing to newbies, and it has the added benefit that your food can have applies.
Hades_Kane said:
Maybe this thread has just gone over my head… but what's so broken about Lope's color code that makes it need fixing or needs a new, "better" system to replace it?
Well, once it's plugged into ROM. it really doesn't stand out as "bad" code. :)
I think what's broken is the concept. Or, really the name, "colour code". It's an output parser, and I keep repeating that in the hopes of getting people to do more with it. For instance, we have a Stock Market. Those are supposed to have a Big Board where you can see all the current prices. With 'color codes' that return prices rather than ansi escapes, you can do that with 'look' rather than a separate command. The benefit is the world seems more "real". In a similar vein, you ought to be able to eat pills and drink potions. Not hard to do, less confusing to newbies, and it has the added benefit that your food can have applies.
Ok, so calling it "colour" is bad, and what now? I guess it might still be going over my head… if I want to make text red, I guess I just don't see the issue with typing {R before a word to make it do that, and typing {x to clear it (or some other color code to return back to the default color code for that string).
Scandum said:
It doesn't support background colors, underline, black, blink, reverse video, bold background colors, or xterm 256.
The extended color codes isn't that hard to put in, which then easily converts it to support background colors, underlines, blink among some other things… I'm not even quite sure why I bothered patching those in, because I disabled them on pretty much all channels, titles, emotes, etc. Those things seem to be more annoying than actually having any real use, so I guess I don't see the problem there either :p
As far as xterm 256, if I understand this correctly, that's basically 256 colors as opposed to the default 16, right? Do many MUD clients even support this? I haven't poked around a ton of them, but with things like zMud/cMud, gmud, and mush client… the ones I would be willing to bet a vast majority of MUD users use… if those only support 16 colors (not saying they do, but of what I've seen I'm inclined to assume they do), would having such a feature be worth implementing if a vast majority of the players won't get any use out of it?
11 Feb, 2009, David Haley wrote in the 45th comment:
IMO color codes should almost never be specified as actual color codes, but as contextual codes. For instance, "the thing I'm about to give you is a damage message". (EDIT: or, "this is a positive stock price", "this is a negative stock price", or just "this is a stock price", …) Route that through the user's color preferences, and you get the actual color code.
I'm not sure you need to conflate color codes and other forms of dynamic output. You can implement this "dynamic look behavior" by simply having some kind of object-oriented look behavior, where the result of "look" is controlled not by the look command but by the individual objects, with some generic fall-back for objects that don't implement special behavior.
I'm not sure you need to conflate color codes and other forms of dynamic output. You can implement this "dynamic look behavior" by simply having some kind of object-oriented look behavior, where the result of "look" is controlled not by the look command but by the individual objects, with some generic fall-back for objects that don't implement special behavior.
11 Feb, 2009, Hades_Kane wrote in the 46th comment:
DavidHaley said:
What you're suggesting though is entirely different. You're talking about sending text that the person highlights to read. What is your use case? Are you going to send hints that only become visible if you highlight the MUD output with your cursor? If you step back to any form of immersion whatsoever, this is a completely OOC hint with no story-world justification whatsoever. That is not necessarily a sufficient argument on its own, but it is a serious problem IMO.
I never suggested you would send "blank" texts to players without any indication of how to find it. In fact, I figured outline examples of alluding to hidden exits or commands through descriptions would clearly illustrate that you would do the same with hidden text. As far as specific examples? I could probably make some up, as I said, I thought it would be neat thing to consider, but it's not something I've been planning or have implemented. One application might be books with disappearing ink or invisible ink that you get clues elsewhere to highlight, or an alternative means of having parts of room descriptions that would be difficult for one class to see but a bit more obvious to others… I'm sure if I actually sat down and tried to plan out some uses, I could find some creative ways. I don't think highlighting text to simulate reading invisible ink, as an example, would be any more immersion breaking than having to 'type' out a command. Either way, you are interacting with your client to create an affect, so I don't think that would somehow be a serious problem.
Quote
If you are talking about giving hints about where "hidden text" is, why can't you give a hint to do something like "look under the rug" in some room? What is the point of some terminal color trickery when you already can integrate "hidden text" using existing features?
Why implement anything new if you have some round about way to create an affect? What is the point of that? Why implement it so that players can type 'push button' when they can just say a keyword to get a program to fire?
I think sometimes presenting a new and uncommon way to reveal secrets or hide things can be an interesting novelty in of itself. For both players and builders, I think creativity and thinking outside of the box in quests and other things that make an area interactive makes a game and area much more fun to play rather than thinking "well, I already have a way to accomplish this, why bother trying something new?"
Regardless, this is really a moot argument… I already stated that after giving it even a little bit of thought, I realize it would be really easy for people to just change their black output to another color to see the text and would make even considering doing something like that pointless, so it's not something I'm considering anymore.
11 Feb, 2009, David Haley wrote in the 47th comment:
Hades_Kane said:
I don't think highlighting text to simulate reading invisible ink, as an example, would be any more immersion breaking than having to 'type' out a command.
The difference is that a command corresponds to some in-game action, such as applying some kind of special light from an object to reveal the ink. Highlighting text client-side is completely decoupled from anything the character could be doing. It would be kind of like players constructing URLs to go to or something like that.
Hades_Kane said:
For both players and builders, I think creativity and thinking outside of the box in quests and other things that make an area interactive makes a game and area much more fun to play rather than thinking "well, I already have a way to accomplish this, why bother trying something new?"
I think this is kind of an unfair statement. I'm not arguing against innovation; I just happen to think that this particular innovation is kind of pointless. :wink:
11 Feb, 2009, Scandum wrote in the 48th comment:
Hades_Kane said:
The extended color codes isn't that hard to put in, which then easily converts it to support background colors, underlines, blink among some other things… I'm not even quite sure why I bothered patching those in, because I disabled them on pretty much all channels, titles, emotes, etc. Those things seem to be more annoying than actually having any real use, so I guess I don't see the problem there either :p
Background colors come in useful at times, so most muds not providing them makes the argument that 'nobody uses them in a productive manner' a rather weak one.
Hades_Kane said:
As far as xterm 256, if I understand this correctly, that's basically 256 colors as opposed to the default 16, right? Do many MUD clients even support this? I haven't poked around a ton of them, but with things like zMud/cMud, gmud, and mush client… the ones I would be willing to bet a vast majority of MUD users use… if those only support 16 colors (not saying they do, but of what I've seen I'm inclined to assume they do), would having such a feature be worth implementing if a vast majority of the players won't get any use out of it?
It contains 16 standard colors, 216 extended colors, and a 24 color grayscale. I updated Wikipedia's mud list, though I'm not sure if Zmud supports 256 colors or not, google didn't show any matches. But from the looks of it xterm 256 color support is well enough supported to warrant implementation.
11 Feb, 2009, quixadhal wrote in the 49th comment:
DavidHaley said:
I'm not sure you need to conflate color codes and other forms of dynamic output. You can implement this "dynamic look behavior" by simply having some kind of object-oriented look behavior, where the result of "look" is controlled not by the look command but by the individual objects, with some generic fall-back for objects that don't implement special behavior.
Or, you could make context-specific tokens that would call functions in the local context (without needing to be "objects"). If you see $f(12) in the room description, call dynamic_description_func(current_room, 12) and use what it returns. Lots of different ways to do that…
What I think Hades_Kane is confused about is why there are so many flamethrowers being pointed everywhere over the use of constructs like "{R". Some of us (myself) are complaining about the "R" part – because the choices of letters often seem arbitrary and even manage to conflict in one case. Others are complaing about the "{" part – because using something that messes up syntax highlight is annoying, or because it's harder to type than other choices. Still others are complaining because they don't want two different sets of escape codes, even though there is almost no overlap in their functionality (other than them BEING text replacement systems). The other set is the act() codes, BTW. And, a few (myself again) are even complaining about people saying they want to preserve the "look and feel" of ROM in one breath, and then saying that the defacto standard of "{R"-type codes isn't part of ROM, despite the fact that most ROM people seem to be familiar with and use that system.
It comes down to intended audience. If this driver is being written to BE a cleaned-up and re-vitalized ROM, then it probably should follow the conventions that various ROM games have used over the years. As Sandi has pointed out, *I* am not a ROM person – so I rely on what others tell me is true. When I see lots of ROM people talking about Lopes colour system, and see lots of ROM muds that use "{R" style colour codes, I assume that's the standard. When I mention other standards, such as Smaug's "&R" codes, and get told that's a Smaug thing and isn't wanted… I again, assume the only actual thing I've seen used in the field *IS* the defacto standard. Apparently, my eyesight is bad, since ROM has no standard and all those people using Lope's are just rebels.
11 Feb, 2009, Hades_Kane wrote in the 50th comment:
DavidHaley said:
I just happen to think that this particular innovation is kind of pointless.
Due to certain (maybe different) factors, I came to the same conclusion almost immediately after I thought of the idea, so yeah…
Scandum said:
Background colors come in useful at times, so most muds not providing them makes the argument that 'nobody uses them in a productive manner' a rather weak one.
I didn't say no one uses then in a productive manner, I said they seem to be more annoying than having any real use. I've actually seen them used in a productive manner before, namely in wilderness maps and in other ASCII based areas. Generally, though, use of background colors, in my opinion, tend to be as bad as those games that have alternating colors in almost every object and room title.
Quote
It contains 16 standard colors, 216 extended colors, and a 24 color grayscale. I updated Wikipedia's mud list, though I'm not sure if Zmud supports 256 colors or not, google didn't show any matches. But from the looks of it xterm 256 color support is well enough supported to warrant implementation.
Out of the clients I'm sure a majority of my builders or players use, Mush Client seems to be the only one to support it. If we saw a wider adoption of it, then I could see the use. In fact, I'd advocate wider adoption so that it would be more useful, but if some of the major MUD clients don't use it, then that's still a good percentage of your playerbase seeing no change.
11 Feb, 2009, Scandum wrote in the 51st comment:
Hades_Kane said:
Out of the clients I'm sure a majority of my builders or players use, Mush Client seems to be the only one to support it. If we saw a wider adoption of it, then I could see the use. In fact, I'd advocate wider adoption so that it would be more useful, but if some of the major MUD clients don't use it, then that's still a good percentage of your playerbase seeing no change.
Most muds don't use colors in areas. I think it's most useful for muds that allow players to configure display colors like room names, exits, chat, tells, etc.
11 Feb, 2009, David Haley wrote in the 52nd comment:
It's nice to be able to configure certain things to have not only a foreground color, but also a background color, yes. Of course this kind of decision should always be made by the player, not the MUD, IMO and as I said earlier.
12 Feb, 2009, Sandi wrote in the 53rd comment:
First of all, quix, I'm sorry. I feel I got a bit carried away there. And, I thank you for being a gentleman.
Also, I can understand your frustration:
On the contrary, I think if there were a ROM community, we wouldn't be having this discussion - you would have a place to get your answers. Looking around, I don't see anyone else from the ROM list. It looks like I'm the "defacto" community. And, I'm not going to use RaM. Nor is Mac, or Hades, or Grumny or Lasher. The people that will use it will be newbies looking for a simple codebase they can plug lots of snippets into.
Funny you should mention Tiny:
These are what MUSH builders get to play with, and this is why I feel your fear of confusion is unfounded. Then again, you can't crash a MUSH with a 'percent sub'. Perhaps that's a worthy goal for RaM? (Just kidding!)
Now, I think you have a very good point here. I also agree with the others whose complaint with { is that it fouls up paren-matching. Whoever the little snark was that piped up, "Get a better editor!" lost you quite a few people that might have contributed something. For some it's religious, for some love… you might as well tell a Catholic to get a new wife. That remark was rude * stupid. Remember, those of us who know ROM have nothing to gain from this project.
I remember this argument, and I still don't get it. The people using RaM, if they're anything like the people that used ROM, will not be stripping things out. They'll be cutting and pasting your "weirdness" and mangling it to do things that will make your skin crawl.
Readability is next to godliness, but after a while most of us resort to shorthand. I'd suggest both, as MUSH does.
Also, I can understand your frustration:
quixadhal said:
If there were no ROM community, this discussion would not be taking place. Like it or not, what you see here is what we have.
On the contrary, I think if there were a ROM community, we wouldn't be having this discussion - you would have a place to get your answers. Looking around, I don't see anyone else from the ROM list. It looks like I'm the "defacto" community. And, I'm not going to use RaM. Nor is Mac, or Hades, or Grumny or Lasher. The people that will use it will be newbies looking for a simple codebase they can plug lots of snippets into.
quixadhal said:
If you've ever worked on one of the TinyMUD variants, you may have noticed that all the "wizard" commands begin with '@'? There's a reason for that, and a good one IMHO… it makes it obvious what class of command you're using. If I type @users, I know it's an administrative command that will probably show me out of game context data, as opposed to who, which only displays in-game data.
Funny you should mention Tiny:
Quote
SUBSTITUTIONS
The most basic form of evaluation is a %-substitution. Even when other
forms of evalution are not performed, %-substitutions usually are. A
%-substitution is a '%' followed by one or two letters, digits, or symbols.
If a sequence is understood, it is substituted by a corresponding value.
If a sequence is not understood, the initial '%' is removed. In this way,
the '%' also acts similarly to the '\' escape.
For some substitutions, if the letter following the '%' is capitalized, the
first letter of the result of the substitution is also capitalized.
Commonly-used substitutions:
%r Carriage Return
%t Tab
%b Space
%% Literal '%'.
%\ Literal '\'.
%x<code> ANSI color codes. See: ansi().
%c<code> ANSI color codes. See: ansi().
Pronoun-related substitutions:
%s, %S Subjective form: he, she, it, they. See: subj(%#)
%o, %O Objective form: him, her, it, them. See: obj(%#)
%p, %P Possessive form: his, her, its, their. See: poss(%#)
%a, %A Absolute Possessive form: his, hers, its, theirs. See: aposs(%#)
Database substitutions:
%n, %N Enactor's name. See name(%#).
%va-%vz Contents of attribute va through vz
Execution state substitutions:
%m Text of the last command executed.
%0-%9 Value of positional parameter/stack location 0 through 9.
%q0-%q9 Value of temporary (setq) register 0 through 9.
%qa-%qz Value of temporary (setq) register A through Z.
Execution state substitutions (continued):
%# Database number of the object that caused the message to be
displayed or the action list to be run (Enactor).
%@ Database number of the object immediately calling %! (Caller).
This number starts as the same as %#, but can be affected by
u()-type functions, zones, and @function.
%! Database number of the object holding the message or running
the action list (Executor).
%l Database number of the location of the object that caused the
message to be displayed or the action list to be run.
%| A string piped from the previous command in a pipe.
Note that %<whatever> is equivalent to [v(<whatever>)], but is more
efficient.
ANSI CODES
f - flash i - inverse
h - hilite n - normal
u - underline
x - black foreground X - black background
r - red foreground R - red background
g - green foreground G - green background
y - yellow foreground Y - yellow background
b - blue foreground B - blue background
m - magenta foreground M - magenta background
c - cyan foreground C - cyan background
w - white foreground W - white background
For example, "%xc%xuTest%n" would hilight "Test" in cyan and underline it.
Related Topics: ANSI(), ANSI CODES, ANSI SUBSTITUTION, GENDER, V().
The most basic form of evaluation is a %-substitution. Even when other
forms of evalution are not performed, %-substitutions usually are. A
%-substitution is a '%' followed by one or two letters, digits, or symbols.
If a sequence is understood, it is substituted by a corresponding value.
If a sequence is not understood, the initial '%' is removed. In this way,
the '%' also acts similarly to the '\' escape.
For some substitutions, if the letter following the '%' is capitalized, the
first letter of the result of the substitution is also capitalized.
Commonly-used substitutions:
%r Carriage Return
%t Tab
%b Space
%% Literal '%'.
%\ Literal '\'.
%x<code> ANSI color codes. See: ansi().
%c<code> ANSI color codes. See: ansi().
Pronoun-related substitutions:
%s, %S Subjective form: he, she, it, they. See: subj(%#)
%o, %O Objective form: him, her, it, them. See: obj(%#)
%p, %P Possessive form: his, her, its, their. See: poss(%#)
%a, %A Absolute Possessive form: his, hers, its, theirs. See: aposs(%#)
Database substitutions:
%n, %N Enactor's name. See name(%#).
%va-%vz Contents of attribute va through vz
Execution state substitutions:
%m Text of the last command executed.
%0-%9 Value of positional parameter/stack location 0 through 9.
%q0-%q9 Value of temporary (setq) register 0 through 9.
%qa-%qz Value of temporary (setq) register A through Z.
Execution state substitutions (continued):
%# Database number of the object that caused the message to be
displayed or the action list to be run (Enactor).
%@ Database number of the object immediately calling %! (Caller).
This number starts as the same as %#, but can be affected by
u()-type functions, zones, and @function.
%! Database number of the object holding the message or running
the action list (Executor).
%l Database number of the location of the object that caused the
message to be displayed or the action list to be run.
%| A string piped from the previous command in a pipe.
Note that %<whatever> is equivalent to [v(<whatever>)], but is more
efficient.
ANSI CODES
f - flash i - inverse
h - hilite n - normal
u - underline
x - black foreground X - black background
r - red foreground R - red background
g - green foreground G - green background
y - yellow foreground Y - yellow background
b - blue foreground B - blue background
m - magenta foreground M - magenta background
c - cyan foreground C - cyan background
w - white foreground W - white background
For example, "%xc%xuTest%n" would hilight "Test" in cyan and underline it.
Related Topics: ANSI(), ANSI CODES, ANSI SUBSTITUTION, GENDER, V().
These are what MUSH builders get to play with, and this is why I feel your fear of confusion is unfounded. Then again, you can't crash a MUSH with a 'percent sub'. Perhaps that's a worthy goal for RaM? (Just kidding!)
quixadhal said:
Letting act() parse colour codes is a no-brainer. The only place you don't want to translate those codes is in your editor, because it would make it hard to edit them. However, if you make ALL the text replacement symbols use the same format (which is NOT a very descriptive one), you lose the ability to quickly scan any given file or line of code for a given type.
Now, I think you have a very good point here. I also agree with the others whose complaint with { is that it fouls up paren-matching. Whoever the little snark was that piped up, "Get a better editor!" lost you quite a few people that might have contributed something. For some it's religious, for some love… you might as well tell a Catholic to get a new wife. That remark was rude * stupid. Remember, those of us who know ROM have nothing to gain from this project.
quixadhal said:
Precisely because of this kind of reaction. I do enjoy writing code, although I will freely admit that I have less patience with C's quirks than I used to. However, I'm trying to produce a driver that ROM people might be able to use without having to de-construct half of it because it does things in "weird" ways.
There can be no doubt that, if I just do things the way I want to do them, we'll have plenty of those "weird" things that others will feel compelled to undo, or pass us by for something less advanced, but also more "normal".
There can be no doubt that, if I just do things the way I want to do them, we'll have plenty of those "weird" things that others will feel compelled to undo, or pass us by for something less advanced, but also more "normal".
I remember this argument, and I still don't get it. The people using RaM, if they're anything like the people that used ROM, will not be stripping things out. They'll be cutting and pasting your "weirdness" and mangling it to do things that will make your skin crawl.
quixadhal said:
If we're going to ditch the Lope's psudo-standard and make up a new one, I would suggest also ditching the single-character versions of all the symbols for ones that are easy to read without needing to go spelunking through the documentation. $[red], $[damage], etc.
Readability is next to godliness, but after a while most of us resort to shorthand. I'd suggest both, as MUSH does.
12 Feb, 2009, Scandum wrote in the 54th comment:
Sandi said:
On the contrary, I think if there were a ROM community, we wouldn't be having this discussion - you would have a place to get your answers.
The only ROM sub-community I know of is a tight knit bunch held together by AIM and based around a handful of incestuous muds of privately leaked source code. It's like heading out to the coal mines back in the 50s whenever I visit, people writing roleplay notes while running back and forth from the quest master dressed up in rainbow colored equipment, rather surreal. But when I speak of ROM, that's what I envision. :P
12 Feb, 2009, Igabod wrote in the 55th comment:
rainbow colored eq? What's wrong with the imps? couldn't put in a restring command? I know I always had matching armor on when I was a player, couldn't stand having something like a Turban on my head with leather greaves and an Iron breastplate. I always had to restring it all to something attractive, except on one character that was a down on his luck mercenary, but even his mismatched eq sorta matched.
12 Feb, 2009, David Haley wrote in the 56th comment:
Wait, why can players decide willynilly what all their equipment looks like? If you've got leather greaves, how do you turn those into iron leggings?
12 Feb, 2009, Igabod wrote in the 57th comment:
Duh magic! Transmutation maybe. It's always done by a special NPC on any rom I've played with restringing. Usually the questmaster or on occasion there's been a special Wizard character in midgaard that did it. This is a world of magic after all, it's not reality where we KNOW leather can't be turned into iron. It's a land where dragons and goblins and orcs and all kinds of other weird creatures roam. It's a world where if you get hungry you just say a word and a freaking mushroom just pops out of thin air. Why is eq restringing such an odd concept in a world like this?
12 Feb, 2009, David Haley wrote in the 58th comment:
Well, just because the world has different physics doesn't mean it has no physics. If things are actually transmuting left and right, why isn't everybody decked out in the strongest material possible? Why does gold have any value, if people can poof lead into gold? If you take these ideas to their logical conclusion, you get a very strange world indeed.
My MUD allows restringing at the price of quest points, so it's a rather special reward that is given out relatively rarely. It is certainly not the case that everybody can run around with all of their equipment renamed.
My MUD allows restringing at the price of quest points, so it's a rather special reward that is given out relatively rarely. It is certainly not the case that everybody can run around with all of their equipment renamed.
12 Feb, 2009, Igabod wrote in the 59th comment:
well yeah the muds I am referring to also did it with qp, I'm not saying you can just walk up to the guy and have him restring it for free. Think of restringing as magically cloaking the item to make it LOOK different. It still has the same stats, it's still the same item, it just looks different. Like getting a can of gold spray paint and painting a plastic ring. It's still a plastic ring but it looks like a gold ring.
[edit to add] I guess not everybody had theirs restrung on the muds I'm talking about either, I just liked to quest a lot on those particular muds.
[edit to add] I guess not everybody had theirs restrung on the muds I'm talking about either, I just liked to quest a lot on those particular muds.
12 Feb, 2009, David Haley wrote in the 60th comment:
So why don't whole armies do this to look more formidable? In fact, why do people believe anything they see in the world when this is run of the mill?
I don't really like trying to give these things an IC justification because then you run into these consistency issues. At least when it's OOC, you're not trying to fool anybody, and in fact, we don't allow just anything as a new name.
Well, anyhow…
I don't really like trying to give these things an IC justification because then you run into these consistency issues. At least when it's OOC, you're not trying to fool anybody, and in fact, we don't allow just anything as a new name.
Well, anyhow…
Random Picks
Of course, since we don't implement the TELNET standard, negotiating for compliance with ECMA-48 isn't likely to happen soon either, and I'm thinking it's not so useful without doing terminfo support too, right?
Unless, of course, you just assume the end user's terminal can cope with it, and let them suffer if it can't? :evil:
It's an xterm standard that has been incorporated in several other terminal emulators, including rxvt. And there's really no negotiation to determine color support either, so the user has to enable/disable an xterm256 config option, muds could probably incorporate it into the color command: color on/off/xterm256. The TTYPE negotiation could be used to enable it for clients known to support it.
If support is disabled my snippet converts a 256 colors code into a 16 colors code, so it's backward compatible.