10 Feb, 2009, Scandum wrote in the 21st comment:
Votes: 0
quixadhal said:
I'm still waiting on a reasonable 256 colour terminal emulator, so I'll pass on that one. {d is actually "gossip", which defaults to magenta. There is no black, Lope couldn't see black so it's not a colour. :)

Xterm, PuTTY, and countless others support it. And black is useful when using background colors, which I guess is another glaring omission.

TinTin color codes for comparison supports most available options: http://tintin.sourceforge.net/manual/col...
10 Feb, 2009, Ssolvarain wrote in the 22nd comment:
Votes: 0
DavidHaley said:
What is the point of sending text that the person can't see?


Well, highlighting a string would reveal the letters, so it'd be an option for hiding things in plain sight without being too obvious about it.
10 Feb, 2009, David Haley wrote in the 23rd comment:
Votes: 0
Err, that much was obvious :wink: The point was, what's the point of doing that? Making your players go highlight everything the MUD sends to look for hidden messages?
10 Feb, 2009, Tyche wrote in the 24th comment:
Votes: 0
Sandi said:
I think the intersection would be the ability to put color codes in 'acts' along with the existing pronoun and name substitutions. Or rather, you might look at it as the ability to put name substitutions in any of the text strings,including descriptions. Natch, you know where this is coming from.


*shrug* I think we're in agreement. It makes more sense to me to present to the builder/player/programmer a consistent system of marking up text.
I've heard of Lope's color, although we never used it. In fact we extended act's $ escape with the color codes. Looking at Lope's now, I couldn't imagine patching that into my mud.
11 Feb, 2009, Tyche wrote in the 25th comment:
Votes: 0
Ssolvarain said:
DavidHaley said:
What is the point of sending text that the person can't see?


Well, highlighting a string would reveal the letters, so it'd be an option for hiding things in plain sight without being too obvious about it.


What happens on your client when you send "\033

What happens on your client when you send "\033[8mHello\033[0m"?
11 Feb, 2009, The_Fury wrote in the 26th comment:
Votes: 0
Most clients seem to be able to handle these codes well enough, so you might as well incorporate them into your code and use them as you feel fit. If your color code does not currently support all these HD, code them in. I know i had to add in inverse and italic text into our game. They do come in handy at times. The black text in the image was inversed so that it was readable. Black on black is hard to read and all :)

11 Feb, 2009, Tyche wrote in the 27th comment:
Votes: 0
Hades_Kane said:
Is it possible to actually code in black as a color?


I've been using a white background for so long I didn't think it was possible to use white as a color!
11 Feb, 2009, Sandi wrote in the 28th comment:
Votes: 0
From my help files:

ANSI standards provide 8 dark colours for white screens and 8 light colours
for black screens. None of the standard colours display well on a medium
grey screen. So, whatever your background preference, you should adjust
the colours of your client's palette as we use 12 colours here (no black,
light/dark grey or white) to provide colour keyed informational messages.
We suggest a black background screen with 8 medium and 8 pastel colours.
11 Feb, 2009, Sandi wrote in the 29th comment:
Votes: 0
Tyche said:
What happens on your client when you send "\033
What happens on your client when you send "\033[8mHello\033[0m"?
[/quote]

Nothing, in zMUD on ROM. It just prints to the screen. Same for SimpleMU and MUX.

There was a time, about a dozen years ago, when PennMUSH would let you save escapes. Ooops. A friend of mine created a gadget that would send random characters, in random colors, to random locations on your screen. Of course, it overwrote whatever was there, but I thought it was sorta pretty. This was quickly fixed after I crashed the client of a staffer on one of the Dev's MUSHes. Lottsa ansi and dial-up don't mix.
11 Feb, 2009, quixadhal wrote in the 30th comment:
Votes: 0
Intersting.. here's half the battle for 256 colour support, IFF you're using xterm or a linux terminal.

http://push.cx/2008/256-color-xterms-in-...

Now, finding the actual ANSI sequence for such extended colour codes…
11 Feb, 2009, Sandi wrote in the 31st comment:
Votes: 0
quixadhal said:
You can say what you want, but if Lopes system isn't considered the "standard" for ROM based MUDs, why are there sooooo many out there which make it the first thing they add in?

Most likely because it's the only game in town.

quixadhal said:
I would argue that people who have worked on ROM derived codebases that have colour are probably going to expect Lope's { style colour codes. That is, for better or worse, part of the community's sense of the feel of ROM. Is that worth preserving, or is it something best replaced by a newer idea?

What are you basing you argument on? Experience or a personal fantasy? (Sorry, but you've been asking for this.)

quixadhal said:
Do you want to code a colour system that works the way, historically, the community expects it to work? Or, do you want to invent a new system that works "better"?

Something better, of course. QuickMUD (nee FastROM) was thrown together just because we were all tired of walking people through installing the hideous packages that were available. You're providing a great example of the "monkey see, monkey do" principle. The "ROM community", is another fiction of yours, but if it still existed, it would be better served by decent OLC and color snippets that could be easily installed and, most importantly, provide decent examples of how code should be written.

quixadhal said:
$ isn't actually any kind of standard escape… it's the escape for the act() subsystem from DikuMUD. The act codes serve a different purpose than colour codes, and are far more situational. $o in a room description, for example, means nothing. In the description of an ACTion though, it gets replaced by the object name.

But you can put color codes in act(). Duh. You may disagree, but I don't think it takes that much imagination to envision one parser for all the MUD's output, which is basically what Lope's is. If you log into my MUD, in the second room the description addresses you by name. In various places, weather is shown in the same fashion. You will see descriptions that begin "You are standing in…" unless you're sitting. Or flying. And different races have appropriate descriptions of how they fly. Faeries flutter and Dragons soar. There are signs that change with events. It's all done with escapes and an output parser.

quixadhal said:
If we merged the colour codes into the same system (not entirely without merit), it would be confusing for new builders which letters belonged to which kind of functionality.

This is bull, and this is insulting. Again, on what experience do you base this? I'm sure Fizban will agree that we've both seen Newbs handle much more complicated things with aplomb. It's certainly simpler than 'mobprogs' which are de rigeur for Builders these days. In fact, it's a good introduction for the timid.

quixadhal said:
One of the things I did in the Smaug code…

This is the most annoying thing, it's obvious you have the ability - the question is, why won't you use it?
11 Feb, 2009, KaVir wrote in the 32nd comment:
Votes: 0
Sandi said:
But you can put color codes in act(). Duh. You may disagree, but I don't think it takes that much imagination to envision one parser for all the MUD's output, which is basically what Lope's is.

I agree with you in theory, but in practice I found the dynamic description parsing to be one of the most expensive operations on my mud. Supporting colour codes separately, while not as elegant, certainly helped to keep down my hosting costs.
11 Feb, 2009, Sandi wrote in the 33rd comment:
Votes: 0
KaVir said:
I agree with you in theory, but in practice I found the dynamic description parsing to be one of the most expensive operations on my mud. Supporting colour codes separately, while not as elegant, certainly helped to keep down my hosting costs.

Now, that's a fascinating tidbit. May I be so bold as to suggest that your core procedures, having been written by a professional programmer, make the parsing stand out like that? The PennMUSH parser written by T. Alexander Popiel made enough of a difference that's it's now used by all flavors of MUSH/MUX/Rhost. Still, when Thorvald and I profiled it, the difference was in the single digits, as I recall. (Alex is the biggest efficiency freak I've known, yet he'd be the first to tell you it usually doesn't matter. It's just a fun problem.) I liked his first version, where he saved a pass by not looking for the closing bracket. :evil:
11 Feb, 2009, KaVir wrote in the 34th comment:
Votes: 0
I'm sure my code could be optimised further, but it's always going to be expensive because of the sheer amount of text it has to go through. I use the dynamic description code for pretty much everything, but the combat messages are by far the most excessive.
11 Feb, 2009, Hades_Kane wrote in the 35th comment:
Votes: 0
DavidHaley said:
Err, that much was obvious :wink: The point was, what's the point of doing that? Making your players go highlight everything the MUD sends to look for hidden messages?


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?
11 Feb, 2009, Hades_Kane wrote in the 36th comment:
Votes: 0
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?
11 Feb, 2009, Sandi wrote in the 37th comment:
Votes: 0
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.
11 Feb, 2009, Scandum wrote in the 38th comment:
Votes: 0
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?

It doesn't support background colors, underline, black, blink, reverse video, bold background colors, or xterm 256.

I went ahead and published an xterm 256 color code snippet that is backward compatible with ASCII color and also supports the full ECMA-48 set.

http://www.mudbytes.net/index.php?a=file...

People wanting to use it should probably wait till my Feb 11 update with a few bug fixes is added.
11 Feb, 2009, quixadhal wrote in the 39th comment:
Votes: 0
Sandi said:
quixadhal said:
You can say what you want, but if Lopes system isn't considered the "standard" for ROM based MUDs, why are there sooooo many out there which make it the first thing they add in?

Most likely because it's the only game in town.

And why is that?

Sandi said:
quixadhal said:
I would argue that people who have worked on ROM derived codebases that have colour are probably going to expect Lope's { style colour codes. That is, for better or worse, part of the community's sense of the feel of ROM. Is that worth preserving, or is it something best replaced by a newer idea?

What are you basing you argument on? Experience or a personal fantasy? (Sorry, but you've been asking for this.)

Sorry…. I was assuming that all the people who chimed in, over the last 3 months, saying that Lope's format was the de-facto standard for ROM, that ROM colour codes looked like {x, and that Lope's snippet was always one of the first ones installed – PLUS the fact that it's included in QuickMUD and probably (No, I have not downloaded and looked at them all) several other derivatives – lent some credence to the idea that it was the normal way you ROM folks did things. Don't tell me "ROM doesn't have colour", because then you have to show me that there are more running ROM muds out there which have no colour support, than those which do. Good luck finding them…. the RaM test driver doesn't count. :)

Sandi said:
quixadhal said:
Do you want to code a colour system that works the way, historically, the community expects it to work? Or, do you want to invent a new system that works "better"?

Something better, of course. QuickMUD (nee FastROM) was thrown together just because we were all tired of walking people through installing the hideous packages that were available. You're providing a great example of the "monkey see, monkey do" principle. The "ROM community", is another fiction of yours, but if it still existed, it would be better served by decent OLC and color snippets that could be easily installed and, most importantly, provide decent examples of how code should be written.

That one is not such a fiction. 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.

Sandi said:
quixadhal said:
$ isn't actually any kind of standard escape… it's the escape for the act() subsystem from DikuMUD. The act codes serve a different purpose than colour codes, and are far more situational. $o in a room description, for example, means nothing. In the description of an ACTion though, it gets replaced by the object name.

But you can put color codes in act(). Duh. You may disagree, but I don't think it takes that much imagination to envision one parser for all the MUD's output, which is basically what Lope's is. If you log into my MUD, in the second room the description addresses you by name. In various places, weather is shown in the same fashion. You will see descriptions that begin "You are standing in…" unless you're sitting. Or flying. And different races have appropriate descriptions of how they fly. Faeries flutter and Dragons soar. There are signs that change with events. It's all done with escapes and an output parser.

Yes, of course you can, but the function of the symbols is very different, as I said in my previous post. 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.

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.

To add one more log onto the fire, I dunno about you but I would use a small number of such colour codes in my room descriptions. I suspect others would use a non-so-small number. Now, if the same parser is handling all escapes, and you come across a $o in your room description, what happens? Well, did I mean the "object" you were wielding? Some other "object" in the room? Did I pass a NULL when printing the room description, thus making it either crash or print "something"?

Why am I trying to print an object in the room anyways? Oh, I wasn't… my new builder wanted to make something "orange" and forgot that it's not $o, but it's $y for "dark yellow". Sure, blame the n00b. However, if the two systems are distinct, that confusion wouldn't have happened since colour codes don't start with $.

Sandi said:
quixadhal said:
If we merged the colour codes into the same system (not entirely without merit), it would be confusing for new builders which letters belonged to which kind of functionality.

This is bull, and this is insulting. Again, on what experience do you base this? I'm sure Fizban will agree that we've both seen Newbs handle much more complicated things with aplomb. It's certainly simpler than 'mobprogs' which are de rigeur for Builders these days. In fact, it's a good introduction for the timid.

I wasn't trying to be insulting, see my above argument for why I think it's a bad idea *IF* we stick with terse one-letter codes. If we used longer tags that were self-descriptive, the problem goes away, but then people complain about too much typing.

Sandi said:
quixadhal said:
One of the things I did in the Smaug code…

This is the most annoying thing, it's obvious you have the ability - the question is, why won't you use it?

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

We need one of those vote thingies… *grin*

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.

Here are the ACT codes that ROM supports:
$$      $
$t arg1
$T arg2
$n PERS(ch)
$N PERS(vch)
$e HESHE(ch)
$E HESHE(vch)
$m HIMHER(ch)
$M HIMHER(vch)
$s HISHER(ch)
$S HISHER(vch)
$p OPERS(obj1)
$P OPERS(obj2)
$a ANA(obj1->name)
$A ANA(obj2->name)
$d "door" or exit name of arg2
11 Feb, 2009, quixadhal wrote in the 40th comment:
Votes: 0
Scandum said:
I went ahead and published an xterm 256 color code snippet that is backward compatible with ASCII color and also supports the full ECMA-48 set.

http://www.mudbytes.net/index.php?a=file...

People wanting to use it should probably wait till my Feb 11 update with a few bug fixes is added.


Is the 256 colour support part of the ECMA standard, or is that an xterm-specific thing? My 5 minute perusal of the technical document found quite a bit about cursor control and character sets, but nothing about actual attributes like colour. However, it is a technical document so I probably just don't know the right "magic acronym" to look for. :)

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:
20.0/80