A few people have chimed in on the issue. Currently IMC2 uses color tokens that must be translated on the mud side both directions. Eg, when you send color from users you must convert your color code to a universal color code that someone on the other end will know to convert to their own private system.
Strong arguments have been made for simply sending raw ANSI color codes. Although, this seems to be a divided opinion. Any debate on the subject is, of course, welcome.
The universal color code was a hack when it was created and is a hack now. Direct ANSI conversion is the way to go. It's 2009, surely people have clients that can display color properly by now? :)
Well if you really don't want to transmit ANSI, that seems like a logical thing to consider as a client-side toggle because some people will want it, others may not.
Ehhh. I don't think it's that. I mean—hating color, someone might already have a rainbow-looking channel for their IMC stuff. Then you add a bunch of user supplied colors. In any event, it can be stripped on an individual basis. (And I think I would for my projects.)
03 Aug, 2009, Chris Bailey wrote in the 9th comment:
Votes: 0
Personally I would prefer to receive no color. I don't see any particular reason to when I can colorize my incoming information however I like. That being said, if color is a must I think clients should be required to translate their color codes to ansi before sending them.
Personally I would prefer to receive no color. I don't see any particular reason to when I can colorize my incoming information however I like.
I was thinking that myself. I assume these colour codes are for players who like to write that horrible rainbow text in their messages? I allow players to specify which colour they see each channel, but I don't allow them to force colours on each other, and if I added IMC I would treat it the same way - strip out both incoming and outgoing colour codes.
03 Aug, 2009, quixadhal wrote in the 11th comment:
Votes: 0
The ONLY argument I can see against using ANSI is those who want to support a superset of ANSI on local channels, or channels between MUDs they know support it. It adds a special case to channel handling.
Personally, I agree with the anti-colour camp. The MUD itself is free to assign individual channel colours, based on user and/or admin preferences. Having colour codes (of any kind) inside a message is just asking for problems.
I see no reason why this can't be a per-channel thing. If the channel is set to no colour, strip it, if not, send raw ansi codes.
03 Aug, 2009, David Haley wrote in the 13th comment:
Votes: 0
I don't see why we need color in the first place. I would actually be somewhat opposed to allowing it sent in messages. I think it's impolite to force colors on other people.
If we really, really must have color, then yes, it might as well be with ANSI codes.
I see no reason why this can't be a per-channel thing. If the channel is set to no colour, strip it, if not, send raw ansi codes.
I like this option the best because it provides choice. Perhaps the primary network channels should all be maintained at no color (lets all save bandwidth, of course … :) with an exception of one channel similar to the current ifree. Let private non-primary channels retain control of their own preferences, though.
Ok. Not trying to be hostile or anything, but I don't understand. Why is there such a large opposition to the use of color? From my experience on the current network and on previous networks, the use of color has always been commonplace. I don't recall it ever being abused or anything like that, just a bit finicky in being parsed under the current token system outlined in the IMC2 protocol.
If bandwidth is really of that much concern, sticking with a token system like exists now seems like the logical solution.
Otherwise I just plain don't get it, really.
03 Aug, 2009, David Haley wrote in the 16th comment:
Votes: 0
I don't think that bandwidth is the concern here. It's just that it seems unnecessary to be sending color around. The fact that nobody ever does it (intentionally) is indication to me that we shouldn't really be bothering with it. It's not that the protocol should search-and-destroy ANSI color codes, it's that there should be no particular effort paid to anything. In particular, it should be made clear that chat messages should be taken literally so that clients don't try to parse color codes and thereby screw up URLs or words like D&D or whatever.
I don't like the idea of forcing people to use color on IMC for the same reason I don't let spaztastic teenage mortals write room descriptions. (I believe the rainbow puke picture would be a good addition here.)
The current Freedom client for IMC2 already allows individual users to toggle network color on or off. I don't know how other clients that have been developed handle it. If this is truly that big of an issue, then new clients for IMC3 could simply incorporate the same toggle. This sort of setup is made far easier though with standard network color tokens. Stripping out raw ANSI codes would make things harder.
03 Aug, 2009, David Haley wrote in the 19th comment:
Votes: 0
It's not just an option to strip out color: it's awareness that the clients should not expect (their own MUD) color codes in IMC packets.
That is, if somebody says: "Hey have you played D&D" or "the answer is x^n", no MUD should try to parse those as color codes.
The toggle to enable or disable color should be at the ANSI code level, and should also be handled client-side.
But I think it's extremely important to stress that clients shouldn't try to parse IMC packet contents for their own specific color codes. IMC packets should only be treated as they are meant to be according to the specification.
03 Aug, 2009, Chris Bailey wrote in the 20th comment:
Votes: 0
I do agree that stripping out raw Ansi codes would be a pain in the butt. Not something I want to do! Which is why there should be no color. :P
Strong arguments have been made for simply sending raw ANSI color codes. Although, this seems to be a divided opinion. Any debate on the subject is, of course, welcome.