A way to inform the server of the client fore/background-colours

Hello,

Nearly every time MUD wizards want to send colourized text to the client they have to ask themselves which background-colour the client-user has set and if the used colour would be visually discernable.
Yellow on white is very difficult to read.
Now, MUD wizards cant know this of course, so we have more or less tried never to use some foreground colours that are difficult to read on the most common default client backgrounds. (these being black, white, dark-green and a light grey)

You could argue, that it is the users responsability to change his fg-colours so that he is able to see everything when he sets a new bg-colour, and this is indeed possible, but that is not what I am on about.

The thing is that it would be much nicer from the useability side of things (think: newbies!) if the MUD could automatically know what bg-colour the user has set and be automatically able to adapt to that. (How a MUD would do that is another question, maybe by using a predefined set of incompatible colours.) I want users to log in into the MUD and that it just works (ie. they can see the text!).

Defining a plugin in Mushclient that does this (maybe over some custom protocol) is not my goal, also. I am aiming at a bigger crowd. I would like a de-facto-standard way of doing this that different clients and different MUD-servers could include. Something that can be widely adopted and everybody could profit of.

Obviously I am historically a bit late to suggest a new standard in 2009, but this is my idea:

Use a MXP command to request the fg- and bg-colour of the client, similar to the MXP VERSION or MXP SUPPORT/SUPPORTS tags.

Mushclient has already added some custom MXP tags, I think. So maybe I can convince you of adding another. Maybe even this idea could gain momentum and we could get Zugg to add it to his spec. I don't know, since I haven't had much experience in his forum, if he would be ameanable for something like this.
Mainly my (and the german MUD) user base uses Mushclient, so thats why I am here and I would need Mushclient to do this, not CMUD.

But I think only MXP can agreeably achieve this for as many clients and MUD-servers as possible, since it is well known and supported.

So we could have something like:

Server sends:
MXP: <FG-QUERY>
Client responds:
MXP: <FG-STATE yellow>
or MXP: <FG-STATE #eeffbb>

Also the Client would need to send that same tag on a colourchange initiated by the user (in the menu for example).

I have been thinking of this for quite some time now and I would really be interested in what you think about it.

Thank you,
xtian@avalon

ps: The names of the tags are really not important, could be anything you wish, of course.

why MXP, and not telnet?
MXP isn't really designed to do such question-answer negotiations

Actually it is. The MXP <version> and <support> queries are recommended and the client will answer them with his own MXP tags.

Implementing this with yet another telopt (with standarised subnegoatiations) would effectively just be a new MUD protocol, wouldn't it. At least with MXP you can put some pressure behind people (server admins and client programmers) to adhere to the spec or a useful addition to the spec.

If Mush does it, maybe others will follow.

It's a nice idea, but really it should be suggested to Zugg, as he "owns" the MXP spec.

I don't really want to add features that won't be supported by zMud or cMud, as they are the other main clients that use MXP (that I am aware of).

In any case, how would this work? Say you find that the user has yellow background text, and you want to put a word in yellow, obviously that won't work, but what would you use instead? Potentially there are thousands of colours they might be using, so you would need some sort of palette of alternatives. This could become very fiddly to get right.

You will probably find that newbies won't fiddle with their colours, and thus the problem goes away for them.

Ok, I will try to transfer this to Zuggs forums.

To answer your questions: Even if a newbie doesn't change the bg-colour, I would need a way to know that default bg-colour of the client. Of course, I can keep a record of all known clients and their backgrounds - and this I will have to do either way - but you will see the problems that would arise from this: What if you decide to change the default bg-colour for your next version, what of new clients not on my list, etc.
I am trying to avoid to have to prompt the user for their client-settings.

What I was thinking of was checking if the client-bg-colour and our textcolour are "too close" (for some distance measure, maybe in HSL-space, havent decided yet), and if so, change the colour I would output to something that increases the contrast (with MXP the client would be using true-colour, anyway). So, it would be an automatic calculation. The palette-map was just something I mentioned to simplify my post.

I will post this in the MXP-forums and then inform you of the outcome, if you are still interested.

Greetings from Germany,
xtian

I would suggest that clients should have, as a default, the standard 16 ANSI colours, like this:



In the early days of MUSHclient I had slightly different colours because I personally liked them more, but was convinced to go the "standard" route fairly early.

As for Zugg's forums, I monitor those from time to time, so I'll be interested to see what they say to you.

IMO, imms shouldn't be choosing which colors to send in the first place. Colors should be based on category, and then the user should be able to select the scheme used (by the MUD) to translate categories to actual color codes. Make a few of these, catering to generally dark and generally light backgrounds, and then let people customize them to their hearts' content. Then, you have solved not only this problem, but several others as well, for example you have given the user the ability to use colors that make sense to them to highlight certain events that they find relevant.

And don't forget that there are some (many?) people who are colourblind. Following David's suggestions would let them manufacture a colour scheme that makes sense to them.

Question, why bother with this, doing it automatically would be rather complicated and tricky, why not just make a command that the user can type to specify what their background color is. Like backgroundcolor blue during character creation. Which records it on their character. It should fall to them for the responsibility, because they're the ones that'd be bothered by not being able to read something. It should fall to them to fix the problem, not the client programmers. It's not like people change their colors often anyway, so chances are they'd only need to type it once. Coding it into all the clients seems like a lot of work for something that I can't see being used all that often.

Edit: Oh looks like somebody already suggested something like this. Only better.

Please excuse, my answers have been delayed a bit:

David Haley: I don't agree that MUD shouldn't do colour formatting at all. The reason being: I want things to look good. If I need to have every player set a special colour to special tagged events himself, most of them won't bother to do this (because they will not get it or won't read the corresponding announcement, etc). It would be like saying every web-user should write his own default css-stylesheet.
On the other hand, if I define a default colour for the event -> well then we're doing colour-formatting again and will run into the problems mentioned above.

Twisol: Offering the possibility to tag events so that the player can modify them (mud-side or client-side) is a sensible thing for a MUD to do.

Cage_fire_2000: Ideally users should not have to setup more technical stuff than they need to. In my opinion, even having to enter a port number is too much detail. 95% of gamers don't even know what that means. My intention is to make my MUD as easily useable as possible. Going back to the web-example: What would you say if your browser asked you for every webpage what colours you have set? It shouldn't be necessary. Stuff should just work for the user.

Ok, I moved my suggestion to Zugg's development forums. We will see how it goes.

OK, who said anything about defining a color scheme for every 'webpage'? I'm saying you define them, but you simply prompt them during character creation "Which of these color schemes show up best on you screen?" or "What color is your background so we can make the colors show up best?" You'd have to define some default color schemes anyway, even with the automatic negotiation, so why not just have them type a command /once/ during character creation, then record it for future logins in their player data.
I mean you said yourself there's like 4 common colors for background, you just present four different color schemes and they pick the one they can read the best. It's not /that/ technical, you're just making it seem that way, it's all how you phrase the question, I mean how is "What color is the background of your screen?" anywhere as technical as port number?
People aren't constantly changing their background color, so only setting it once should suffice, and most games have them pick things a lot more complicated than that at character creation, like which race they want to be, or what class, and they have to weigh the pros and cons of each one. So if they can't figure out 'Which colors can you read best?', then they're pretty hopeless quite frankly. I know first hand how stupid people can be, but I think if they're smart enough to find and use a MUD, they should be smart enough to type a command /one time/.
Also if it does negotiate the background color, what format would that be in? 0-15 for the standard ANSI? RGB? Also, how would you define a color scheme for every possible background color? Also, what about if they set a background picture? There's no way that the client would be able to generalize the color of it to send that. Frankly, it seems like you're taking something simple and grossly overcomplicating it. Not to mention some people like to have control over their own display colors, so if you kept changing them every time they tried to change them to something else, it'd probably tick them off. Not to mention possibly breaking color triggers. Also, who besides you would possibly want to go through the trouble of changing their server's source code to support that kind of thing? Is there really a high demand?? Some servers don't even somebody who knows how to change the sourcecode on that level, which'd be necessary to use an automatic negotiation.
Also, Colors are really up to the end user, and what you're proposing usurps control over them to the server end. How will you know exactly how the colors /you/ pick based on their background color will be what they like?

I suppose I could've organized my thoughts better, but it's early.

P.S. Some websites actually /do/ let you click on links to pick different schemes.

Yes, I understand your point, but I used the web example to drive home my point: You want to use your browser, not configure it.

But MUDs that want to adapt their formatting and offer the user the choice of predefined colour schemes ("which one looks the best for you" - like you said) will have implemented the whole colour scheme-thing anyway. So going from there to a fully automated procedure is a rather trivial step and not overcomplicated.

And implementing that process is worth it: In my opinion for every "obstacle" you set up for a newbie, you loose a player - mostly people that just want to check the game out. Because adding an option here, adding one there accumulates and users will get bored before they even really entered the world.

So my logic is:
If you want to do colour formatting, you will hit the "dont use yellow"-wall at some point. If you want to get around that, you will have to ask the user what bg/fg colour he has set. If you have that, it could as well be done invisibly for the user.

As for the encoding of the colour, please check out my first post: Encoding it into pinkfish codes is an idea, as well as RGB notations.

Yes, but again, my point is that an automatic negotiation has it's flaws, it's great for users who can barely use a client, but for everybody else it's a problem. For the people who actually /want/ to set their own colors an automatic negotiation would keep changing them every time they change their background color, possibly screwing up any highlighting triggers that match on certain colors.

Also, like I said, what is it supposed to do if they have a background picture? The background color could be white but the background picture could be mostly black.

Wouldn't it just be simpler to use the existing RFC 1091 client negotiation (see terminfo() on PennMUSH) to figure out which client they're using and use the default colors of that client? Well, at least simpler for the client developers. So if they use MUSHclient assume the background color is black, if they use terminal assume white, etc. Or like I said just have them type a command once. If one command is gonna turn them away from a game, then they're really fickle and probably would get bored with the game quickly and stop playing, leaving you with lots of abadoned character files to clean up. I agree stuff like having to write a 5 page bio for your character is ridiculous and has turned me away from many games, but something as simple as picking colors shouldn't lose any actual worthwild players, if they're too lazy to type one command, then they're probably too lazy to actually play the game long enough to get interested.

I'm sorry, but I haven't played any MUDs in a long time, but seriously, I would be interested to how many MUD admins actually would actually use this? Trying to request a feature be put into all the clients just for a single game seems like a lost cause, usually client features are only put in if they're found /universally/ useful, like screen width and height, that was universally useful, it doesn't matter if it's MUDs, MUSHes, MUXes, MOOs, knowing where to wrap text is useful. What you're requesting isn't nearly as useful as you seem to think it is. I admit I haven't tried very many clients before, but the ones I have used are mostly black background, only terminal was white. And who uses Terminal anymore?

Personally though, I think you're wasting time, even if it was implemented in one client, you'd have a god aweful time trying to get the whole community to implement it, especially if you're the only game that'd use it.

Edit: *removed suggestion to make a plugin as I noticed in your first post that wasn't your goal.*

Edit: Techinically they don't even /need/ to do anything, you could default to a black background, and have a message that says "If colors aren't showing up for you, just type "clientbackground Color" where Color is the background color of your client." Anyway, I've wasted all my remaining free time before work typing this, so I'll cut it off here.

I agree with this, and am surprised that SmaugFUSS still asks this question as part of making a new character:



This is where I find people getting stuck. Obviously you have to answer it, but what is RIP? What is ANSI? Do you really want "no color support"? IMHO that question should go, and you could validly assume that 99.9% of terminal emulation programs will support ANSI anyway. Or, use the terminal type negotiation to at least check for common clients.

I would also get rid of stat rolls. Stuff like:



... is also offputting. Newbies won't know if the stats are good or bad, and in any case, if they are bad they are given an unfair start to the game. Much better to give eveyone the same stats (perhaps modified for the class they chose). You could always give them 10 "spare" stats they can later add into one of their primary stats when they understand why they would want to do this.

Here's another one:



Do they mean "what sex do you want your character (avatar) to be?". If so, they should say that. Otherwise, why ask? What is the point of asking what *my* sex is? Next they'll want to know my religion. ;)

I would also clarify with something like "Choosing a gender will not affect game play in any way, however it may affect how other players interact with you.".

In fact, as I suggested in another recent thread, I would make all character creation stuff take defaults, and let you change items (like class or race) if you want to, so that, after connecting, you can just accept the defaults and be playing a moment later.

Something like this:

---

As for the colours (back on topic) I'll see what they do to you in Zugg's forum. :-)

By the way: For mudadmins out there who check the telnet terminal type, a good advice is to also check for the MXP version string. It will be more accurate (in both mushclient and zmud/cmud the user may change the TTYPE) and you will get a way for versioning (ex: mushclient before x.y doesnt understand 256 colour codes, but afterwards it does).

I think you might have kind of missed my point. I didn't mean that there should be no colors, nor did I say to make everything colorless by default and force players to set all the colors themselves. It's nothing like telling everybody to write their own stylesheet. It's like writing a bunch of stylesheets, and then letting them choose which one they want, and furthermore letting them customize it if they feel like it.

Basically this whole affair seems like quite a bit of overkill, when a simple question could be asked during creation (before you use any colors at all): "do you have a light or dark background?" From there, let them play more with colors using your provided schemes, and their ability to customize if they feel like it. In particular I believe that this statement is incorrect:
"So going from there to a fully automated procedure is a rather trivial step and not overcomplicated."

If it were trivial, we wouldn't be having this conversation in the first place. It's not trivial, because now all clients need to be able to handle this negotiation. It's not trivial, because the client might report something, making the MUD server do something that the player didn't want. And so forth.
Creating standards that a whole pile of clients have to start respecting is never trivial, even if the basic idea is simple.

Well said, I think that mostly sums it up.

I haven't seen any posts that seem related to this on the Zugg forums. Have you made one? Are you going to post on the cMud or zMud section?

I doubt that Zugg will make changes of that sort to zMud, as he is now mainly supporting cMud, which means that a client which is still in fairly general use will not support your proposed idea.

Have you seen this?

http://forums.zuggsoft.com/forums/viewtopic.php?t=34261

Zugg seems to have already covered finding out the text and background colours.

Uhm, I can't open that, it gives me a login screen, and I'm not creating an account on a forum I'll probably never use again, just to read a post. I don't care much anyway, other than idle curiosity.

Well I assumed that Xtian would be able read that page, and he is the one that cares about the subject.

Yes, thanks, I'm back and just had the time to fill up on the newest developments. To sum it up for the others: Zugg includes my colour requests into a broader image where the server may request different client features or options (over MXP). This is exactly what other mudadmins and I have a (more or less badly maintained) client-feature database for and it would be great to be able to get this data automatically (i.e. reliably).

To finish up on the other recent posts, please forgive that I am repeating myself:
Better than asking a user for his client-fg/bg colour is to have a standard set already defined for every client (as in the database mentioned above).
Better than that is the availability of that data as supplied by the client (that way it would also be current).

If the mudlib can already handle colour schemes and picking of a good default scheme dependent on user interaction (or the client TTYPE), then it would only be trivial to add the automatic request mentioned above - trivial on the server side. This is what I meant a few posts back.

Of course getting a multitude of clients and servers to implement and adhere to a new standard is not trivial. But that was why I posted the thread in the first place, wasn't it?

Comment: Even if this works, for old clients we will still have to use the old way and more or less guess the data.