[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  MXP and Pueblo
. . -> [Subject]  A way to inform the server of the client fore/background-colours
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

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

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Pages: 1 2  

Posted by Xtian   (53 posts)  [Biography] bio
Date Thu 15 Oct 2009 04:42 PM (UTC)

Amended on Thu 15 Oct 2009 04:47 PM (UTC) by Xtian

Message
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.
[Go to top] top

Posted by Erendir   Germany  (47 posts)  [Biography] bio
Date Reply #1 on Thu 15 Oct 2009 05:43 PM (UTC)
Message
why MXP, and not telnet?
MXP isn't really designed to do such question-answer negotiations
[Go to top] top

Posted by Xtian   (53 posts)  [Biography] bio
Date Reply #2 on Thu 15 Oct 2009 06:29 PM (UTC)
Message
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.
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Fri 16 Oct 2009 03:50 AM (UTC)
Message
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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Xtian   (53 posts)  [Biography] bio
Date Reply #4 on Sun 18 Oct 2009 03:56 PM (UTC)
Message
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
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #5 on Sun 18 Oct 2009 07:58 PM (UTC)
Message
I would suggest that clients should have, as a default, the standard 16 ANSI colours, like this:


// standard 16 ANSI colours

  xterm_256_colours   [0] = RGB (0, 0, 0);         // (black)       
  xterm_256_colours   [1] = RGB (128, 0, 0);       // (maroon)      
  xterm_256_colours   [2] = RGB (0, 128, 0);       // (green)       
  xterm_256_colours   [3] = RGB (128, 128, 0);     // (olive)       
  xterm_256_colours   [4] = RGB (0, 0, 128);       // (navy)        
  xterm_256_colours   [5] = RGB (128, 0, 128);     // (purple)      
  xterm_256_colours   [6] = RGB (0, 128, 128);     // (teal)        
  xterm_256_colours   [7] = RGB (192, 192, 192);   // (silver)      
                       
  xterm_256_colours   [8]  = RGB (128, 128, 128);  // (gray)                 
  xterm_256_colours   [9]  = RGB (255, 0, 0);      // (red)               
  xterm_256_colours   [10] = RGB (0, 255, 0);      // (lime)              
  xterm_256_colours   [11] = RGB (255, 255, 0);    // (yellow)            
  xterm_256_colours   [12] = RGB (0, 0, 255);      // (blue)              
  xterm_256_colours   [13] = RGB (255, 0, 255);    // (magenta)  
  xterm_256_colours   [14] = RGB (0, 255, 255);    // (cyan)        
  xterm_256_colours   [15] = RGB (255, 255, 255);  // (white) 


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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #6 on Mon 19 Oct 2009 09:06 PM (UTC)
Message
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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #7 on Mon 19 Oct 2009 10:44 PM (UTC)
Message
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.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Cage_fire_2000   USA  (119 posts)  [Biography] bio
Date Reply #8 on Thu 22 Oct 2009 12:56 AM (UTC)

Amended on Thu 22 Oct 2009 12:58 AM (UTC) by Cage_fire_2000

Message
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.
[Go to top] top

Posted by Xtian   (53 posts)  [Biography] bio
Date Reply #9 on Tue 10 Nov 2009 09:16 AM (UTC)
Message
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.
[Go to top] top

Posted by Cage_fire_2000   USA  (119 posts)  [Biography] bio
Date Reply #10 on Tue 10 Nov 2009 12:38 PM (UTC)

Amended on Tue 10 Nov 2009 12:40 PM (UTC) by Cage_fire_2000

Message
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.
[Go to top] top

Posted by Xtian   (53 posts)  [Biography] bio
Date Reply #11 on Tue 10 Nov 2009 06:26 PM (UTC)
Message
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.
[Go to top] top

Posted by Cage_fire_2000   USA  (119 posts)  [Biography] bio
Date Reply #12 on Tue 10 Nov 2009 07:00 PM (UTC)

Amended on Tue 10 Nov 2009 07:06 PM (UTC) by Cage_fire_2000

Message
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.
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #13 on Tue 10 Nov 2009 07:31 PM (UTC)
Message
Xtian said:

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.


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


Would you like RIP, ANSI or no graphic/color support, (R/A/N)? 


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:


Do you accept these stats? Y/N


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


What is your sex (M/F/N)?


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:



Currently:

Name:   Agreramond
Class:  Warrior
Race:   Troll
Gender: Male

Type Y to accept the above, or change:
(N)ame, (C)lass, (R)ace, (G)ender ...





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

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Xtian   (53 posts)  [Biography] bio
Date Reply #14 on Tue 10 Nov 2009 08:02 PM (UTC)
Message
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).
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


29,889 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]