Add 6 tutorials (6 files)
Browse Source
Daemon666 committed
parent 43154d68f0
commit ab2fb368c69df794b65d6c4d0f40f446613dea26
6 changed files
with 329 additions and 0 deletions
A
admin-immunity-setup/en.md
+48 -0
A
ban-systems-compared/en.md
+66 -0
A
cs16-competitive-video-config/en.md
+75 -0
A
make-your-first-cs16-map/en.md
+49 -0
A
monitor-server-uptime-alerts/en.md
+79 -0
A
sv-allowdownload-settings/en.md
+12 -0
admin-immunity-setup/en.md
A
| @@ -0,0 +1,48 @@ | ||
| 1 | +--- | |
| 2 | +title: "Admin Immunity: Setting Up the Immunity Flag Correctly" | |
| 3 | +excerpt: "What the AMX Mod X immunity flag actually protects against, how to grant it in users.ini, and the common misconception that higher access outranks immunity." | |
| 4 | +category: "administration" | |
| 5 | +tags: "immunity, admin" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Admin immunity in AMX Mod X is a single access flag that marks a player as protected from admin actions — other admins cannot kick, ban, slap or slay them, and reserved-slot logic will not bump them. It is one letter in <code>users.ini</code>, but there is a persistent misunderstanding about how it interacts with access levels that leads admins to think it is broken when it is working exactly as designed.</p> | |
| 10 | + | |
| 11 | +<h2>1. Immunity is a flag, not a rank</h2> | |
| 12 | +<p>In AMXX, immunity is <code>ADMIN_IMMUNITY</code>, and it maps to the access-flag letter <strong><code>a</code></strong>. It lives in the third field of a <code>users.ini</code> line — the same access-flags field that grants command permissions:</p> | |
| 13 | +<pre>; <steamid> <password> <access flags> <account flags> | |
| 14 | +"STEAM_0:1:12345" "" "abcdefghijklmnopqrstu" "ce"</pre> | |
| 15 | +<p>Here the leading <code>a</code> in the flags string is immunity. Every letter maps to a specific power — see the full <a href="/tutorials/amxx-admin-flags-reference">admin flags reference</a> — and <code>a</code> is deliberately first. A head admin usually has the whole alphabet; a junior admin might have only the moderation letters and no <code>a</code>.</p> | |
| 16 | + | |
| 17 | +<h2>2. Grant immunity to a specific admin</h2> | |
| 18 | +<p>To make one admin immune while keeping another exposed, add <code>a</code> to the first admin's access field and leave it off the second:</p> | |
| 19 | +<pre>"STEAM_0:1:12345" "" "abcdefghijklmnopqrstu" "ce" ; full admin, immune | |
| 20 | +"STEAM_0:1:99999" "" "cdefiju" "ce" ; junior mod, NOT immune</pre> | |
| 21 | +<p>Reload the file and reconnect (or change the map) for the change to take effect. The junior moderator can now be slapped or kicked by the head admin, but not the reverse.</p> | |
| 22 | + | |
| 23 | +<h2>3. Understand what immunity does and does not stop</h2> | |
| 24 | +<p>Immunity is honoured by plugins that explicitly check for it before acting. The stock admin commands do: <code>amx_kick</code>, <code>amx_ban</code>, <code>amx_slap</code>, <code>amx_slay</code> and the menu equivalents refuse to target an immune player. But immunity is a convention, not an engine-enforced shield:</p> | |
| 25 | +<ul> | |
| 26 | +<li>A poorly written third-party plugin that skips the immunity check <em>can</em> still act on an immune player. Immunity is only as good as the plugins that respect it.</li> | |
| 27 | +<li>It does not make a player invulnerable in-game, and it does not hide their actions. It is purely about admin commands.</li> | |
| 28 | +<li>Reserved-slot plugins treat immune players as never-kickable when freeing a slot.</li> | |
| 29 | +</ul> | |
| 30 | + | |
| 31 | +<h2>4. The level misconception</h2> | |
| 32 | +<p>The single most common belief is that a higher-access admin automatically overrides a lower admin's immunity. By default in AMXX, <strong>it does not.</strong> Immunity is flat: an immune player is protected from <em>all</em> other admins regardless of their access level, unless a plugin implements explicit level-based immunity (comparing flag counts or a dedicated ranking). Stock AMXX does not do this. So if your head admin cannot slap a junior who also has <code>a</code>, that is expected — remove <code>a</code> from the junior, or install a plugin that adds hierarchical immunity. This is why you should hand the immunity flag out sparingly.</p> | |
| 33 | + | |
| 34 | +<h2>5. Keep the activity visible</h2> | |
| 35 | +<p>Immunity plus hidden admin actions breeds accusations you cannot answer. Keep <code>amx_show_activity</code> at <code>2</code> in <a href="/tutorials/amxx-cfg-explained">amxx.cfg</a> so players see who did what, even when the actor is an immune head admin. Transparency and immunity are not in tension — the first is about accountability, the second about protecting trusted staff from each other's mistakes.</p> | |
| 36 | + | |
| 37 | +<h2>Common errors</h2> | |
| 38 | +<ul> | |
| 39 | +<li><strong>Head admin cannot act on a junior</strong> — the junior also has the <code>a</code> flag. Immunity is flat; remove <code>a</code> from the junior.</li> | |
| 40 | +<li><strong>Immune admin still gets slapped by a custom plugin</strong> — that plugin does not check immunity. This is a plugin bug, not an AMXX one; report it or replace the plugin.</li> | |
| 41 | +<li><strong>Immunity flag has no effect at all</strong> — you added <code>a</code> to the wrong field. It goes in the third field (access flags), not the fourth (account flags).</li> | |
| 42 | +<li><strong>Everyone seems immune</strong> — a flag was left in <code>amx_default_access</code> in amxx.cfg, granting <code>a</code> to the whole server. Set that cvar back to empty.</li> | |
| 43 | +</ul> | |
| 44 | + | |
| 45 | +<h2>Verification</h2> | |
| 46 | +<p>Connect two admin accounts, one with <code>a</code> and one without. From the non-immune account, try <code>amx_slap</code> on the immune one — it should refuse with an "immunity" style message. Then confirm the reverse works. You can also read a player's flags live:</p> | |
| 47 | +<pre>amx_who</pre> | |
| 48 | +<p>The immune admin's flag list should include the immunity letter. If you plan to run tiered staff where seniors <em>do</em> outrank juniors, pair this with a level-immunity plugin and document who holds <code>a</code>, because on stock AMXX everyone with it is untouchable to everyone else.</p> |
ban-systems-compared/en.md
A
| @@ -0,0 +1,66 @@ | ||
| 1 | +--- | |
| 2 | +title: "CS 1.6 Ban Systems Compared (AMXBans, Simple Bans, Built-in)" | |
| 3 | +excerpt: "Engine bans vs AMX Mod X amx_ban vs AMXBans MySQL: how each stores a ban, where the ban list lives, and which one to run for a single server versus a network." | |
| 4 | +category: "administration" | |
| 5 | +tags: "bans, comparison" | |
| 6 | +image: "" | |
| 7 | +read_time: "9 min read" | |
| 8 | +--- | |
| 9 | +<p>\"Ban systems\" on CS 1.6 are really three layers that people conflate: the engine's own ban list, AMX Mod X's <code>amx_ban</code> built on top of it, and full MySQL ban managers like AMXBans. They store bans in different places, survive restarts differently, and scale very differently. Picking the wrong one for your setup means bans that vanish on restart or a database you did not need. Here is what each actually does.</p> | |
| 10 | + | |
| 11 | +<h2>1. Layer one: the engine ban list</h2> | |
| 12 | +<p>The GoldSrc engine bans without any addon, using two commands and two files. SteamID bans go through <code>banid</code>, IP bans through <code>addip</code>:</p> | |
| 13 | +<pre>banid 0 STEAM_0:1:12345 kick // permanent SteamID ban, kick now | |
| 14 | +addip 0 203.0.113.44 // permanent IP ban (0 = permanent) | |
| 15 | +writeid // flush SteamID bans to banned.cfg | |
| 16 | +writeip // flush IP bans to listip.cfg</pre> | |
| 17 | +<p>The critical gotcha: bans are held <strong>in memory</strong> until you <code>writeid</code>/<code>writeip</code>. If you <code>banid</code> someone and the server restarts before a write, the ban is gone. <code>banned.cfg</code> and <code>listip.cfg</code> are executed at startup to reload them, and <code>sv_filterban 1</code> must be set for the filter to actually block. This layer has no reason, no duration tracking, no admin name — just IDs.</p> | |
| 18 | + | |
| 19 | +<h2>2. Layer two: AMX Mod X amx_ban</h2> | |
| 20 | +<p>The AMX Mod X admin base (<code>admin.amxx</code>) wraps the engine ban in a usable command with a duration and a reason:</p> | |
| 21 | +<pre>amx_ban <name|#userid> <minutes> [reason] // 0 minutes = permanent | |
| 22 | +amx_banip <name|#userid> <minutes> [reason] | |
| 23 | +amx_addban <steamid> <minutes> [reason] // ban an offline SteamID | |
| 24 | +amx_unban <steamid></pre> | |
| 25 | +<p>This is the right tool for the overwhelming majority of servers. It records who banned whom, for how long, and why; timed bans expire on their own; and it still calls the engine underneath so <code>sv_filterban</code> enforcement applies. Bans are stored in the AMXX <code>bans</code> file under <code>addons/amxmodx/</code>. It gives you an in-game <code>amx_banmenu</code> too — pair it with the <a href="/plugins/csb-admin-menu">CSB Admin Menu</a> for a point-and-click workflow. What it does <em>not</em> do is share bans across multiple servers or give you a web page to manage them.</p> | |
| 26 | + | |
| 27 | +<h2>3. Layer three: AMXBans and MySQL managers</h2> | |
| 28 | +<p>AMXBans is a plugin plus a MySQL database plus a web front-end. Every ban is a database row, so a ban on one server is instantly enforced on every server pointed at the same database, and you get a website where admins issue and lift bans, attach demos and screenshots, and players can appeal. This is what a <strong>network</strong> of servers wants. The cost is real: you run and secure a MySQL database (see <a href="/tutorials/backup-configs-bans-stats">backing it up</a>), install and configure the web panel, and accept that a database outage affects banning. For a single server it is overkill; for five servers sharing an admin team it is the only sane option.</p> | |
| 29 | + | |
| 30 | +<h2>4. Side-by-side</h2> | |
| 31 | +<table> | |
| 32 | +<thead><tr><th>Feature</th><th>Engine banid</th><th>amx_ban</th><th>AMXBans (MySQL)</th></tr></thead> | |
| 33 | +<tbody> | |
| 34 | +<tr><td>Storage</td><td>banned.cfg / listip.cfg</td><td>AMXX bans file</td><td>MySQL database</td></tr> | |
| 35 | +<tr><td>Timed bans</td><td>minutes field, manual</td><td>yes, auto-expire</td><td>yes, auto-expire</td></tr> | |
| 36 | +<tr><td>Reason / admin recorded</td><td>no</td><td>yes</td><td>yes, plus demos/appeals</td></tr> | |
| 37 | +<tr><td>Shared across servers</td><td>no</td><td>no</td><td>yes</td></tr> | |
| 38 | +<tr><td>Web management</td><td>no</td><td>no</td><td>yes</td></tr> | |
| 39 | +<tr><td>Setup effort</td><td>none</td><td>ships with AMXX</td><td>high (DB + panel)</td></tr> | |
| 40 | +<tr><td>Good for</td><td>quick manual ban</td><td>one server</td><td>a network</td></tr> | |
| 41 | +</tbody> | |
| 42 | +</table> | |
| 43 | + | |
| 44 | +<h2>5. Which to run</h2> | |
| 45 | +<ul> | |
| 46 | +<li><strong>One server, casual</strong> — <code>amx_ban</code>. It is already installed, it does everything you need, and there is nothing extra to secure.</li> | |
| 47 | +<li><strong>One server, but you want a ban history and menu</strong> — still <code>amx_ban</code>, plus the admin menu. Do not add a database for a single box.</li> | |
| 48 | +<li><strong>Multiple servers, shared admins</strong> — AMXBans or an equivalent MySQL manager, so a ban is enforced everywhere and admins work from one panel.</li> | |
| 49 | +</ul> | |
| 50 | +<p>Whichever you pick, verify <code>sv_filterban 1</code> is set, because all three ultimately rely on the engine to refuse the connection.</p> | |
| 51 | + | |
| 52 | +<h2>Common errors</h2> | |
| 53 | +<ul> | |
| 54 | +<li><strong>Bans disappear after a restart</strong> — you used raw <code>banid</code> without <code>writeid</code>, so the ban never hit <code>banned.cfg</code>. Use <code>amx_ban</code>, which persists for you, or remember to write.</li> | |
| 55 | +<li><strong>Banned player still connects</strong> — <code>sv_filterban 0</code>, or the player switched SteamID (common on non-Steam servers — ban the IP too, or use a validation setup like <a href="/tutorials/reunion-non-steam-setup">Reunion</a>).</li> | |
| 56 | +<li><strong>amx_ban says \"unknown command\"</strong> — <code>admin.amxx</code> is not loaded, or your admin entry lacks the ban flag. Check <a href="/tutorials/plugins-ini-load-order">plugins.ini</a> and <code>users.ini</code> flags.</li> | |
| 57 | +<li><strong>AMXBans web panel and in-game disagree</strong> — the plugin and the panel point at different databases or table prefixes. They must share one schema.</li> | |
| 58 | +<li><strong>IP ban blocks innocent players</strong> — you IP-banned a shared/CGNAT address. Prefer SteamID bans on Steam servers; reserve IP bans for repeat evaders.</li> | |
| 59 | +</ul> | |
| 60 | + | |
| 61 | +<h2>Verification</h2> | |
| 62 | +<p>Ban a test account and prove the ban survives the round-trip. With <code>amx_ban</code>, ban yourself for one minute, confirm the kick, then check the ban is written:</p> | |
| 63 | +<pre>amx_addban STEAM_0:1:99999 1 "test" | |
| 64 | +// then confirm the engine knows it | |
| 65 | +listid</pre> | |
| 66 | +<p><code>listid</code> should list the SteamID. Restart the server and run <code>listid</code> again — a persistent ban is still there. If it vanished, the write step failed and you have your answer.</p> |
cs16-competitive-video-config/en.md
A
| @@ -0,0 +1,75 @@ | ||
| 1 | +--- | |
| 2 | +title: "A Competitive Video Config for CS 1.6 (Gamma, r_ Cvars, Visibility)" | |
| 3 | +excerpt: "A clean, cheat-free video config for CS 1.6: gamma and brightness that keep dark corners readable, the r_ cvars that actually help, and which ones need sv_cheats." | |
| 4 | +category: "client" | |
| 5 | +tags: "config, video" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A good competitive video setup in CS 1.6 does one thing: it makes enemies easy to see without breaking the rules or the game's feel. There is a lot of folklore attached to this — half the cvars people share are cheat-protected and will not take on a real server, and a few are placebos. This is a lean config of the settings that genuinely help, with an honest note on which ones the server has to allow.</p> | |
| 10 | + | |
| 11 | +<h2>1. Set gamma and brightness for readable shadows</h2> | |
| 12 | +<p>The single biggest visibility win is lifting the darks so a player crouched in a shadow is not invisible. These are not cheats and work on any server:</p> | |
| 13 | +<pre>gamma 3 | |
| 14 | +brightness 2 | |
| 15 | +texgamma 2 | |
| 16 | +lightgamma 2.5</pre> | |
| 17 | +<p><code>gamma</code> ranges roughly 1–3; 3 is the practical maximum before the image washes out. <code>brightness</code> lifts the black point. <code>texgamma</code> and <code>lightgamma</code> shape how textures and lightmaps are toned. Push these until dark corners read clearly but bright areas do not bloom into a white smear — that balance point is personal, so tune on a dark map like <code>de_nuke</code>.</p> | |
| 18 | + | |
| 19 | +<h2>2. The r_ cvars worth setting</h2> | |
| 20 | +<p>Most <code>r_</code> cvars people paste around either do nothing useful or require <code>sv_cheats 1</code>. The ones that are legitimately worth setting:</p> | |
| 21 | +<pre>r_detailtextures 0 // no detail-texture overlay; cleaner surfaces | |
| 22 | +r_decals 100 // cap decals so blood/bullet spam does not pile up | |
| 23 | +gl_max_size 512 // texture upload size; keep default unless low VRAM | |
| 24 | +gl_texturemode GL_LINEAR_MIPMAP_LINEAR // trilinear, smooth distant textures</pre> | |
| 25 | +<p>Lowering <code>r_decals</code> keeps the screen from filling with blood and bullet holes in a long round, which is a real clarity gain, not a placebo.</p> | |
| 26 | + | |
| 27 | +<h2>3. Cvars that need sv_cheats — do not rely on them</h2> | |
| 28 | +<p>Be clear-eyed about this: the dramatic "see through walls" brightness cvars are cheat-protected. They will only take effect when the server has <code>sv_cheats 1</code>, which no real public or match server runs:</p> | |
| 29 | +<pre>gl_monolights 1 // sv_cheats only — flat fullbright lighting | |
| 30 | +r_fullbright 1 // sv_cheats only | |
| 31 | +r_lightmap 0 // sv_cheats only</pre> | |
| 32 | +<p>On a normal server these silently revert to their locked values. If a config promises wall-hack-like vision from these, it only works offline or on a misconfigured server — see the <a href="/tutorials/essential-server-cvars">server cvars</a> for why <code>sv_cheats</code> stays 0 in public.</p> | |
| 33 | + | |
| 34 | +<h2>4. Resolution, refresh and FPS</h2> | |
| 35 | +<p>Pick your monitor's native or preferred mode in the video options, and drive FPS from launch options and a cap:</p> | |
| 36 | +<pre>fps_max 100 | |
| 37 | +cl_showfps 1</pre> | |
| 38 | +<p>Whether you can exceed 100 FPS, and the physics reasons you might want a specific number, are covered in <a href="/tutorials/cs16-fps-max-explained">fps_max and fps_override</a>. Set your refresh rate with the <code>-freq</code> launch option (for example <code>-freq 144</code>) so the game does not default to 60 Hz on a high-refresh panel.</p> | |
| 39 | + | |
| 40 | +<h2>5. Keep the HUD out of the way</h2> | |
| 41 | +<p>A smaller, dimmer HUD leaves more of the screen for reading the map:</p> | |
| 42 | +<pre>hud_fastswitch 1 | |
| 43 | +cl_radartype 1 | |
| 44 | +developer 0</pre> | |
| 45 | +<p><code>hud_fastswitch 1</code> also makes weapon binds instant, which pairs with your <a href="/tutorials/cs16-buy-binds">buy binds</a>.</p> | |
| 46 | + | |
| 47 | +<h2>6. Save it so it survives restarts</h2> | |
| 48 | +<p>Do not put these in <code>config.cfg</code> — the game rewrites that file on exit. Create <code>cstrike/autoexec.cfg</code> (it runs at launch) or a named config you exec, and keep your video block there:</p> | |
| 49 | +<pre>// autoexec.cfg | |
| 50 | +gamma 3 | |
| 51 | +brightness 2 | |
| 52 | +texgamma 2 | |
| 53 | +lightgamma 2.5 | |
| 54 | +r_detailtextures 0 | |
| 55 | +r_decals 100 | |
| 56 | +fps_max 100 | |
| 57 | +hud_fastswitch 1 | |
| 58 | +echo "autoexec loaded"</pre> | |
| 59 | +<p>The trailing <code>echo</code> prints to console at startup so you know the file actually ran.</p> | |
| 60 | + | |
| 61 | +<h2>Common errors</h2> | |
| 62 | +<ul> | |
| 63 | +<li><strong>Brightness cvars "do nothing"</strong> — you tried <code>gl_monolights</code> or <code>r_fullbright</code> on a real server. Those need <code>sv_cheats 1</code>; use <code>gamma</code>, <code>brightness</code>, <code>texgamma</code> and <code>lightgamma</code> instead.</li> | |
| 64 | +<li><strong>Settings reset every launch</strong> — you edited <code>config.cfg</code>, which the game overwrites. Move them to <code>autoexec.cfg</code>.</li> | |
| 65 | +<li><strong>Image is washed out and hard to read</strong> — gamma and brightness pushed too far. Back them down until bright areas stop blooming.</li> | |
| 66 | +<li><strong>Game runs at 60 Hz on a 144 Hz monitor</strong> — no <code>-freq</code> launch option. Add <code>-freq 144</code>.</li> | |
| 67 | +<li><strong>Texture mode reverts</strong> — you typed the enum wrong; it must be one of the <code>GL_*_MIPMAP_*</code> strings exactly.</li> | |
| 68 | +</ul> | |
| 69 | + | |
| 70 | +<h2>Verification</h2> | |
| 71 | +<p>Load a dark map offline and read your values back in console by typing each cvar with no argument:</p> | |
| 72 | +<pre>gamma | |
| 73 | +brightness | |
| 74 | +r_decals</pre> | |
| 75 | +<p>The console echoes the current value of each. Then join a real server and confirm gamma and brightness still apply while the cheat cvars do not — that split is exactly what you want, because a config that only looks good offline is worthless in a match. If <code>autoexec.cfg</code> printed its <code>echo</code> line at startup, your settings loaded cleanly.</p> |
make-your-first-cs16-map/en.md
A
| @@ -0,0 +1,49 @@ | ||
| 1 | +--- | |
| 2 | +title: "Making Your First CS 1.6 Map: de_ Layout and Required Entities" | |
| 3 | +excerpt: "Build a minimal but playable defusal map: seal the world, place both team spawns, add buy zones and a bomb site, light it, and compile it into cstrike/maps." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "mapping, beginner" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A defusal (<code>de_</code>) map is the most forgiving place to start, because it needs only a handful of special entities to be playable: two sets of spawns, a buy zone for each team, and at least one bomb site. Everything else — cover, rotations, timing — is level-design craft you refine later. This walks the minimum viable map, the pieces the engine actually requires, so your first compile drops you into a round rather than a "server info" error.</p> | |
| 10 | + | |
| 11 | +<h2>1. Seal a world-brush room</h2> | |
| 12 | +<p>Draw a large box and hollow it (or build six world brushes) into a sealed room. This is the single most important rule in GoldSrc mapping: <strong>only world brushes seal the map</strong>. If the shell leaks, VIS and lighting never run — see <a href="/tutorials/fix-leak-in-hull-pointfile">fixing leaks with the pointfile</a>. Texture every face; untextured faces cause compile warnings.</p> | |
| 13 | + | |
| 14 | +<h2>2. Place both team spawns</h2> | |
| 15 | +<p>CS uses two different spawn entities, one per team, and the names are not intuitive:</p> | |
| 16 | +<pre>info_player_start <- Counter-Terrorist spawns | |
| 17 | +info_player_deathmatch <- Terrorist spawns</pre> | |
| 18 | +<p>Place them slightly above the floor so players do not spawn stuck in the ground. For a full server you want roughly 16 of each, spread out so players do not telefrag on spawn. For a first test, four of each is enough. Point them in a sensible facing direction using the angle property.</p> | |
| 19 | + | |
| 20 | +<h2>3. Add a buy zone for each team</h2> | |
| 21 | +<p>Players can only buy inside a buy zone. Make a thin brush covering each spawn area, tie it to <code>func_buyzone</code>, and set its team so CTs buy at their spawn and Ts at theirs:</p> | |
| 22 | +<pre>Brush over CT spawn → tie to func_buyzone (team: CT) | |
| 23 | +Brush over T spawn → tie to func_buyzone (team: T)</pre> | |
| 24 | +<p>The buy-zone brush should use a tool/trigger texture (e.g. AAATRIGGER) so it is invisible in-game. Without a buy zone, players spawn with a pistol and no way to buy, and you will think the economy is broken.</p> | |
| 25 | + | |
| 26 | +<h2>4. Create a bomb site</h2> | |
| 27 | +<p>A bomb site is a brush tied to <code>func_bomb_target</code> (some FGDs also expose <code>info_bomb_target</code> as a point marker). Cover the plant area — a corner of the room is fine for a first map — with a trigger-textured brush and tie it:</p> | |
| 28 | +<pre>Brush over plant area → tie to func_bomb_target</pre> | |
| 29 | +<p>With a bomb target present the game auto-arms the map as a defusal round: one T carries the C4, CTs must defuse. No hostage entities are needed for a <code>de_</code> map — those belong to <code>cs_</code> rescue maps.</p> | |
| 30 | + | |
| 31 | +<h2>5. Light the map</h2> | |
| 32 | +<p>Without a light entity the whole map renders fullbright (flat, shadeless). Add at least one <code>light</code> entity, or a <code>light_environment</code> if the room has a sky. Set a brightness that is not blinding — the fourth value in the light's color is intensity:</p> | |
| 33 | +<pre>light _light "255 255 220 200"</pre> | |
| 34 | +<p>For an outdoor area, texture the ceiling with the <code>SKY</code> tool texture and add a single <code>light_environment</code> plus an <code>info_sunlight</code>/angle to cast directional sun. One indoor <code>light</code> is enough to prove the pipeline works.</p> | |
| 35 | + | |
| 36 | +<h2>6. Name it correctly and compile</h2> | |
| 37 | +<p>Save the source map with a <code>de_</code> prefix (e.g. <code>de_firsttest</code>) so the game treats it as defusal, then run a full compile from <a href="/tutorials/jack-editor-setup-cs16">J.A.C.K.</a> with all four stages enabled. The output <code>.bsp</code> must land in <code>cstrike/maps/</code>. Add it to your rotation via <a href="/tutorials/mapcycle-txt-setup">mapcycle.txt</a> and, if you host downloads, mirror it through <a href="/tutorials/fastdl-setup-guide">FastDL</a>.</p> | |
| 38 | + | |
| 39 | +<h2>Troubleshooting</h2> | |
| 40 | +<ul> | |
| 41 | +<li><strong>Spawn as spectator / cannot join a team</strong> — you are missing one of the two spawn types. Both <code>info_player_start</code> and <code>info_player_deathmatch</code> must exist.</li> | |
| 42 | +<li><strong>Round never starts / "waiting for players"</strong> — no <code>func_bomb_target</code>, so the game has no objective. Add a bomb site.</li> | |
| 43 | +<li><strong>Cannot buy anything</strong> — no <code>func_buyzone</code> over the spawn, or the brush is not actually tied to the entity.</li> | |
| 44 | +<li><strong>Map is flat and shadeless</strong> — no <code>light</code> entity, or you compiled without RAD. Add a light and run the full toolchain.</li> | |
| 45 | +<li><strong>Map will not load, "leak" in console</strong> — the shell is not sealed; walk the <a href="/tutorials/fix-leak-in-hull-pointfile">pointfile</a>.</li> | |
| 46 | +</ul> | |
| 47 | + | |
| 48 | +<h2>Verification</h2> | |
| 49 | +<p>Launch a local server on the map with a couple of bots (see <a href="/tutorials/install-yapb-bots">installing YaPB bots</a>). You should spawn on a team, be able to buy at your spawn, pick up and plant the C4 at the site, and see the map lit rather than fullbright. Once the minimum map plays a full round end to end, iterate on the layout — cover, two bomb sites, tighter timings — and re-tune the final compile using the <a href="/tutorials/zhlt-vhlt-compile-parameters">VHLT parameters</a>.</p> |
monitor-server-uptime-alerts/en.md
A
| @@ -0,0 +1,79 @@ | ||
| 1 | +--- | |
| 2 | +title: "Monitoring Server Uptime and Getting Alerts" | |
| 3 | +excerpt: "Auto-restart a crashed CS 1.6 server with systemd, query the game port to confirm it is really up, and fire an alert to a webhook when it goes down." | |
| 4 | +category: "administration" | |
| 5 | +tags: "monitoring, uptime" | |
| 6 | +image: "" | |
| 7 | +read_time: "9 min read" | |
| 8 | +--- | |
| 9 | +<p>A CS 1.6 server that crashes at 3am and stays down until you wake up loses its regulars fast. There are two separate problems to solve: making the process come back on its own, and knowing when it didn't. This covers auto-restart with systemd, a real availability check that queries the game port (not just the process), and a small alerting script you can run from cron.</p> | |
| 10 | + | |
| 11 | +<h2>1. Auto-restart with systemd</h2> | |
| 12 | +<p>Running HLDS under systemd gives you automatic restart on crash for free. A minimal unit:</p> | |
| 13 | +<pre>// /etc/systemd/system/cs16.service | |
| 14 | +[Unit] | |
| 15 | +Description=CS 1.6 Server | |
| 16 | +After=network.target | |
| 17 | + | |
| 18 | +[Service] | |
| 19 | +User=hlds | |
| 20 | +WorkingDirectory=/home/hlds/hlds | |
| 21 | +ExecStart=/home/hlds/hlds/hlds_run -game cstrike +ip 0.0.0.0 +port 27015 +map de_dust2 +maxplayers 20 | |
| 22 | +Restart=always | |
| 23 | +RestartSec=5 | |
| 24 | + | |
| 25 | +[Install] | |
| 26 | +WantedBy=multi-user.target</pre> | |
| 27 | +<pre>systemctl daemon-reload | |
| 28 | +systemctl enable --now cs16</pre> | |
| 29 | +<p><code>Restart=always</code> brings the process back whether it crashed or exited cleanly. That handles most outages, but it does not catch a process that is alive yet frozen — which is why you still need an external check.</p> | |
| 30 | + | |
| 31 | +<h2>2. Check availability the right way</h2> | |
| 32 | +<p>Checking that the process exists (<code>pgrep hlds</code>) is weak: a hung server still has a running process. The reliable test is to send it an A2S_INFO query on its UDP game port and require a reply. A tiny Python check:</p> | |
| 33 | +<pre>#!/usr/bin/env python3 | |
| 34 | +import socket, sys | |
| 35 | +HOST, PORT = "127.0.0.1", 27015 | |
| 36 | +pkt = b"\xFF\xFF\xFF\xFFTSource Engine Query\x00" | |
| 37 | +s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) | |
| 38 | +s.settimeout(3) | |
| 39 | +try: | |
| 40 | + s.sendto(pkt, (HOST, PORT)) | |
| 41 | + s.recvfrom(1400) # any reply means it is answering | |
| 42 | + sys.exit(0) | |
| 43 | +except Exception: | |
| 44 | + sys.exit(1)</pre> | |
| 45 | +<p>Exit 0 means the server answered a real client query; exit 1 means it is down or frozen. This is the same query a client's server browser sends, so it tests what players actually experience. Make sure UDP 27015 is reachable — see <a href="/tutorials/cs16-server-firewall-ports">which ports to open</a>.</p> | |
| 46 | + | |
| 47 | +<h2>3. Send an alert on failure</h2> | |
| 48 | +<p>Wrap the check so it posts to a webhook (Discord, Slack, a status page — anything that takes an HTTP POST) only when the server is down:</p> | |
| 49 | +<pre>#!/bin/bash | |
| 50 | +if ! /usr/local/bin/cs_check.py; then | |
| 51 | + curl -s -X POST "$WEBHOOK_URL" \ | |
| 52 | + -H 'Content-Type: application/json' \ | |
| 53 | + -d '{"content":"CS 1.6 server 27015 is DOWN"}' | |
| 54 | +fi</pre> | |
| 55 | +<p>Run it from cron every minute:</p> | |
| 56 | +<pre>* * * * * WEBHOOK_URL='https://your-webhook' /usr/local/bin/cs_alert.sh</pre> | |
| 57 | +<p>To avoid a message every single minute during a long outage, have the script write a small state file and only alert on the transition from up to down (and again on recovery). Even the naive version above is a big improvement over finding out from an angry player.</p> | |
| 58 | + | |
| 59 | +<h2>4. Watch the things that predict a crash</h2> | |
| 60 | +<p>Uptime is downstream of resource health. Two cheap habits:</p> | |
| 61 | +<ul> | |
| 62 | +<li>Log server FPS and player count periodically — a server FPS that collapses under load precedes choke and drops. The <a href="/tutorials/sys-ticrate-truth">sys_ticrate guide</a> explains what a healthy value looks like.</li> | |
| 63 | +<li>Watch the AMXX logs for repeating run-time errors; a plugin looping on an error can drag the whole server down. <a href="/tutorials/plugins-ini-load-order">Load a suspect plugin in debug mode</a> to pin it.</li> | |
| 64 | +</ul> | |
| 65 | +<p>It is also worth watching the host, not just the game: memory pressure, a full disk in <code>cstrike/logs/</code>, or a runaway process on the same box will take the server down in ways no in-game check predicts. A one-line cron that alerts on disk usage over 90% or free memory near zero catches the slow failures that a per-minute A2S probe only notices once it is already too late.</p> | |
| 66 | + | |
| 67 | +<h2>Troubleshooting</h2> | |
| 68 | +<ul> | |
| 69 | +<li><strong>systemd restarts in a tight loop</strong> — the server exits immediately (bad startup line, missing files). Read <code>journalctl -u cs16 -n 50</code>; <code>RestartSec=5</code> keeps the loop from hammering the box while you fix it.</li> | |
| 70 | +<li><strong>Check reports down but players are on</strong> — you queried the wrong IP/port, or the query is blocked by the firewall while the game traffic is not. Point the check at <code>127.0.0.1</code> from the same host.</li> | |
| 71 | +<li><strong>Alerts never fire</strong> — the webhook URL is wrong or unreachable, or cron's environment lacks it. Test the <code>curl</code> line by hand first.</li> | |
| 72 | +<li><strong>Constant false alarms</strong> — a 3-second timeout is too tight for a loaded server; raise it, and only alert on state changes.</li> | |
| 73 | +</ul> | |
| 74 | + | |
| 75 | +<h2>Verification</h2> | |
| 76 | +<p>Stop the server deliberately and confirm the whole chain works:</p> | |
| 77 | +<pre>systemctl stop cs16 | |
| 78 | +/usr/local/bin/cs_check.py; echo "exit $?" // expect exit 1</pre> | |
| 79 | +<p>You should receive one alert, and with <code>Restart=always</code> the service should be back within seconds of a crash (a manual <code>stop</code> stays down, as intended). Start it again and confirm the check returns exit 0. Once the loop is proven, layer the resource checks on top so you are warned before the crash, not after.</p> |
sv-allowdownload-settings/en.md
A
| @@ -0,0 +1,12 @@ | ||
| 1 | +--- | |
| 2 | +title: "sv_allowdownload, sv_allowupload and sv_downloadurl Explained" | |
| 3 | +excerpt: "Exactly what each download cvar does, how the server and client flags interact, why sv_downloadurl needs the cstrike path, and how to stop clients joining with missing textures." | |
| 4 | +category: "administration" | |
| 5 | +tags: "downloads, cvars" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Custom content — maps, models, sprays, sounds — only reaches players if the download cvars are set correctly on both ends. Three server cvars and two client cvars govern the whole thing, and admins routinely set one and forget its partner, producing the classic "everyone has missing textures" symptom. This explains each cvar precisely and how they interact.</p><h2>1. sv_allowdownload — the master switch</h2><pre>sv_allowdownload 1</pre><p>With this at <code>1</code>, the server is allowed to hand missing files to connecting clients. At <code>0</code>, a client that lacks a map or model simply joins without it — purple/black checkerboard textures, silent weapons, an <code>ERROR</code> model where a custom prop should be. This is the first cvar to check when players report missing content. It controls whether downloads happen at all; <em>how</em> they happen (slow in-game transfer vs fast HTTP) is decided by <code>sv_downloadurl</code>.</p><h2>2. sv_allowupload — sprays and logos</h2><pre>sv_allowupload 1</pre><p>This governs the reverse direction: clients uploading their spray logo to the server so <em>other</em> players can see it. At <code>0</code>, sprays still work locally for the person spraying but nobody else sees custom logos. It has nothing to do with map or model downloads — a common confusion. Leave it at <code>1</code> for a normal public server unless you specifically want to suppress user sprays (some admins disable it to stop offensive logos, alongside a higher <code>decalfrequency</code>).</p><h2>3. sv_downloadurl — fast vs slow</h2><pre>sv_downloadurl "http://dl.example.com/cs"</pre><p>With <code>sv_allowdownload 1</code> but <strong>no</strong> <code>sv_downloadurl</code>, downloads still happen — but over the ancient in-game UDP transfer at a few KB/s, so a 20 MB map empties the server on every map change. <code>sv_downloadurl</code> points clients at an HTTP mirror (FastDL) instead, moving transfers to a real web server. The path is the part people break: the engine appends the game-relative path <em>including the <code>cstrike/</code> folder</em>, so a request for <code>cstrike/maps/de_rats.bsp</code> becomes <code>http://dl.example.com/cs/cstrike/maps/de_rats.bsp</code>. Your web root must contain a <code>cstrike/</code> directory that mirrors the server. The full setup, with Nginx and Apache examples and bzip2 compression, is in the <a href="/tutorials/fastdl-setup-guide">FastDL setup guide</a>.</p><h2>4. The client side you cannot control</h2><p>Two client cvars decide whether a player accepts downloads, and they are set on the player's machine, not yours:</p><table><thead><tr><th>Cvar</th><th>Default</th><th>Effect</th></tr></thead><tbody><tr><td><code>cl_allowdownload</code></td><td>1</td><td>Client accepts file downloads from servers.</td></tr><tr><td><code>cl_allowupload</code></td><td>1</td><td>Client uploads its own spray to servers.</td></tr></tbody></table><p>If a player set <code>cl_allowdownload 0</code>, they join every server with missing content no matter what you do. You cannot override it from the server; the most you can do is tell them to set it back to <code>1</code>. It defaults on, so this only affects players who changed it deliberately.</p><h2>5. Putting it together</h2><p>A correct public-server download block looks like this in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a>:</p><pre>sv_allowdownload 1 | |
| 10 | +sv_allowupload 1 | |
| 11 | +sv_downloadurl "http://dl.example.com/cs"</pre><p>The mental model: <code>sv_allowdownload</code> decides <em>whether</em>, <code>sv_downloadurl</code> decides <em>how fast</em>, <code>sv_allowupload</code> is the unrelated spray direction, and the two <code>cl_</code> cvars are the client's veto. Get all three server cvars right and keep the mirror in sync with your <a href="/tutorials/mapcycle-txt-setup">map rotation</a>, and content lands fast.</p><h2>6. What each side actually decides</h2><p>It helps to trace one join. A client connects and the server tells it the list of files this map references — the <code>.bsp</code>, any custom models and sounds, sprites. For each file the client does not already have, it checks its own <code>cl_allowdownload</code>; if that is <code>0</code>, it skips the file and you get missing textures no matter what the server does. If it is <code>1</code>, the client asks the server for the file. The server checks <code>sv_allowdownload</code>; if that is <code>0</code>, it refuses and the client joins without the content. If it is <code>1</code>, the server looks at <code>sv_downloadurl</code>: set, and the client is redirected to fetch over HTTP; empty, and the file dribbles over the slow in-game channel. Nothing about this touches <code>sv_allowupload</code>, which only governs the separate act of a client pushing its spray logo up so others can see it. Keeping those four decisions straight is the whole game — most "downloads broken" tickets are one of them set wrong on one side.</p><h2>Common errors</h2><ul><li><strong>Everyone has missing textures</strong> — <code>sv_allowdownload 0</code>, or the file is not on the mirror. Turn it on and confirm the content exists on the FastDL host.</li><li><strong>Downloads work but crawl</strong> — <code>sv_downloadurl</code> is empty or unreachable, so the server fell back to the UDP transfer. Test the URL in a browser.</li><li><strong>Every file 404s over HTTP</strong> — the <code>cstrike/</code> level is missing or doubled in the web root. The client requests <code><url>/cstrike/maps/...</code>; that exact path must resolve.</li><li><strong>One player always misses content, others are fine</strong> — that player set <code>cl_allowdownload 0</code>. Only they can fix it.</li><li><strong>Sprays do not show for others</strong> — <code>sv_allowupload 0</code> on the server or <code>cl_allowupload 0</code> on the client.</li></ul><h2>Verification</h2><p>Read the values back in the console by typing each cvar with no argument:</p><pre>sv_allowdownload | |
| 12 | +sv_downloadurl</pre><p>Then delete a custom map from a test client, connect, and watch it pull the file — fast over HTTP if the mirror is right, slow if it fell back. If the client shows missing textures despite everything, confirm <code>cl_allowdownload</code> is <code>1</code> on that client. For the mirror itself, open the exact map URL in a browser as described in the <a href="/tutorials/fastdl-setup-guide">FastDL guide</a>.</p> | |
| 0 | 13 |
