Add 6 tutorials (6 files)
Browse Source
Daemon666 committed
parent f4018604f4
commit d64263085d67d2e60ef7abda421fabe3ca2d457f
6 changed files
with 323 additions and 0 deletions
A
amx-slap-slay-kick/en.md
+52 -0
A
cron-restart-cs16-server/en.md
+74 -0
A
cs16-crashes-on-startup/en.md
+56 -0
A
prevent-admin-abuse/en.md
+74 -0
A
steam-vs-nonsteam-servers/en.md
+54 -0
A
update-plugins-live-server/en.md
+13 -0
amx-slap-slay-kick/en.md
A
| @@ -0,0 +1,52 @@ | ||
| 1 | +--- | |
| 2 | +title: "amx_slap, amx_slay and amx_kick: Moderation Basics" | |
| 3 | +excerpt: "The three everyday AMX Mod X moderation commands, how to target players by name, userid or team, the access flags each needs, and how immunity affects them." | |
| 4 | +category: "administration" | |
| 5 | +tags: "moderation, admin" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Most in-game moderation on a CS 1.6 server is done with three AMX Mod X commands: <code>amx_slap</code> to nudge or hurt a player, <code>amx_slay</code> to kill them, and <code>amx_kick</code> to remove them. They are the lightest tools in the box — proportionate responses to a player who is being annoying rather than one who needs banning — and knowing how to target them precisely is what separates confident moderation from flailing.</p> | |
| 10 | + | |
| 11 | +<h2>1. amx_slap: a warning with teeth</h2> | |
| 12 | +<p><code>amx_slap</code> throws the target a short distance and optionally deals damage:</p> | |
| 13 | +<pre>amx_slap <target> [damage] | |
| 14 | +amx_slap Camper 0 // slap with no damage — a pure nudge/warning | |
| 15 | +amx_slap Camper 10 // slap and take 10 HP</pre> | |
| 16 | +<p>A zero-damage slap is the classic "knock it off" signal — it moves the player and plays the slap sound without risking a kill. Non-zero damage that exceeds the player's HP will kill them, so keep the number small if you only mean to warn.</p> | |
| 17 | + | |
| 18 | +<h2>2. amx_slay: end their round</h2> | |
| 19 | +<p><code>amx_slay</code> kills the target outright — useful for a player stuck in a wall, exploiting, or ignoring repeated slaps:</p> | |
| 20 | +<pre>amx_slay <target> | |
| 21 | +amx_slay Exploiter</pre> | |
| 22 | +<p>It only affects the current round; they respawn next round as normal. It is the right escalation from a slap when a player is actively abusing something and a warning has not landed.</p> | |
| 23 | + | |
| 24 | +<h2>3. amx_kick: send them to reconnect</h2> | |
| 25 | +<p><code>amx_kick</code> disconnects the player, with an optional reason shown to them:</p> | |
| 26 | +<pre>amx_kick <target> [reason] | |
| 27 | +amx_kick Griefer "stop team-flashing"</pre> | |
| 28 | +<p>A kick is not a ban — nothing stops them reconnecting immediately. Use it to break up a situation or force a config reload, and step up to <a href="/tutorials/amx-ban-commands">a ban</a> when they should not come back at all.</p> | |
| 29 | + | |
| 30 | +<h2>4. Targeting: names, userids and teams</h2> | |
| 31 | +<p>All three commands share AMXX's target syntax, and using it well avoids hitting the wrong person:</p> | |
| 32 | +<ul> | |
| 33 | +<li><strong>Name fragment</strong> — <code>amx_slap Camp</code> matches a player whose name contains "Camp". The match is case-insensitive and partial. If it is ambiguous, AMXX lists the matches instead of guessing, so you can re-run with more of the name.</li> | |
| 34 | +<li><strong>#userid</strong> — the unambiguous way. Get the userid from <a href="/tutorials/amx-who-and-status">amx_who or status</a>, then target it with a hash: <code>amx_slay #12</code>. The userid is stable for the length of that player's connection, so it will not drift the way a partial name can.</li> | |
| 35 | +<li><strong>Team and state tokens</strong> — many builds accept <code>@CT</code>, <code>@T</code>, <code>@ALL</code>, <code>@ALIVE</code> and <code>@DEAD</code>. For example <code>amx_slay @T</code> slays the whole Terrorist team, and <code>amx_slap @ALL 0</code> nudges everyone at once. Use these carefully; they hit everyone that matches, so a mistaken <code>@ALL</code> with damage can wipe the server.</li> | |
| 36 | +</ul> | |
| 37 | +<p>When two players have similar names — a real problem on non-Steam servers where impersonation is common — always fall back to <code>#userid</code>. It is the only target that cannot match the wrong person, and getting into the habit early saves you from the embarrassment of slaying an innocent player who happened to share three letters with the offender.</p> | |
| 38 | + | |
| 39 | +<h2>5. Access flags and immunity</h2> | |
| 40 | +<p>Each command is gated by an access flag in <a href="/tutorials/users-ini-explained">users.ini</a>: slap and slay require the slay flag (<code>e</code>), kick requires the kick flag (<code>c</code>). An admin missing the flag gets an access-denied message. All three also honour <a href="/tutorials/admin-immunity-setup">immunity</a> — a player with the immunity flag cannot be slapped, slayed or kicked by another admin, which is exactly why immunity should be handed out sparingly. For the full letter-to-power mapping, keep the <a href="/tutorials/amxx-admin-flags-reference">flags reference</a> open.</p> | |
| 41 | + | |
| 42 | +<h2>Common errors</h2> | |
| 43 | +<ul> | |
| 44 | +<li><strong>"That was not a valid target" or multiple matches listed</strong> — your name fragment is ambiguous or matches nobody. Use <code>#userid</code> from <code>amx_who</code>.</li> | |
| 45 | +<li><strong>A slap kills the player</strong> — the damage value exceeded their remaining HP. Use <code>0</code> for a warning slap.</li> | |
| 46 | +<li><strong>Access denied</strong> — the admin lacks the slay (<code>e</code>) or kick (<code>c</code>) flag. Grant it in <code>users.ini</code>.</li> | |
| 47 | +<li><strong>Command silently does nothing to one player</strong> — that player has immunity. Remove their immunity flag or accept they are protected.</li> | |
| 48 | +<li><strong>Kicked player rejoins instantly</strong> — that is what a kick does; it is not a ban. Ban them if they should stay out.</li> | |
| 49 | +</ul> | |
| 50 | + | |
| 51 | +<h2>Verification</h2> | |
| 52 | +<p>On a test server, slap yourself with <code>amx_slap YourName 0</code> and confirm the nudge and sound. Slay yourself and confirm you die and respawn next round. For kick, target a second test client by <code>#userid</code> and confirm they disconnect with your reason shown. Check that <code>amx_show_activity</code> in <a href="/tutorials/amxx-cfg-explained">amxx.cfg</a> reports the action to players the way you expect. If you prefer clicking to typing, the same three actions are one keypress away in the <a href="/plugins/csb-punish-menu">punish menu</a> and the built-in <a href="/tutorials/amxmodmenu-guide">amxmodmenu</a>.</p> |
cron-restart-cs16-server/en.md
A
| @@ -0,0 +1,74 @@ | ||
| 1 | +--- | |
| 2 | +title: "Auto-Restarting Your CS 1.6 Server with cron" | |
| 3 | +excerpt: "A scheduled nightly restart for CS 1.6: why a clean bounce helps, how to do it safely with a screen/systemd-aware script, and how to avoid restarting on top of a full server." | |
| 4 | +category: "administration" | |
| 5 | +tags: "cron, uptime" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A scheduled restart is different from crash recovery. Crash recovery (<a href="/tutorials/auto-restart-on-crash">covered here</a>) brings a dead server back; a cron restart deliberately bounces a <em>healthy</em> server on a schedule to clear slow memory growth, re-read configs cleanly, and reset any plugin that leaks over days of uptime. Long-running GoldSrc servers do drift — edicts, memory, the occasional stuck plugin — and a nightly restart at a dead hour keeps things fresh. The trick is doing it without yanking players out mid-round.</p> | |
| 10 | + | |
| 11 | +<h2>1. Decide what \"restart\" means for your setup</h2> | |
| 12 | +<p>How you restart depends on how you run the server:</p> | |
| 13 | +<ul> | |
| 14 | +<li><strong>systemd unit</strong> — the clean case. <code>systemctl restart cs16</code> does everything. This is the recommended supervisor; see <a href="/tutorials/auto-restart-on-crash">the auto-restart guide</a>.</li> | |
| 15 | +<li><strong>screen/tmux loop</strong> — you kill the engine and let the wrapper loop restart it.</li> | |
| 16 | +<li><strong>bare hlds_run</strong> — you should not be running it this way for scheduled restarts; wrap it first.</li> | |
| 17 | +</ul> | |
| 18 | +<p>The examples below assume systemd, with a screen alternative noted.</p> | |
| 19 | + | |
| 20 | +<h2>2. The simplest cron restart</h2> | |
| 21 | +<p>For a systemd-managed server, a nightly restart is one crontab line. Edit root's crontab (systemctl needs privilege) or use a sudoers rule for the game user:</p> | |
| 22 | +<pre>crontab -e</pre> | |
| 23 | +<pre># min hour dom mon dow command | |
| 24 | +0 6 * * * systemctl restart cs16</pre> | |
| 25 | +<p>That bounces the server every day at 06:00. Pick an hour when nobody is on — check your own player-count graph rather than guessing. For a screen loop instead, the job kills the engine and the loop restarts it:</p> | |
| 26 | +<pre>0 6 * * * pkill -f hlds_linux</pre> | |
| 27 | + | |
| 28 | +<h2>3. Warn players before you pull the plug</h2> | |
| 29 | +<p>Restarting on top of a full server is rude and loses regulars. If people might be on at your restart hour, announce it first via RCON, then restart a minute later. A tiny wrapper script:</p> | |
| 30 | +<pre>#!/bin/bash | |
| 31 | +# scheduled-restart.sh | |
| 32 | +RCON() { /home/steam/tools/rcon "$1"; } # your rcon helper | |
| 33 | +RCON 'say [SERVER] Scheduled restart in 60 seconds...' | |
| 34 | +sleep 30 | |
| 35 | +RCON 'say [SERVER] Restart in 30 seconds - reconnect after.' | |
| 36 | +sleep 30 | |
| 37 | +systemctl restart cs16</pre> | |
| 38 | +<pre># crontab | |
| 39 | +0 6 * * * /home/steam/tools/scheduled-restart.sh</pre> | |
| 40 | +<p>Even better, gate it on emptiness so you never interrupt a live game.</p> | |
| 41 | + | |
| 42 | +<h2>4. Only restart when the server is empty</h2> | |
| 43 | +<p>The considerate pattern is a restart <em>window</em> rather than a fixed instant: check the player count every few minutes during the small hours and restart the first time it is zero. Query the player count (via an RCON <code>status</code> parse, a stats query, or an AMXX-exposed metric) and act on it:</p> | |
| 44 | +<pre>#!/bin/bash | |
| 45 | +# restart-if-empty.sh -- run every 5 min from 04:00-06:00 | |
| 46 | +PLAYERS=$(/home/steam/tools/rcon 'status' | grep -c '^# ') | |
| 47 | +STAMP=/tmp/cs-restarted-today | |
| 48 | +if [ "$PLAYERS" -eq 0 ] && [ ! -f "$STAMP" ]; then | |
| 49 | + systemctl restart cs16 | |
| 50 | + touch "$STAMP" | |
| 51 | +fi</pre> | |
| 52 | +<pre># crontab -- every 5 min in the quiet window, plus a daily flag reset | |
| 53 | +*/5 4-6 * * * /home/steam/tools/restart-if-empty.sh | |
| 54 | +0 7 * * * rm -f /tmp/cs-restarted-today</pre> | |
| 55 | +<p>The stamp file ensures you restart at most once per night even though the check runs many times. If the server never empties, it simply is not restarted that day — which is usually the right call for a popular server.</p> | |
| 56 | + | |
| 57 | +<h2>5. Make sure configs actually reload</h2> | |
| 58 | +<p>A restart is only useful if the fresh process reads your current configs. Confirm <code>server.cfg</code> executes on startup (a surprising number of servers have a broken exec chain — see <a href="/tutorials/fix-server-cfg-not-executing">why server.cfg is not executing</a>) and that your first map applies the settings you expect. A nightly restart that reloads a stale or broken config just spreads the problem.</p> | |
| 59 | + | |
| 60 | +<h2>Common errors</h2> | |
| 61 | +<ul> | |
| 62 | +<li><strong>Cron job does nothing</strong> — <code>systemctl</code> needs privilege the crontab user lacks. Put the job in root's crontab or grant a specific sudoers rule.</li> | |
| 63 | +<li><strong>Server restarts mid-match</strong> — a fixed-time restart landed on a full server. Switch to the empty-check window, and always warn via RCON.</li> | |
| 64 | +<li><strong>Restarts several times in the window</strong> — missing the once-per-night stamp file, so every empty check fires. Add the flag and reset it daily.</li> | |
| 65 | +<li><strong>screen restart leaves no server</strong> — you killed the engine but there was no wrapper loop to bring it back. Verify the loop or use systemd.</li> | |
| 66 | +<li><strong>Time zone surprise</strong> — cron runs in the server's local time, not your players'. Set the box time zone or offset the schedule to your audience's quiet hours.</li> | |
| 67 | +</ul> | |
| 68 | + | |
| 69 | +<h2>Verification</h2> | |
| 70 | +<p>Test the script by hand before trusting cron, and confirm the server comes back:</p> | |
| 71 | +<pre>/home/steam/tools/scheduled-restart.sh | |
| 72 | +systemctl status cs16 # active (running), fresh uptime | |
| 73 | +journalctl -u cs16 -n 20 # startup log, server.cfg executed</pre> | |
| 74 | +<p>Watch the console for your <code>hostname</code> and cvar echoes to confirm the config reloaded. Let one real scheduled run happen overnight and check the next morning that uptime reset once, not five times. Pair this with a working <a href="/tutorials/auto-restart-on-crash">crash supervisor</a> and a <a href="/tutorials/backup-configs-bans-stats">backup routine</a> for a server that looks after itself.</p> |
cs16-crashes-on-startup/en.md
A
| @@ -0,0 +1,56 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: CS 1.6 Crashes on Startup from Steam" | |
| 3 | +excerpt: "CS 1.6 closing instantly or crashing to desktop on launch — verify files, reset the video mode, clear bad launch options and custom content, and the Anniversary rollback." | |
| 4 | +category: "client" | |
| 5 | +tags: "crash, steam" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You click Play, the window flickers, and you are back on the desktop — or the game hangs on a black screen and dies. A startup crash in CS 1.6 is almost always one of a short list of causes: a corrupt file, a bad video mode, a broken launch option, incompatible custom content, or the fallout from the 2023 Anniversary update. Work through these in order; the first two fix the large majority.</p> | |
| 10 | + | |
| 11 | +<h2>1. Verify the game files</h2> | |
| 12 | +<p>Start here every time. In Steam, right-click <strong>Counter-Strike → Properties → Installed Files → Verify integrity of game files</strong>. This re-downloads anything corrupt, including the WADs and DLLs whose damage causes instant crashes. It is the same first move as fixing a <a href="/tutorials/cs16-cannot-find-wad">missing WAD error</a>, and it resolves a surprising share of launch crashes on its own.</p> | |
| 13 | + | |
| 14 | +<h2>2. Reset a bad video mode</h2> | |
| 15 | +<p>A resolution or renderer the game cannot initialise makes it die on launch. Force it into a safe mode with launch options: right-click the game, <strong>Properties → General → Launch Options</strong>, and set:</p> | |
| 16 | +<pre>-window -w 640 -h 480</pre> | |
| 17 | +<p>If it launches windowed at 640×480, the crash was the video mode — now set a resolution your monitor supports and go back to fullscreen. You can also pick the renderer explicitly:</p> | |
| 18 | +<pre>-gl // OpenGL (default, usually best) | |
| 19 | +-d3d // Direct3D | |
| 20 | +-soft // software renderer, last resort for GPU issues</pre> | |
| 21 | +<p>Try <code>-gl</code> first; if the GPU driver is the problem, <code>-soft</code> will at least get you to the menu to change settings.</p> | |
| 22 | + | |
| 23 | +<h2>3. Strip your launch options back</h2> | |
| 24 | +<p>A single bad launch option crashes the game before it draws a frame. Clear the box entirely, launch, and add options back one at a time. Options that are commonly mistyped or unsupported on a given system:</p> | |
| 25 | +<pre>-freq 144 // must match a real refresh rate your monitor offers | |
| 26 | +-noforcemparms | |
| 27 | +-console</pre> | |
| 28 | +<p>If clearing the box fixes it, add these back individually until you find the offender rather than pasting a giant string from a forum.</p> | |
| 29 | + | |
| 30 | +<h2>4. Remove custom content and the config</h2> | |
| 31 | +<p>A broken skin, a corrupt <code>autoexec.cfg</code>, or a leftover cheat DLL can crash the game on load. Two safe resets:</p> | |
| 32 | +<ul> | |
| 33 | +<li>Temporarily rename anything you added under <code>cstrike/</code> — custom models, sprites, <code>autoexec.cfg</code> — and launch clean.</li> | |
| 34 | +<li>Delete a stray <code>opengl32.dll</code> from the game folder. A file by that name in the Half-Life directory is a cheat loader, not a system file, and it frequently crashes the game after an update.</li> | |
| 35 | +</ul> | |
| 36 | +<p>If a clean profile launches, add your content back a piece at a time to find the bad file. A single oversized model or a truncated sound file is enough to crash the loader, and reintroducing content one folder at a time is the only sure way to identify which one.</p> | |
| 37 | + | |
| 38 | +<h2>5. Update or roll back your graphics driver</h2> | |
| 39 | +<p>A game this old occasionally clashes with a brand-new GPU driver, and just as often is fixed by a fresh one. If the crash is a black-screen-then-death and switching renderers with <code>-gl</code> / <code>-d3d</code> / <code>-soft</code> changes the behaviour, the driver is implicated. Update to the current stable driver for your card; if the crash <em>started</em> right after a driver update, roll back to the previous version. The software renderer (<code>-soft</code>) sidesteps the GPU path entirely and is a useful way to confirm the driver is the culprit before you spend time reinstalling it.</p> | |
| 40 | + | |
| 41 | +<h2>6. Roll back to the Anniversary legacy branch</h2> | |
| 42 | +<p>The 25th Anniversary update (2023) broke many older setups. If the crash started around then and nothing above helps, opt into the pre-update build: <strong>Properties → Betas</strong> and select <code>steam_legacy</code> from the dropdown. Let it download, then launch. This is also the branch that resolves the client-side <a href="/tutorials/cs16-connection-failed-retries-client">connection failures</a> some players hit after the update. Switch back to None later to return to the current build.</p> | |
| 43 | + | |
| 44 | +<h2>Common errors</h2> | |
| 45 | +<ul> | |
| 46 | +<li><strong>Instant crash to desktop, no window</strong> — corrupt files or a bad launch option. Verify files, then clear launch options.</li> | |
| 47 | +<li><strong>Black screen then crash</strong> — video mode or renderer. Use <code>-window -w 640 -h 480</code>, then switch renderer with <code>-gl</code> / <code>-d3d</code> / <code>-soft</code>.</li> | |
| 48 | +<li><strong>Crashes only after you added a skin/model</strong> — bad custom content. Rename your added files under <code>cstrike/</code> and reintroduce them one at a time.</li> | |
| 49 | +<li><strong>Started crashing after a Steam update</strong> — Anniversary incompatibility. Switch to the <code>steam_legacy</code> beta.</li> | |
| 50 | +<li><strong>Crashes with a stray <code>opengl32.dll</code> present</strong> — that is a cheat loader; delete it and verify files.</li> | |
| 51 | +</ul> | |
| 52 | + | |
| 53 | +<h2>Verification</h2> | |
| 54 | +<p>After each change, launch to the main menu — reaching the menu means the client itself is healthy. Prove the game runs end to end by hosting a quick offline map:</p> | |
| 55 | +<pre>map de_dust2</pre> | |
| 56 | +<p>If a local map loads and plays, the install is sound and any remaining trouble is about reaching servers, not launching. Once you know which step fixed it, undo the temporary safety options (drop <code>-window -w 640 -h 480</code>) and restore your real resolution so you are not stuck in a tiny window.</p> |
prevent-admin-abuse/en.md
A
| @@ -0,0 +1,74 @@ | ||
| 1 | +--- | |
| 2 | +title: "Preventing Admin Abuse (Logging and Limited Flags)" | |
| 3 | +excerpt: "Give admins only the flags their role needs, keep activity visible, and log every admin command so you can answer accusations instead of guessing." | |
| 4 | +category: "administration" | |
| 5 | +tags: "admin, moderation" | |
| 6 | +image: "" | |
| 7 | +read_time: "9 min read" | |
| 8 | +--- | |
| 9 | +<p>The fastest way to kill a community is a power-tripping admin, and the second fastest is having no way to prove they didn't. AMX Mod X gives you granular access flags precisely so you can hand out limited power, plus activity visibility and logging so nothing happens in the dark. This shows how to build tiered admin roles and keep an audit trail.</p> | |
| 10 | + | |
| 11 | +<h2>1. Understand the access flags</h2> | |
| 12 | +<p>An admin's power is a string of flags in <code>addons/amxmodx/configs/users.ini</code>. Each letter grants one capability:</p> | |
| 13 | +<table> | |
| 14 | +<thead><tr><th>Flag</th><th>Grants</th></tr></thead> | |
| 15 | +<tbody> | |
| 16 | +<tr><td><code>a</code></td><td>Immunity (cannot be kicked/banned by others)</td></tr> | |
| 17 | +<tr><td><code>b</code></td><td>Reservation (reserved slot access)</td></tr> | |
| 18 | +<tr><td><code>c</code></td><td>amx_kick</td></tr> | |
| 19 | +<tr><td><code>d</code></td><td>amx_ban / amx_unban</td></tr> | |
| 20 | +<tr><td><code>e</code></td><td>amx_slay / amx_slap</td></tr> | |
| 21 | +<tr><td><code>f</code></td><td>amx_map (change map)</td></tr> | |
| 22 | +<tr><td><code>g</code></td><td>amx_cvar (change cvars)</td></tr> | |
| 23 | +<tr><td><code>h</code></td><td>amx_cfg (exec configs)</td></tr> | |
| 24 | +<tr><td><code>i</code></td><td>amx_chat / admin chat</td></tr> | |
| 25 | +<tr><td><code>j</code></td><td>amx_vote</td></tr> | |
| 26 | +<tr><td><code>l</code></td><td>amx_rcon (run RCON commands)</td></tr> | |
| 27 | +<tr><td><code>u</code></td><td>Menu access</td></tr> | |
| 28 | +</tbody> | |
| 29 | +</table> | |
| 30 | +<p>The lazy move is to give everyone <code>abcdefghijklmnopqrstu</code> — full admin. That is exactly how a trusted regular ends up able to <code>amx_rcon</code> your <code>rcon_password</code> out of the server. Grant roles instead.</p> | |
| 31 | + | |
| 32 | +<h2>2. Build tiered roles</h2> | |
| 33 | +<p>The <code>users.ini</code> line format is <code><authid or name> <password> <access flags> <account flags></code>. Account flag <code>c</code> means the first field is a SteamID; <code>d</code> means an IP; <code>e</code> means name-only with no password. A sensible three-tier setup:</p> | |
| 34 | +<pre>; Moderator: kick, slay/slap, chat, menu — no ban, no cvar, no rcon | |
| 35 | +"STEAM_0:1:1001" "" "ceiu" "ce" | |
| 36 | + | |
| 37 | +; Admin: adds ban and map control, still no rcon/cvar | |
| 38 | +"STEAM_0:1:1002" "" "abcdefiju" "ce" | |
| 39 | + | |
| 40 | +; Owner: everything, including rcon | |
| 41 | +"STEAM_0:1:1003" "" "abcdefghijlu" "ce"</pre> | |
| 42 | +<p>Note the deliberate omissions: moderators get no <code>d</code> (ban), no <code>g</code> (cvar), no <code>l</code> (rcon). Reserve <code>l</code> for people you would trust with the server password, because that is effectively what it is.</p> | |
| 43 | + | |
| 44 | +<h2>3. Keep admin actions visible</h2> | |
| 45 | +<p>Hidden admin actions breed accusations you cannot answer, so announce them:</p> | |
| 46 | +<pre>amx_show_activity 2</pre> | |
| 47 | +<p>At <code>2</code>, players see both the action and the admin's name. This is covered in full in the <a href="/tutorials/amxx-cfg-explained">amxx.cfg guide</a>; the point here is that transparency is itself an abuse deterrent — an admin who knows the whole server sees their name on every slap behaves better.</p> | |
| 48 | + | |
| 49 | +<h2>4. Log every command</h2> | |
| 50 | +<p>AMXX writes admin commands to its logs under <code>addons/amxmodx/logs/</code> and to the game logs. Make sure logging is on (<code>amx_logging 1</code> in amxx.cfg, <code>log on</code> in server.cfg), then audit periodically:</p> | |
| 51 | +<pre>grep -iE 'amx_(ban|kick|slay|slap|map|cvar)' cstrike/logs/*.log</pre> | |
| 52 | +<p>This is the record you produce when someone claims they were banned for no reason. The full technique is in <a href="/tutorials/parse-cs16-server-logs">parsing server logs</a> — grep by the admin's SteamID to see everything they have done.</p> | |
| 53 | + | |
| 54 | +<h2>5. Protect the escalation paths</h2> | |
| 55 | +<ul> | |
| 56 | +<li><strong>Immunity is not a toy</strong> — flag <code>a</code> means no one else can act on that admin. Give it only where it is needed, or a rogue admin becomes untouchable.</li> | |
| 57 | +<li><strong>Never grant <code>g</code> (cvar) or <code>l</code> (rcon) casually</strong> — with <code>amx_cvar</code> an admin can change <code>sv_cheats</code>, rates, or gravity; with rcon they own the box.</li> | |
| 58 | +<li><strong>Prefer SteamID auth (<code>c</code>)</strong> over name-only (<code>e</code>) — name-only admin is trivially impersonated by anyone who copies the nickname.</li> | |
| 59 | +</ul> | |
| 60 | +<p>A useful mental model: treat flags the way you would treat filesystem permissions. Nobody runs as root for daily work, and nobody should hold <code>l</code> (rcon) or <code>a</code> (immunity) just because they are "senior." Start every new admin at the moderator tier, and promote only when a concrete need appears and the person has earned trust. Demotion should be just as routine — pull a flag the moment a role changes, and reload admins so the change is live immediately rather than at the next map.</p> | |
| 61 | + | |
| 62 | +<h2>Troubleshooting</h2> | |
| 63 | +<ul> | |
| 64 | +<li><strong>An admin can do more than intended</strong> — too many flags, or they inherited access from <code>amx_default_access</code> in <a href="/tutorials/amxx-cfg-explained">amxx.cfg</a> (which must stay empty). Trim the flag string.</li> | |
| 65 | +<li><strong>Everyone has admin</strong> — a flag was left in <code>amx_default_access</code>. Set it back to <code>""</code>.</li> | |
| 66 | +<li><strong>Admin cannot authenticate</strong> — account flag mismatch: <code>c</code> for SteamID vs <code>e</code> for name-only, or a password field that does not match their <code>setinfo</code>.</li> | |
| 67 | +<li><strong>No audit trail</strong> — <code>amx_logging 0</code> or <code>log off</code>. Turn both on; without them you cannot prove anything.</li> | |
| 68 | +<li><strong>Cannot act on a misbehaving admin</strong> — they hold immunity (<code>a</code>). Remove it from <code>users.ini</code> and reload admins.</li> | |
| 69 | +</ul> | |
| 70 | + | |
| 71 | +<h2>Verification</h2> | |
| 72 | +<p>Reload the admin list and confirm the flags took:</p> | |
| 73 | +<pre>amx_reloadadmins</pre> | |
| 74 | +<p>Log in as the moderator account and confirm <code>amx_ban</code> is refused (<code>You have no access to that command</code>) while <code>amx_kick</code> works. Perform a slap and confirm the on-screen message names you at <code>amx_show_activity 2</code>. Finally grep the log and confirm your test action was recorded. When all three hold — limited flags, visible activity, logged commands — your admin team is accountable.</p> |
steam-vs-nonsteam-servers/en.md
A
| @@ -0,0 +1,54 @@ | ||
| 1 | +--- | |
| 2 | +title: "Steam vs Non-Steam CS 1.6 Servers: The Whole Picture" | |
| 3 | +excerpt: "How Steam and non-steam CS 1.6 servers differ in client auth, SteamIDs, the master list and moderation — and what Reunion or dproto actually change." | |
| 4 | +category: "misc" | |
| 5 | +tags: "non-steam, comparison" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>"Steam or non-steam" is the first decision every CS 1.6 admin makes, and it quietly shapes everything after it: who can connect, how reliable SteamIDs are, how you ban people, and which master list you show up in. Neither is objectively better — they serve different audiences. This lays out what actually differs so you choose deliberately instead of by accident.</p> | |
| 10 | + | |
| 11 | +<h2>1. What "Steam" means for a server</h2> | |
| 12 | +<p>A Steam server accepts only legitimate Steam clients. When a player connects, their Steam ticket is validated against Steam's auth servers, so the <code>STEAM_0:x:xxxx</code> ID they present is genuine and unique. That is the whole point: identity you can trust. Bans by SteamID actually stick, admins added by SteamID cannot be impersonated, and stats are reliable. The trade-off is reach — anyone running a non-Steam (pirated) client simply cannot join.</p> | |
| 13 | + | |
| 14 | +<h2>2. What "non-steam" means</h2> | |
| 15 | +<p>A non-steam server accepts clients that are not authenticated by Steam. In much of the world the non-steam player base dwarfs the Steam one, so for many communities this is where the players are. You enable it with an add-on that handles the missing auth layer:</p> | |
| 16 | +<table> | |
| 17 | +<thead><tr><th>Engine</th><th>Non-steam add-on</th></tr></thead> | |
| 18 | +<tbody> | |
| 19 | +<tr><td><a href="/tutorials/install-rehlds-on-linux">ReHLDS</a></td><td><a href="/tutorials/install-reunion">Reunion</a></td></tr> | |
| 20 | +<tr><td>Original HLDS</td><td>dproto</td></tr> | |
| 21 | +</tbody> | |
| 22 | +</table> | |
| 23 | +<p>Reunion is the modern choice and the one that pairs with the "Re" stack. See <a href="/tutorials/make-server-accept-nonsteam">making a server accept non-steam clients</a>.</p> | |
| 24 | + | |
| 25 | +<h2>3. The SteamID problem</h2> | |
| 26 | +<p>This is the real difference. On a Steam server, SteamIDs are validated and unique. On a non-steam server, the client can present whatever ID it likes unless the add-on forces otherwise. Two consequences:</p> | |
| 27 | +<ul> | |
| 28 | +<li><strong>Duplicate IDs.</strong> Many cracked clients ship with the same default SteamID, so half the server shows up as one person — which breaks stats, bans and admin. Reunion can generate per-client IDs from a hash to fix this; see <a href="/tutorials/fix-duplicate-steamids-nonsteam">fixing duplicate SteamIDs</a>.</li> | |
| 29 | +<li><strong>Spoofing.</strong> Without a secret salt, a non-steam client can claim an admin's SteamID and inherit their access. This is a genuine security hole you must close — see <a href="/tutorials/prevent-steamid-spoofing">preventing SteamID spoofing</a>.</li> | |
| 30 | +</ul> | |
| 31 | + | |
| 32 | +<h2>4. Master list and visibility</h2> | |
| 33 | +<p>Both kinds of server need <code>sv_lan 0</code> to heartbeat a master list, and both need UDP 27015 reachable (see <a href="/tutorials/cs16-server-firewall-ports">which ports to open</a>). Steam servers appear in the official Steam server browser. Non-steam servers appear in the non-steam clients' own browsers and third-party listers; Reunion and community master servers handle that ecosystem. If your server does not show up at all, the cause is usually the same for both: <a href="/tutorials/fix-server-not-in-master-list">a master-list or firewall problem</a>, not the Steam/non-steam choice.</p> | |
| 34 | + | |
| 35 | +<h2>5. Moderation and anti-cheat</h2> | |
| 36 | +<p>Steam servers can lean on the fact that identity is real: a SteamID ban is meaningful, and the account has something to lose. Non-steam servers get neither VAC nor guaranteed identity, so moderation leans harder on server-side tools — a solid <a href="/tutorials/install-amxbans">ban system</a>, name filtering, and consistent SteamID generation so a banned player cannot rejoin by restarting their client. Plan for more manual anti-cheat on non-steam.</p> | |
| 37 | + | |
| 38 | +<h2>6. Which should you run?</h2> | |
| 39 | +<ul> | |
| 40 | +<li><strong>Steam</strong> if your community is Steam-based, you want trustworthy identity and stats, and VAC coverage matters to you.</li> | |
| 41 | +<li><strong>Non-steam</strong> if you want maximum reach in regions where cracked clients dominate — accepting that you must actively harden identity and moderation.</li> | |
| 42 | +<li><strong>Both:</strong> a Reunion-configured server can accept Steam and non-steam clients at once, which is what most large community servers do. This gives reach without turning away Steam players.</li> | |
| 43 | +</ul> | |
| 44 | + | |
| 45 | +<h2>Common pitfalls</h2> | |
| 46 | +<ul> | |
| 47 | +<li><strong>Non-steam server, admins get impersonated</strong> — no secret <code>SteamIdHashSalt</code>. Set one; see <a href="/tutorials/prevent-steamid-spoofing">the spoofing guide</a>.</li> | |
| 48 | +<li><strong>Everyone shows the same SteamID</strong> — default cracked-client ID; enable Reunion's ID generation.</li> | |
| 49 | +<li><strong>Steam players cannot join a non-steam server</strong> — Reunion not configured to accept the Steam provider. Enable it if you want a mixed server.</li> | |
| 50 | +<li><strong>Bans do not hold</strong> — you banned a shared/spoofable ID. Fix ID uniqueness first, then ban.</li> | |
| 51 | +</ul> | |
| 52 | + | |
| 53 | +<h2>Verification</h2> | |
| 54 | +<p>Connect a test client and read your own identity in the console with <code>status</code> — a healthy setup shows a unique <code>STEAM_</code> ID for each player, not the same one repeated. On a mixed server, verify both a Steam and a non-steam client can join and each gets a distinct ID. Then confirm a SteamID ban actually blocks a rejoin. If IDs collide or are spoofable, stop and fix identity with the <a href="/tutorials/install-reunion">Reunion setup</a> before you open to the public.</p> |
update-plugins-live-server/en.md
A
| @@ -0,0 +1,13 @@ | ||
| 1 | +--- | |
| 2 | +title: "Updating Plugins on a Live Server Without Downtime" | |
| 3 | +excerpt: "Why AMX Mod X cannot hot-swap a plugin binary, how to stage a new .amxx safely, use amxx pause and a map change to reload cleanly, and roll back the moment something breaks." | |
| 4 | +category: "administration" | |
| 5 | +tags: "plugins, maintenance" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You want to push a new version of a plugin to a busy server without kicking everyone. The honest constraint first: AMX Mod X <strong>cannot hot-swap a compiled plugin at runtime</strong> — there is no "reload this <code>.amxx</code> in place" command. Plugins are loaded when the map loads. But you can absolutely update without a visible outage by staging the file and letting the next map change pick it up, and by using <code>amxx pause</code> to neutralize a bad plugin instantly. Here is the safe procedure.</p><h2>1. Understand when plugins actually load</h2><p>The plugin list in <code>plugins.ini</code> and the <code>.amxx</code> files are read once, at map load. Replacing <code>myplugin.amxx</code> on disk mid-map changes nothing until the map changes — the running server holds the old code in memory. This is why "I uploaded the new version and nothing happened" is not a bug. The map change is the reload event. See <a href="/tutorials/plugins-ini-load-order">plugins.ini load order</a> for how the list is processed.</p><h2>2. Stage the new file, do not overwrite blind</h2><p>Keep the current version so you can roll back in seconds:</p><pre>cd addons/amxmodx/plugins | |
| 10 | +cp myplugin.amxx myplugin.amxx.bak # keep the known-good build | |
| 11 | +cp /tmp/myplugin_new.amxx myplugin.amxx</pre><p>Now the new binary is on disk but the running server is still executing the old one in memory. Nothing has changed for connected players yet. This staging step is what makes the update safe: you have the new file ready and the old one preserved, and you have not disrupted the live map.</p><h2>3. Trigger the reload on your terms</h2><p>Let the reload happen at a natural boundary. Two options:</p><ul><li><strong>Wait for the next map change.</strong> Zero disruption — the plugin updates when the map rotates anyway, and players never notice.</li><li><strong>Force a controlled change.</strong> If you cannot wait, change to the same or next map when the round count is low. From RCON: <code>changelevel de_dust2</code> reloads every plugin cleanly. Warn players first with a <a href="/plugins/csb-adverts">chat notice</a>.</li></ul><p>A <code>changelevel</code> is a few seconds of reconnect, not a real outage. It is the closest thing to a graceful restart and it reloads the whole plugin set from disk, including your new file.</p><h2>4. Kill a misbehaving plugin instantly with pause</h2><p>If a plugin starts causing problems and you need it gone <em>now</em> without a map change, pause it from the server console:</p><pre>amxx pause myplugin.amxx | |
| 12 | +amxx unpause myplugin.amxx</pre><p><code>amxx pause</code> stops the plugin executing its forwards immediately, for the rest of the current map, without editing any file. This is your emergency brake: a new version is spamming chat or throwing runtime errors, you pause it, the server stays up, and you sort the file out before the next map. Confirm the state with <code>amxx plugins</code>, which shows each plugin as <code>running</code>, <code>paused</code>, or <code>bad load</code>.</p><h2>5. Verify the new version loaded, then roll back if not</h2><p>After the map change, check the plugin loaded and reports its new version:</p><pre>amxx plugins</pre><p>Find your plugin in the list — it should read <code>running</code> and, if the version string was bumped, show the new number. If it says <code>bad load</code>, the new build is broken (a missing module, a compile targeting the wrong AMXX branch). Roll back instantly:</p><pre>cp myplugin.amxx.bak myplugin.amxx | |
| 13 | +changelevel de_dust2</pre><p>You are back on the known-good build in one map change. Never delete the <code>.amxx</code> while its line is still in <code>plugins.ini</code> — that produces a <code>bad load</code> on every map load; comment the line instead.</p><h2>Common errors</h2><ul><li><strong>New version has no effect</strong> — you overwrote the file but did not change the map. Plugins reload at map load; force a <code>changelevel</code>.</li><li><strong><code>bad load</code> after the update</strong> — the new build needs a module you do not have, or was compiled for a different AMXX version. See <a href="/tutorials/fix-amxx-module-failed-to-load">module failed to load</a>.</li><li><strong>Server crashed on the new plugin</strong> — roll back to the <code>.bak</code> and change map; investigate offline with the <code>debug</code> flag.</li><li><strong>Paused plugin came back next map</strong> — <code>amxx pause</code> only lasts the current map. To disable it durably, comment the line in <code>plugins.ini</code>.</li><li><strong>Two versions loaded / duplicate</strong> — the file exists under two names both listed in <code>plugins.ini</code>. Keep exactly one line per plugin.</li></ul><h2>Verification</h2><p>Do a dry run on a test server first: bump the plugin's version string, deploy with the steps above, change map, and confirm <code>amxx plugins</code> shows the new version <code>running</code>. Then rehearse the rollback — restore the <code>.bak</code>, change map, confirm the old version is back. Once you trust the procedure, apply it live at a low-population moment. Pair this with the <a href="/tutorials/amxx-cfg-explained">amxx.cfg</a> settings so new plugin cvars are configured before they load.</p> | |
| 0 | 14 |
