---
title: "Blocking Bad Nicknames and Ads in Player Names"
excerpt: "Stop clan-tag ads, empty names and slurs in player nicks: how CS 1.6 handles name changes, what the engine can filter, and an AMXX name-filter approach that renames offenders."
category: "administration"
tags: "names, moderation"
image: ""
read_time: "8 min read"
---
<p>Player names are the one piece of text every visitor controls, and on a public server a fraction of them will abuse it: a website advert as a clan tag, a slur, a name that impersonates an admin, or an empty/blank nick that breaks kill feeds. The engine gives you almost nothing here, so name moderation is an AMX Mod X job. This covers what the engine does at connect, what a name filter can enforce, and how to apply it without breaking legitimate name changes.</p>
<h2>1. Understand when a name is set</h2>
<p>A client's name is the <code>name</code> setinfo value. It is sent at connect and can be changed at any time in-game via the console (<code>name "whatever"</code>) or the options menu. That means a filter cannot be a one-time check at join — a player can connect with a clean name and switch to <code>www.rival-server.com</code> ten seconds later. Any real solution has to react to name <em>changes</em>, not just connects.</p>
<h2>2. What the engine and mp_ cvars can do (not much)</h2>
<p>Stock CS has no name blacklist. The engine will reject a name that is entirely empty by substituting a default, and it collapses some characters, but there is no cvar to ban a word or a URL from a nick. Do not go looking for an <code>mp_</code> cvar for this — it does not exist. This is squarely a plugin problem, which is why every serious public server runs a name filter.</p>
<h2>3. How an AMXX name filter works</h2>
<p>A name-filter plugin hooks the moment a name is set and validates it, using the <code>client_infochanged</code> forward (fired whenever any setinfo, including <code>name</code>, changes) and the <code>namecheck</code>/<code>SetClientKeyValue</code> mechanics to inspect and, if needed, overwrite the new name. The logic is:</p>
<ol>
<li>Read the proposed new name from the client's info buffer.</li>
<li>Compare it against a blacklist (substrings, or a regex for URLs) and against structural rules (min length, no all-whitespace, character set).</li>
<li>If it violates a rule, reject it — either revert to the previous name or force a neutral placeholder like <code>Player</code>, and optionally warn the client.</li>
</ol>
<p>Blocking a URL pattern such as <code>.com</code>, <code>.net</code>, <code>www.</code> and <code>http</code> catches the overwhelming majority of name adverts. A short slur list handles the rest. Our <a href="/plugins/csb-name-filter">CSB Name Filter</a> implements exactly this — a configurable blacklist plus URL and empty-name rules that rename offenders on the spot.</p>
<h2>4. Set sensible rules</h2>
<p>Filters that are too aggressive punish normal players. Reasonable defaults:</p>
<ul>
<li><strong>Block URLs</strong> — <code>www.</code>, <code>http</code>, and common TLDs in a name are almost always ads. This is the single highest-value rule.</li>
<li><strong>Reject empty / whitespace-only names</strong> — force a placeholder. Blank names break the kill feed and votes.</li>
<li><strong>Minimum length</strong> — one or two characters is usually a troll or an evasion; require at least three.</li>
<li><strong>Impersonation</strong> — block names containing <code>ADMIN</code>, your server name, or an owner's handle, so nobody masquerades as staff.</li>
<li><strong>Slur list</strong> — keep it short and specific; long word lists cause false positives on innocent substrings (the classic \"Scunthorpe\" problem).</li>
</ul>
<p>Log every rename so you can tune the list and catch a rule that fires too often.</p>
<h2>5. Handle the rename gracefully</h2>
<p>When you reject a name, tell the player why and give them a clean fallback rather than silently reverting in a loop — a client whose name is rejected can get stuck re-sending it. Print a one-line chat message (\"Names with website addresses are not allowed\") and set them to a neutral placeholder. Pair the filter with an <a href="/plugins/csb-adverts">adverts plugin</a> that states the naming rule occasionally, so it feels like a policy rather than a random kick.</p>
<h2>Common errors</h2>
<ul>
<li><strong>Filter only checks at connect, ads slip in later</strong> — it hooks connect instead of <code>client_infochanged</code>. A name changed in-game must be re-validated.</li>
<li><strong>Legitimate names get rejected</strong> — an over-broad blacklist (a TLD substring matching inside a normal word, or a slur substring inside an innocent one). Match on word boundaries or full tokens, not bare substrings.</li>
<li><strong>Name-change loop</strong> — the plugin reverts to the same rejected value the client keeps resending. Force a fixed placeholder instead of bouncing between two names.</li>
<li><strong>Unicode/colored names bypass the filter</strong> — the offender uses lookalike characters. Normalize the string before matching, or block non-ASCII if your community does not need it.</li>
<li><strong>Admins caught by the impersonation rule</strong> — exempt authenticated admins from the <code>ADMIN</code> block by checking their flags before filtering.</li>
</ul>
<h2>Verification</h2>
<p>Test each rule from a client console. Try to set a forbidden name and confirm the plugin corrects it:</p>
<pre>name "www.some-ad.com" // should be rejected / renamed
name "" // should become a placeholder
name "x" // should fail the minimum-length rule</pre>
<p>Watch the server console or AMXX log for the rename entries. Then set a perfectly normal name and confirm it is accepted unchanged — a filter that blocks ads but also blocks <code>Steve</code> is worse than no filter. Once it behaves, add the naming rule to your <a href="/tutorials/motd-txt-html-guide">MOTD</a> so players know before they are corrected.</p>
