XTERM 256 Color Codes

331 views
Skip to first unread message

Daniel

unread,
Apr 28, 2012, 3:10:05 PM4/28/12
to eve...@googlegroups.com
I just started playing around with Evennia a few days back. I'm not well-versed in Python, but have a background in C. I dabbled with NakedMud before this, which was written in C with Python scripting. I really like Python and decided that making my next MUD with Evennia would be a great way to learn it. So far, so good!
 
The documentation is superb and I'm very happy for that, so my first question is not too technical in nature. I noticed that XTERM256 compatibility is checked and immediately tried to display some color goodness. I threw the XTERM color codes that I know at it and got nothing.
 
E.g. "say {161Test." spits out "You say "{161Test.""
 
I glanced through the source again and saw that it should definitely be taking a 3 digit color code, but cannot figure out what these color codes should be. What am I doing wrong?
 
Thanks for the help.

Griatch Art

unread,
Apr 28, 2012, 6:37:44 PM4/28/12
to eve...@googlegroups.com

Hello and welcome to Evennia! Glad you like the documentation, that's an important bit for a tool like Evennia.

You are correct that {161 doesn't work. This is due to the fact that it is not a valid XTERM256 colour code. Each number in your xterm colour code can only be 0-5. Maybe you are used to a system where the range is 1-6 instead (it can't be 0-6 since that would give more than 256 colours)? Try e.g. {151 and you should get a more expected result (assuming your terminal and client supports XTERM256 of course - if it doesn't Evennia will convert your code to the closest of the normal 8 ANSI colours).

Hope that helps!
.
Griatch

Griatch Art

unread,
Apr 28, 2012, 6:58:10 PM4/28/12
to eve...@googlegroups.com
Follow-up:

Actually, when checking this, I realized that the current regex only accepts xterm256-values between 1-5, not 0-5 as it should have been. So at the moment you cannot reach the very darkest values in the colour cube. Oops. :-)

It's a trivial fix that I will push to main as soon as I finish up some other changes on my development machine. Thanks for asking, or we might not had noticed that one in a while! :-)
.
Griatch

Daniel

unread,
Apr 28, 2012, 8:51:30 PM4/28/12
to Evennia
That makes sense and I guess I was remembering something completely
different. As an aside, it appears that my client is not communicating
properly it's support of 256 colors. Time to switch.

Griatch Art

unread,
Apr 28, 2012, 11:09:45 PM4/28/12
to eve...@googlegroups.com
Which client is that? It could be that it does something not-quite standard during the TTYPE negotiation. Always good to hear examples which have issues.

Daniel

unread,
Apr 29, 2012, 2:42:57 AM4/29/12
to eve...@googlegroups.com
Both Mudlet and KildClient both should support the protocol, but don't seem to negotiate it properly. TinTin++, my old standby, does just fine though.

Griatch Art

unread,
Apr 29, 2012, 12:31:11 PM4/29/12
to eve...@googlegroups.com
Hi again,

KildClient doesn't seem to support TerminalType (TTYPE) negotiation. Hence there is no way for Evennia to know which client is connecting and whether it supports xterm256 (or other goodies) or not - hence Evennia won't send extended xterm symbols. Only assumption we do if TTYPE can't be established is that clients should support normal ANSI (one would think that's a safe bet these days ... but who knows). 

Mudlet (2.0-test4) on the other hand does respond to the TTYPE handshake - it replies that it is capable of TTYPE ... then simply refuses to reply when Evennia asks for such info.

As far as I know Evennia follows the TTYPE standard exactly, but I've contacted the Mudlet people to see if there is something we're missing. From posts in their forums, others clearly do use TTYPE successfully with mudlet after all. Evennia's implementation of TTYPE does work fine with tintin++, gnome-mud and others so maybe they  support it in a more lenient way or there is some competing standard around that noone told us about ... ;-)
.
Griatch
Reply all
Reply to author
Forward
0 new messages