<li><p><codeclass="docutils literal notranslate"><spanclass="pre">Xterm256</span></code> - 128 RGB colors, 32 greyscales. Not always supported in old clients.</p></li>
</ul>
<p>To see which colours your client support, use the default <codeclass="docutils literal notranslate"><spanclass="pre">color</span></code> command. This will list all
available colours for ANSI and Xterm256 along with the codes you use for them. The
central ansi/xterm256 parser is located in <aclass="reference internal"href="../api/evennia.utils.ansi.html#evennia-utils-ansi"><spanclass="std std-ref">evennia/utils/ansi.py</span></a>.</p>
<p>Evennia supports the <codeclass="docutils literal notranslate"><spanclass="pre">ANSI</span></code> standard for text. This is by far the most supported MUD-color standard, available in all but the most ancient mud clients.</p>
<p>Note: The ANSI standard does not actually support bright backgrounds like <codeclass="docutils literal notranslate"><spanclass="pre">|[r</span></code> - the standard
only supports “normal” intensity backgrounds. To get around this Evennia implements these as <aclass="reference internal"href="#xterm256-colours"><spanclass="std std-doc">Xterm256 colours</span></a> behind the scenes. If the client does not support
Xterm256 the ANSI colors will be used instead and there will be no visible difference between using upper- and lower-case background tags.</p>
<p>If you want to display an ANSI marker as output text (without having any effect), you need to escape it by preceding its <codeclass="docutils literal notranslate"><spanclass="pre">|</span></code> with another <codeclass="docutils literal notranslate"><spanclass="pre">|</span></code>:</p>
<p>This will output the raw <codeclass="docutils literal notranslate"><spanclass="pre">|r</span></code> without any color change. This can also be necessary if you are doing
ansi art that uses <codeclass="docutils literal notranslate"><spanclass="pre">|</span></code> with a letter directly following it.</p>
<p>to get a list of all supported ANSI colours and the tags used to produce them.</p>
<p>A few additional ANSI codes are supported:</p>
<sectionid="caveats-of">
<h3>Caveats of <codeclass="docutils literal notranslate"><spanclass="pre">|*</span></code><aclass="headerlink"href="#caveats-of"title="Permalink to this headline">¶</a></h3>
<p>The <codeclass="docutils literal notranslate"><spanclass="pre">|*</span></code> tag (inverse video) is an old ANSI standard and should usually not be used for more than to
mark short snippets of text. If combined with other tags it comes with a series of potentially
confusing behaviors:</p>
<ul>
<li><p>The <codeclass="docutils literal notranslate"><spanclass="pre">|*</span></code> tag will only work once in a row:, ie: after using it once it won’t have an effect again
until you declare another tag. This is an example:</p>
<p>that is, it will not reverse to normal at the second <codeclass="docutils literal notranslate"><spanclass="pre">|*</span></code>. You need to reset it manually:</p>
<p>So <codeclass="docutils literal notranslate"><spanclass="pre">|*</span></code> only considers the ‘true’ foreground color, ignoring any highlighting. Think of the bright
state (<codeclass="docutils literal notranslate"><spanclass="pre">|h</span></code>) as something like like <codeclass="docutils literal notranslate"><spanclass="pre"><strong></span></code> in HTML: it modifies the <em>appearance</em> of a normal
foreground color to match its bright counterpart, without changing its normal color.</p>
<ul>
<li><p>Finally, after a <codeclass="docutils literal notranslate"><spanclass="pre">|*</span></code>, if the previous background was set to a dark color (via <codeclass="docutils literal notranslate"><spanclass="pre">|[</span></code>), <codeclass="docutils literal notranslate"><spanclass="pre">|!#</span></code>) will
actually change the background color instead of the foreground:</p>
<divclass="highlight-default notranslate"><divclass="highlight"><pre><span></span>|*reversed text |!R now BG is red.
</pre></div>
</div>
</li>
</ul>
<p>For a detailed explanation of these caveats, see the [Understanding Color Tags](Understanding-Color-
Tags) tutorial. But most of the time you might be better off to simply avoid <codeclass="docutils literal notranslate"><spanclass="pre">|*</span></code> and mark your text
<h2>Xterm256 Colours<aclass="headerlink"href="#xterm256-colours"title="Permalink to this headline">¶</a></h2>
<asideclass="sidebar">
<p>See the <aclass="reference internal"href="../Howtos/Tutorial-Understanding-Color-Tags.html"><spanclass="doc std std-doc">Understanding Color Tags</span></a> tutorial, for more on the use of ANSI color tags and the pitfalls of mixing ANSI and Xterms256 color tags in the same context.</p>
<p>The <em>Xterm256</em> standard is a colour scheme that supports 256 colours for text and/or background. It can be combined freely with ANSI colors (above), but some ANSI tags don’t affect Xterm256 tags.</p>
<p>While this offers many more possibilities than traditional ANSI colours, be wary that too many text
<td><p>foreground RGB (red/green/blue), each from 0 to 5.</p></td>
</tr>
<trclass="row-odd"><td><p>|[###</p></td>
<td><p>background RGB</p></td>
</tr>
<trclass="row-even"><td><p>|=#</p></td>
<td><p>a-z foreground greyscale, where <codeclass="docutils literal notranslate"><spanclass="pre">a</span></code> is black and <codeclass="docutils literal notranslate"><spanclass="pre">z</span></code> is white.</p></td>
into a few blocks of colors, it means Xterm256 is not supported and ANSI are used as a replacement. You can use the <codeclass="docutils literal notranslate"><spanclass="pre">options</span></code> command to see if xterm256 is active for you. This depends on if your client told Evennia what it supports - if not, and you know what your client supports, you may have to activate some features manually.</p>
