Add 6 tutorials (6 files)
Browse Source
Daemon666 committed
parent 993385f970
commit bab3e001a876ad45e0f75c91b135243c3da0bbc7
6 changed files
with 186 additions and 0 deletions
A
create-bomb-sites/en.md
+10 -0
A
goldsrc-map-optimization-checklist/en.md
+9 -0
A
install-cod-mod/en.md
+63 -0
A
install-deathrun-mod/en.md
+49 -0
A
install-rehlds-regamedll-reapi-stack/en.md
+45 -0
A
valve-master-servers-explained/en.md
+10 -0
create-bomb-sites/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Creating Bomb Sites (func_bomb_target and info_bomb_target)" | |
| 3 | +excerpt: "How to make a de_ map's bomb sites work: the brush func_bomb_target versus the point info_bomb_target, the func_buyzone the Ts need, and info_map_parameters to control bomb rules." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "entities, de-maps" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A <code>de_</code> map is defined by its bomb sites — the zones where the Terrorists can plant the C4. If you build a beautiful defusal map with no bomb-target entity, the Ts spawn with the bomb and have nowhere to plant it, the round never resolves on an objective, and the map behaves like a deathmatch. This covers the two ways to define a site, the buyzone the Ts need, and the parameters that tune bomb behaviour.</p><h2>1. Choose the bomb-target entity</h2><p>CS 1.6 gives you two entities to mark where the bomb can be planted, and you pick based on the shape of the site:</p><ul><li><strong><code>func_bomb_target</code></strong> — a <em>brush</em> entity. You tie it to a brush covering the plantable area, so the plant zone is exactly the volume you draw. Use this when the site is a defined region (a warehouse floor, a platform).</li><li><strong><code>info_bomb_target</code></strong> — a <em>point</em> entity. It marks a single spot with a fixed plant radius around it. Simpler, but less precise about the site's shape.</li></ul><p>Most published de_ maps use <code>func_bomb_target</code> because it lets the plant zone match the level geometry. Pick one approach per site; you do not need both.</p><h2>2. Build a func_bomb_target site</h2><p>Draw a brush covering the area where planting should be allowed — typically a thin box over the floor of the site, tall enough to catch a standing player. Tie that brush to a <code>func_bomb_target</code> entity in the editor. Repeat for the second site. A standard de_ map has <strong>two</strong> bomb sites (A and B); a single-site map is legal but unusual.</p><pre>// conceptually, per site: | |
| 10 | +brush over the plant floor -> tie to entity -> func_bomb_target</pre><h2>3. Give the Terrorists a buyzone</h2><p>The Ts carry the bomb but also need to buy, and buyzones are their own entity. Create a <code>func_buyzone</code> brush over each team's spawn/buy area — one for the T spawn, one for the CT spawn. Without a T-side <code>func_buyzone</code>, Terrorists cannot open the buy menu at all, which is a frequent "buy menu doesn't work on my map" report. Buyzones are brush entities, made the same way as the bomb target: draw the brush, tie it to <code>func_buyzone</code>.</p><h2>4. Tune the rules with info_map_parameters</h2><p>The point entity <code>info_map_parameters</code> controls map-wide objective rules. On a bomb map it lets you set things like whether the bomb can be planted anywhere in a buyzone and the buying behaviour. Place one <code>info_map_parameters</code> in the map and set its keys to match the experience you want; if you leave it out, the map uses engine defaults, which is fine for a standard two-site de_ map. Do not place more than one.</p><h2>5. Make sure the Ts actually get the bomb</h2><p>On a correctly built de_ map with bomb targets present, the game hands the C4 to a random Terrorist at round start automatically — you do not place a bomb entity. If no T ever receives the bomb, the map is missing its bomb-target entities entirely, so the game does not recognise it as a defusal map. This is the tell that step 1 or 2 was skipped.</p><h2>6. Compile and test both sites</h2><p>These are ordinary entities; a normal <a href="/tutorials/zhlt-vhlt-compile-parameters">ZHLT/VHLT compile</a> bakes them in. Load the map, join T, and confirm you receive the bomb and can plant at both A and B but nowhere else.</p><h2>Common errors</h2><ul><li><strong>No Terrorist ever gets the bomb</strong> — the map has no <code>func_bomb_target</code> or <code>info_bomb_target</code>, so the game does not treat it as a defusal map. Add at least one bomb target.</li><li><strong>Can plant everywhere / nowhere</strong> — the <code>func_bomb_target</code> brush is the wrong size, or you used a point <code>info_bomb_target</code> with a radius that is too large or too small. Resize the plant zone.</li><li><strong>Ts cannot open the buy menu</strong> — missing <code>func_buyzone</code> over the T spawn. Add one per team.</li><li><strong>Bomb site not registering the plant</strong> — the brush was left as a normal solid instead of being tied to the entity, so it is just a wall. Re-tie it to <code>func_bomb_target</code>.</li><li><strong>Only one site works</strong> — you built A but forgot to tie B's brush to a second <code>func_bomb_target</code>.</li></ul><h2>Verification</h2><p>Load the map, join Terrorist, and confirm you spawn with the C4 (or receive it as a random T). Walk into site A and confirm the plant prompt appears; plant it. Repeat at site B. Stand outside both sites and confirm you <em>cannot</em> plant there. Join CT and confirm you can defuse a planted bomb. If planting works at both sites and nowhere else, and both teams can buy, the objective layer is complete. Pair this with correct <a href="/tutorials/add-spawns-to-map">player spawns</a> so both teams start in the right place.</p> |
goldsrc-map-optimization-checklist/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "GoldSrc Map Optimization: The Complete Checklist" | |
| 3 | +excerpt: "A practical pass-by-pass checklist for keeping a CS 1.6 map fast and inside engine limits: NULL, func_detail, VIS, hint brushes, texture scale and clip hulls." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "optimization, mapping" | |
| 6 | +image: "" | |
| 7 | +read_time: "9 min read" | |
| 8 | +--- | |
| 9 | +<p>A GoldSrc map runs well when it respects the engine's fixed limits and gives <code>hlvis</code> an easy job. Most performance and "map won't compile" problems trace back to a handful of habits. This is the checklist to run against any CS 1.6 map before release — each item is cheap, and together they keep the map inside the BSP v30 limits and fast on modest hardware.</p><h2>1. NULL every face the player never sees</h2><p>Apply the <code>NULL</code> tool texture to the backs of walls, undersides of floors, tops of skybox brushes, and any hidden brush side. <code>NULL</code> faces are removed at compile: no rendering, no lightmap, less work for every tool. This single habit reduces face count, wpoly, and lightmap usage across the whole map. It is the first thing to check when you hit <a href="/tutorials/fix-allocblock-full">AllocBlock: Full</a>.</p><h2>2. Convert decorative brushwork to func_detail</h2><p>Trim, pipes, rails, signs, clutter, ornamental arches — anything non-structural — should be <code>func_detail</code>. It stays visible and lit but is removed from the BSP tree and from clipnode generation, which cuts face splitting and keeps you clear of <a href="/tutorials/fix-max-map-clipnodes">MAX_MAP_CLIPNODES</a>. Add a <code>CLIP</code> cage where a func_detail shape still needs to block the player.</p><h2>3. Simplify the collision hull with CLIP</h2><p>The player does not need pixel-accurate collision. Wrap complex geometry (rocks, many-sided pillars, terrain) in simple <code>CLIP</code> brushes and let the visual shape be func_detail. Fewer, simpler solid brushes means fewer clipnodes and smoother movement with no snagging.</p><h2>4. Control texture scale for lightmaps</h2><p>Large faces at a small texture scale generate huge lightmaps. Raise the scale on big, low-detail surfaces (ceilings, outer walls, floors under props) to shrink their lightmap footprint, and keep detailed surfaces at <code>1.0</code>. Run a compile with <code>-chart</code> and read the lightmap line:</p><pre>hlrad -chart mymap.bsp</pre><h2>5. Seal the map and kill leaks first</h2><p>VIS optimization is meaningless if the map leaks — a leak makes <code>hlvis</code> either fail or treat the whole level as one visible blob. Confirm a clean compile with no leak, using the pointfile if needed; see <a href="/tutorials/fix-leak-in-hull-pointfile">the leak/pointfile guide</a>. A sealed hull is the precondition for everything below.</p><h2>6. Cut visibility with VIS-aware layout and hint brushes</h2><p>Long unbroken sightlines force the engine to draw huge amounts of the map at once. Break lines of sight with geometry, and place <code>hint</code> brushes (faced with <code>hint</code>, backed by <code>skip</code>) at doorways and corners to split visleafs so the engine culls what is around the corner. This is the core of keeping wpoly low; see <a href="/tutorials/vis-optimization-hint-brushes">VIS optimization with hint brushes</a>. Run the full <code>hlvis</code> pass (not <code>-fast</code>) for the release build.</p><h2>7. Keep entities and wpoly in budget</h2><p>Watch the in-game <code>r_speeds</code>: aim to keep wpoly (world polygons in view) well under a few thousand in the busiest spot on a public server. Merge tiny brushes, remove invisible detail, and avoid huge open rooms full of geometry. Fewer <code>func_</code> entities where a world brush will do also helps, as each entity is drawn separately.</p><h2>8. Final compile discipline</h2><p>Always run the whole chain in order — <code>hlcsg → hlbsp → hlvis → hlrad</code> — for the release, with full VIS and full RAD, and read the <code>-chart</code> output at the end. Vluzacn's VHLT v34 gives the clearest limit report. Fix every warning; a clean log is the goal.</p><h2>Common errors</h2><ul><li><strong>High wpoly / choppy on open maps</strong> — long sightlines and no hint brushes. Break sight lines and add hints.</li><li><strong>Compile hits a limit</strong> — NULL hidden faces and func_detail the clutter; see the <a href="/tutorials/fix-max-map-clipnodes">clipnodes</a> and <a href="/tutorials/fix-allocblock-full">AllocBlock</a> fixes.</li><li><strong>VIS took forever or did nothing</strong> — the map leaks, or you ran <code>-fast</code>. Seal it, then run full VIS.</li><li><strong>Map looks flat after scaling textures</strong> — you scaled detailed faces. Only scale large, low-detail surfaces.</li><li><strong>Player snags on invisible edges</strong> — a CLIP cage is oversized or a func_detail is unexpectedly solid. Tighten the collision.</li></ul><h2>Verification</h2><p>Compile the release build with full VIS and RAD, open the map, and turn on <code>r_speeds 1</code> (or <code>developer 1</code>) to watch wpoly and epoly as you walk the busiest routes. Confirm wpoly stays in budget around corners — if it does not drop when you round a corner, your hint brushes are not splitting visibility there. Check the <code>-chart</code> report shows headroom on faces, clipnodes and lightmaps. Once those numbers are healthy and the log is warning-free, the map is ready to <a href="/tutorials/package-map-for-fastdl">package for FastDL</a>.</p> |
install-cod-mod/en.md
A
| @@ -0,0 +1,63 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Install Call of Duty Mod (CoD MW) on AMX Mod X" | |
| 3 | +excerpt: "How to install the Call of Duty MW mod for CS 1.6: the AMX Mod X modules it needs, placing the plugin and its resources, choosing an XP save backend, and getting levels and perks working." | |
| 4 | +category: "installation" | |
| 5 | +tags: "cod-mod, mods" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>The Call of Duty (CoD MW) mod for CS 1.6 turns the game into a class-and-perk RPG shooter: players earn XP, level up, unlock perks and weapons, and their progress is saved between sessions. It is not a single file — it is an AMX Mod X plugin package with its own modules, models, sounds and a save backend. This walks through a clean install on an existing AMXX server.</p> | |
| 10 | + | |
| 11 | +<h2>1. Have the base stack ready</h2> | |
| 12 | +<p>CoD mod runs on <a href="/tutorials/install-metamod-r">Metamod-r</a> + <a href="/tutorials/install-amx-mod-x-1-9">AMX Mod X 1.9</a>. On ReHLDS/ReGameDLL it is happiest. Confirm AMXX is live before adding anything:</p> | |
| 13 | +<pre>amxx version</pre> | |
| 14 | +<p>CoD mod is a total gameplay conversion, so run it on a dedicated server — do not bolt it onto a normal public running other gameplay mods, or they will fight over the same events and cvars.</p> | |
| 15 | + | |
| 16 | +<h2>2. Load the modules it depends on</h2> | |
| 17 | +<p>The mod calls natives from several AMXX modules, and if any is missing the plugin throws load errors. Enable them in <code>addons/amxmodx/configs/modules.ini</code> — typically:</p> | |
| 18 | +<pre>fun | |
| 19 | +engine | |
| 20 | +fakemeta | |
| 21 | +hamsandwich | |
| 22 | +cstrike | |
| 23 | +csx | |
| 24 | +nvault</pre> | |
| 25 | +<p>If the mod saves XP to MySQL rather than a local vault, it also needs the <code>sqlx</code> (or <code>mysql</code>) module. Confirm they loaded at runtime:</p> | |
| 26 | +<pre>amxx modules</pre> | |
| 27 | +<p>Each must read <code>running</code>. A CoD build that uses <a href="/plugins/csb-multi-jump">extra movement</a> or effects may list more; match the modules to what its documentation asks for.</p> | |
| 28 | + | |
| 29 | +<h2>3. Place the plugin and its includes</h2> | |
| 30 | +<p>Drop the mod's compiled plugins into the plugins folder and any custom include (<code>.inc</code>) into the scripting include folder if you plan to recompile add-ons:</p> | |
| 31 | +<pre>addons/amxmodx/plugins/cod.amxx | |
| 32 | +addons/amxmodx/scripting/include/cod.inc</pre> | |
| 33 | +<p>Then register the main plugin in <code>addons/amxmodx/configs/plugins.ini</code>. CoD mod usually wants to run near the top so its class and XP systems initialise before add-on plugins that hook them — follow its readme for order, and see <a href="/tutorials/plugins-ini-load-order">plugins.ini load order</a> and <a href="/tutorials/install-amxx-plugin-files">installing plugin files</a> for the mechanics.</p> | |
| 34 | + | |
| 35 | +<h2>4. Install the resources</h2> | |
| 36 | +<p>The mod ships models, sprites and sounds for its perks, weapons and effects. Copy the resource tree into <code>cstrike/</code> so the paths line up:</p> | |
| 37 | +<pre>cstrike/models/... | |
| 38 | +cstrike/sound/... | |
| 39 | +cstrike/sprites/...</pre> | |
| 40 | +<p>These are precached on map load and sent to clients, so they must exist server-side and be reachable over <a href="/tutorials/fastdl-setup-guide">FastDL</a>, or players get missing-model errors and silent effects. Keep the folder structure exactly as shipped — the plugin hard-codes those paths.</p> | |
| 41 | + | |
| 42 | +<h2>5. Choose and configure the save backend</h2> | |
| 43 | +<p>Levels are worthless if they reset every map, so the mod persists XP. Two common backends:</p> | |
| 44 | +<ul> | |
| 45 | +<li><strong>nvault (local file)</strong> — zero setup, stores progress in <code>addons/amxmodx/data/vault/</code> keyed by SteamID. Fine for a single server.</li> | |
| 46 | +<li><strong>MySQL</strong> — stores XP in a database so several servers share one progression. Set the host, user, password and database in the mod's config, and load the <code>sqlx</code> module.</li> | |
| 47 | +</ul> | |
| 48 | +<p>Either way, progress is keyed by SteamID, so on a non-Steam server give players stable ids with <a href="/tutorials/install-reunion">Reunion</a> or their levels will scramble. The mod's own config file exposes cvars for max level, XP curve, and which perks are enabled — read that file for the exact names, as they vary by CoD build, rather than guessing.</p> | |
| 49 | + | |
| 50 | +<h2>6. Balance and first-run tuning</h2> | |
| 51 | +<p>CoD mod stands or falls on balance. Two levers matter on day one: the XP curve, which decides how long the grind to max level takes, and the perk set, which decides how lopsided a maxed player is against a fresh one. Start with a gentle curve so new players see progress in their first session and stay, and disable any perk that trivialises combat until you have watched it play. Because everything is XP-gated, a curve that is too steep empties a fresh server faster than a bug will — nobody grinds an empty room. Set <code>mp_startmoney</code> and the round timing in your <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> to suit the mod's pace, and keep a <a href="/plugins/csb-server-adverts">rotating advert</a> explaining the class menu so newcomers are not lost.</p> | |
| 52 | + | |
| 53 | +<h2>Common errors</h2> | |
| 54 | +<ul> | |
| 55 | +<li><strong>Plugin shows <code>bad load</code> or "invalid" in <code>amxx plugins</code></strong> — a required module is not enabled in <code>modules.ini</code>, or the build targets a different AMXX version. Enable the modules and match the version.</li> | |
| 56 | +<li><strong>Everyone starts at level 1 every map</strong> — the save backend is not writing. Check directory permissions on the vault folder, or the MySQL credentials.</li> | |
| 57 | +<li><strong>Missing models / no perk effects</strong> — the resource tree is not in <code>cstrike/</code> or not on FastDL. Restore the exact folder paths.</li> | |
| 58 | +<li><strong>Levels reset or swap between players</strong> — colliding non-Steam SteamIDs. Fix identity with Reunion.</li> | |
| 59 | +<li><strong>Server crashes on map load</strong> — another gameplay mod is loaded alongside CoD. Run CoD on its own server.</li> | |
| 60 | +</ul> | |
| 61 | + | |
| 62 | +<h2>Verification</h2> | |
| 63 | +<p>Start the server and run <code>amxx plugins</code> — the CoD plugin must read <code>running</code>. Join, confirm the class/perk menu appears, get a kill and watch XP increase, then reconnect and confirm your level and XP survived. If progression persists across a reconnect and a map change, the save backend and identity are correct and the mod is fully installed.</p> |
install-deathrun-mod/en.md
A
| @@ -0,0 +1,49 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Set Up a Deathrun Server (CS 1.6)" | |
| 3 | +excerpt: "Build a Deathrun server on AMX Mod X: install the manager plugin, load deathrun maps, and tune the activator, traps and round flow for the mode." | |
| 4 | +category: "installation" | |
| 5 | +tags: "deathrun, mods" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Deathrun is a one-versus-many mode: a single terrorist — the "activator" or death — triggers traps along an obstacle course while the counter-terrorists race to the end. It is built entirely on <a href="/tutorials/install-amx-mod-x-1-9">AMX Mod X</a> plus purpose-made maps; there is no separate engine mod to compile. This sets up a clean Deathrun server from a working CS install.</p> | |
| 10 | +<h2>1. Start from a working AMXX server</h2> | |
| 11 | +<p>Deathrun assumes Metamod and AMX Mod X are already running. Confirm:</p> | |
| 12 | +<pre>meta list | |
| 13 | +amxx version</pre> | |
| 14 | +<p>If AMX Mod X is not installed, do that first — the Deathrun plugin is an ordinary AMXX plugin and needs the framework beneath it.</p> | |
| 15 | +<h2>2. Install the Deathrun manager plugin</h2> | |
| 16 | +<p>Deathrun logic — picking the activator, managing traps, showing the HUD — lives in a manager plugin. Place its <code>.amxx</code> in <code>addons/amxmodx/plugins/</code> and register it:</p> | |
| 17 | +<pre>deathrun.amxx</pre> | |
| 18 | +<p>Add that line to <code>addons/amxmodx/configs/plugins.ini</code>. The general procedure is in <a href="/tutorials/install-amxx-plugin-files">installing AMXX plugin files</a>. Our maintained implementation is <a href="/plugins/csb-deathrun-manager">CSB Deathrun Manager</a>, which handles activator selection, glow, and reserved-slot fairness in one plugin.</p> | |
| 19 | +<h2>3. Install Deathrun maps</h2> | |
| 20 | +<p>Deathrun needs maps built for it — long linear courses with button-triggered traps, named with the <code>deathrun_</code> (or <code>dr_</code>) prefix. Place the <code>.bsp</code> files in <code>cstrike/maps/</code> and add them to your rotation:</p> | |
| 21 | +<pre>cstrike/maps/deathrun_castle.bsp | |
| 22 | +cstrike/maps/deathrun_temple.bsp</pre> | |
| 23 | +<p>Add each map to <code>mapcycle.txt</code>. Standard CS maps do not work as Deathrun — they have no trap entities. Distribute the maps to players over FastDL as in <a href="/tutorials/install-custom-maps-cs16-server">installing custom maps</a>, or players download them slowly on join.</p> | |
| 24 | +<h2>4. Tune the round flow for the mode</h2> | |
| 25 | +<p>Deathrun plays badly with default round settings. In <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a>:</p> | |
| 26 | +<pre>mp_freezetime 3 | |
| 27 | +mp_roundtime 5 | |
| 28 | +mp_buytime 0 | |
| 29 | +mp_startmoney 0 | |
| 30 | +mp_autoteambalance 0 | |
| 31 | +mp_limitteams 0</pre> | |
| 32 | +<p>The key ones: disable auto team balance and team limits, because Deathrun deliberately runs one terrorist against many CTs — leave balancing on and the engine constantly fights the plugin's team assignment. Zero buy time and money because there is no buying in Deathrun.</p> | |
| 33 | +<h2>5. Handle the activator</h2> | |
| 34 | +<p>The manager plugin chooses one player as the terrorist each round and moves everyone else to CT. Configure its behavior through the plugin's own cvars (typically in a <code>deathrun.cfg</code> the plugin creates on first run) — things like activator glow, reserved-slot priority, and whether the previous death can be picked again. If your plugin supports it, enable a glow on the activator so racers can see who controls the traps.</p> | |
| 35 | +<h2>6. Optional respawn and quality-of-life</h2> | |
| 36 | +<p>Many Deathrun servers keep dead players as spectators until the round ends, which is default. If you want late joiners to enter the current round, <a href="/plugins/csb-respawn-on-join">CSB Respawn on Join</a> handles that cleanly. Advertise the map's mechanics with a <a href="/plugins/csb-server-adverts">server-adverts plugin</a> so new players know how the traps work. Manage admins and map votes with <a href="/plugins/csb-admin-menu">CSB Admin Menu</a>.</p> | |
| 37 | +<h2>How a Deathrun round actually plays</h2> | |
| 38 | +<p>It helps to know the flow the plugin enforces, because it explains the cvar choices above. At round start the manager picks one player and forces them to the terrorist team — the activator — and puts everyone else on CT. The CTs spawn at the start of the course and must run to the finish; the activator runs a parallel path lined with buttons that trigger the map's traps — crushers, spike floors, moving platforms — timed to catch racers. Because exactly one player must be T and the rest CT, any engine feature that reshuffles teams — auto-balance, team limits, or a scramble plugin — actively fights the mode, which is why you disable them. The activator is deliberately outnumbered; the balance comes from map design, not team size, so the usual "fairness" cvars are exactly wrong here.</p> | |
| 39 | +<h2>Reward the winner</h2> | |
| 40 | +<p>Most Deathrun maps end with a final one-on-one arena or a "free day" where the last surviving CT fights the activator directly. Some manager plugins grant the round-winning racer a reward — extra health, a weapon, or the right to be activator next round — configurable in the plugin's <code>deathrun.cfg</code>. Decide whether winning should be its own reward or carry a mechanical bonus; a small perk keeps players pushing to finish the course rather than hanging back.</p> | |
| 41 | +<h2>Troubleshooting</h2> | |
| 42 | +<ul> | |
| 43 | +<li><strong>Everyone is on the same team / no activator picked</strong> — auto team balance is on. Set <code>mp_autoteambalance 0</code> and <code>mp_limitteams 0</code>.</li> | |
| 44 | +<li><strong>Traps do nothing</strong> — the map is a standard CS map, not a Deathrun map. Only <code>deathrun_</code>/<code>dr_</code> maps have trap entities.</li> | |
| 45 | +<li><strong>Plugin shows <code>bad load</code></strong> in <code>amxx plugins</code> — wrong AMXX version or a missing module. Recompile or install the matching build.</li> | |
| 46 | +<li><strong>Players cannot download the map</strong> — FastDL is not serving it. See <a href="/tutorials/fix-fastdl-not-working">FastDL not working</a>.</li> | |
| 47 | +</ul> | |
| 48 | +<h2>Verification</h2> | |
| 49 | +<p>Load a <code>deathrun_</code> map with a couple of test clients. Confirm the plugin picks exactly one terrorist, moves the rest to CT, and that pressing a trap button kills or blocks racers as designed. Run <code>amxx plugins</code> and check the manager reads <code>running</code>. If one death faces a team of racers on a trap map without the engine reshuffling teams, your Deathrun server is set up correctly.</p> |
install-rehlds-regamedll-reapi-stack/en.md
A
| @@ -0,0 +1,45 @@ | ||
| 1 | +--- | |
| 2 | +title: "The Modern CS 1.6 Stack: ReHLDS + ReGameDLL + Metamod-r + AMXX" | |
| 3 | +excerpt: "How ReHLDS, ReGameDLL, Metamod-r, AMX Mod X, and ReAPI stack up, why the install order matters, and how to verify the whole chain." | |
| 4 | +category: "installation" | |
| 5 | +tags: "rehlds, regamedll, stack" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>"The modern stack" is the combination most competitive and feature-rich CS 1.6 servers run today: <strong>ReHLDS</strong> (a faster, maintained engine), <strong>ReGameDLL_CS</strong> (an open reimplementation of the game logic), <strong>Metamod-r</strong>, <strong>AMX Mod X</strong>, and <strong>ReAPI</strong> (an AMXX module exposing ReHLDS/ReGameDLL hooks). Each replaces or extends a stock component, and they must go on in the right order because each depends on the one below it. This guide is the map of the whole stack; each layer links to its detailed install.</p> | |
| 10 | +<h2>1. The layers, bottom to top</h2> | |
| 11 | +<table> | |
| 12 | +<thead><tr><th>Layer</th><th>Replaces / adds</th><th>Depends on</th></tr></thead> | |
| 13 | +<tbody> | |
| 14 | +<tr><td>ReHLDS</td><td>the engine (<code>engine_i486.so</code> / <code>swds.dll</code>)</td><td>—</td></tr> | |
| 15 | +<tr><td>ReGameDLL_CS</td><td>game logic (<code>cs.so</code> / <code>mp.dll</code>)</td><td>ReHLDS (recommended)</td></tr> | |
| 16 | +<tr><td>Metamod-r</td><td>plugin loader between engine and game DLL</td><td>engine + game DLL</td></tr> | |
| 17 | +<tr><td>AMX Mod X</td><td>admin + Pawn plugin system</td><td>Metamod</td></tr> | |
| 18 | +<tr><td>ReAPI</td><td>AMXX module exposing Re* hooks</td><td>ReGameDLL + AMXX</td></tr> | |
| 19 | +</tbody> | |
| 20 | +</table> | |
| 21 | +<p>Install in that order. Skipping a layer or reversing the order is the root of most "it half-works" problems — ReAPI in particular does nothing without ReGameDLL underneath it.</p> | |
| 22 | +<h2>2. ReHLDS — the engine</h2> | |
| 23 | +<p>Replace the stock GoldSrc engine with ReHLDS first. It is a drop-in binary swap and everything else assumes it is present. Follow <a href="/tutorials/install-rehlds-on-linux">install ReHLDS on Linux</a> (or the Windows guide). Verify the server still boots on the new engine before moving on — a broken engine swap is far easier to spot now than after four more layers are on top.</p> | |
| 24 | +<h2>3. ReGameDLL_CS — the game logic</h2> | |
| 25 | +<p>ReGameDLL replaces <code>cs.so</code> / <code>mp.dll</code>, the DLL that implements rounds, buying, bomb logic and the cvars stock CS lacks (<code>mp_maxrounds</code>, <code>mp_winlimit</code> and many more). Install it per <a href="/tutorials/install-regamedll-cs16">the ReGameDLL guide</a>. Two things make ReGameDLL worth it: it fixes long-standing gameplay bugs, and it is the component ReAPI hooks into. Without ReGameDLL, ReAPI has no game to talk to.</p> | |
| 26 | +<h2>4. Metamod-r — the loader</h2> | |
| 27 | +<p>Metamod sits between the engine and the game DLL and loads plugins. Point <code>liblist.gam</code>'s <code>gamedll</code> line at Metamod and it loads the real game DLL plus its plugin list. Use <a href="/tutorials/install-metamod-r">Metamod-r</a> rather than the legacy build on this stack — the reasoning is in <a href="/tutorials/metamod-r-vs-metamod-p">Metamod-r vs Metamod-P</a>. Metamod-r is compatible with ReHLDS and the Re* components in a way older Metamod builds are not always.</p> | |
| 28 | +<h2>5. AMX Mod X — the plugin system</h2> | |
| 29 | +<p>AMXX loads as a Metamod plugin (its line in <code>addons/metamod/plugins.ini</code> points at <code>amxmodx_mm_i386.so</code> on Linux). It gives you admin commands, menus and the whole Pawn plugin ecosystem. Install <a href="/tutorials/install-amx-mod-x-1-9">AMX Mod X 1.9</a>, the safe default version. AMXX's own plugins are then listed in a <em>separate</em> <code>addons/amxmodx/configs/plugins.ini</code> — do not confuse it with Metamod's file of the same name; the difference is explained in <a href="/tutorials/metamod-plugins-ini-explained">metamod/plugins.ini explained</a>.</p> | |
| 30 | +<h2>6. ReAPI — the hooks</h2> | |
| 31 | +<p>ReAPI is an AMXX module (not a standalone plugin) that exposes ReHLDS and ReGameDLL functions to Pawn plugins through <code>RegisterHookChain</code>. Enable it as covered in <a href="/tutorials/install-reapi">install ReAPI</a> by adding it to <code>addons/amxmodx/configs/modules.ini</code>. Any plugin that <code>#include <reapi></code> now works — but only because ReGameDLL is underneath providing the functions ReAPI wraps. This is why the whole stack is a chain: ReAPI at the top is only meaningful because of ReGameDLL near the bottom.</p> | |
| 32 | +<h2>Troubleshooting</h2> | |
| 33 | +<ul> | |
| 34 | +<li><strong>ReAPI natives error / plugins using reapi fail</strong> — ReGameDLL is not installed or not loaded. ReAPI requires it; confirm the game DLL is ReGameDLL, not stock.</li> | |
| 35 | +<li><strong>Server boots stock despite the swaps</strong> — a layer's files went to the wrong path. Verify each replacement individually, bottom-up, before stacking the next.</li> | |
| 36 | +<li><strong>Metamod loads but AMXX does not</strong> — AMXX's line is missing from Metamod's <code>plugins.ini</code>; see <a href="/tutorials/fix-meta-list-no-amxx">meta list has no AMXX</a>.</li> | |
| 37 | +<li><strong>Crashes after adding ReGameDLL</strong> — a version mismatch between ReHLDS and ReGameDLL, or you kept the stock engine. Match compatible builds and confirm ReHLDS is active.</li> | |
| 38 | +<li><strong>Everything loads but old plugins misbehave</strong> — some very old plugins assume stock game behaviour ReGameDLL changed. Update them or check their ReGameDLL compatibility.</li> | |
| 39 | +</ul> | |
| 40 | +<h2>Verification</h2> | |
| 41 | +<p>Verify the chain from the console after a map load:</p> | |
| 42 | +<pre>meta list | |
| 43 | +amxx modules | |
| 44 | +amxx plugins</pre> | |
| 45 | +<p><code>meta list</code> should show AMXX running; <code>amxx modules</code> should list <code>reapi</code> as <code>running</code>; <code>amxx plugins</code> should show your plugins loaded, including any that use ReAPI. Confirm a ReGameDLL-only cvar such as <code>mp_maxrounds</code> is recognised (it returns a value rather than "unknown command"). When all of those pass, the modern stack is fully wired.</p> |
valve-master-servers-explained/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Valve Master Servers: How Server Listing Actually Works" | |
| 3 | +excerpt: "The full path from your server heartbeating the Valve master to a player seeing you in the browser, the cvars and token that matter, and why a server goes missing from the list." | |
| 4 | +category: "misc" | |
| 5 | +tags: "master-server, listing" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A server does not "appear" in the CS 1.6 browser by magic — it advertises itself to a <strong>master server</strong>, and clients ask that master for the list. When your server vanishes from the browser, one link in that chain is broken. Here is exactly how listing works and what each requirement is for.</p><h2>1. The two halves: heartbeat and query</h2><p>Server listing is a two-step system:</p><ol><li><strong>Heartbeat (server → master).</strong> Your server periodically sends a small UDP packet to Valve's master server announcing "I exist, here is my address." The master records it in a live list.</li><li><strong>Query (client → master → server).</strong> When a player opens the internet tab, the client asks the master for the list of servers. The master returns addresses; the client then sends an <strong>A2S_INFO</strong> query directly to each server to fetch its name, map, and player count for the browser row.</li></ol><p>So the master is a directory, not a proxy. It knows your address because you heartbeat it; the actual server details the player sees come from your server answering A2S queries directly.</p><h2>2. What your server needs to heartbeat successfully</h2><p>For the heartbeat to land and the listing to stick, three things must be true:</p><ul><li><strong><code>sv_lan 0</code></strong> — with <code>sv_lan 1</code> the server considers itself LAN-only and never heartbeats the internet master. This is the number-one reason a server is missing from the public list.</li><li><strong>A valid Steam Game Server login token</strong> — modern listing expects the server to authenticate. You set it with the launch parameter:</li></ul><pre>-sv_setsteamaccount YOUR_GSLT_TOKEN</pre><p>You generate the token (a GSLT) from Valve's Game Server Account management page. Some setups still list anonymously, but a valid token is the reliable path and avoids anonymous-listing limits.</p><ul><li><strong>Correct outbound UDP</strong> — the heartbeat is UDP leaving your box to Valve's master. A firewall or NAT that blocks outbound UDP, or that does not forward the server's own port back, stops both the heartbeat and the client's A2S query. Default game port is <strong>UDP 27015</strong>; it must be reachable inbound for the A2S_INFO step too.</li></ul><h2>3. The master server list on the server side</h2><p>The engine ships with a list of master server addresses it heartbeats to. If Valve rotates a master hostname/IP, an old server binary can end up heartbeating a dead address and silently drop off every browser. This is what the <a href="/tutorials/cs16-masterserver-vdf">master server VDF file</a> handles — it lets you point the engine at current master addresses. On a ReHLDS server this is a common fix after Valve infrastructure changes.</p><h2>4. Putting the chain together</h2><p>For a player to see and join you, all of this must hold at once: <code>sv_lan 0</code>, a working token, outbound UDP for the heartbeat, a current master address list, and inbound UDP 27015 so the client's A2S_INFO reaches you. Break any one and the symptom is the same — "my server isn't in the list" — even though the cause differs. That is why the fix is a checklist, walked in <a href="/tutorials/fix-server-not-in-master-list">fixing a server missing from the master list</a>.</p><h2>Common misconceptions</h2><ul><li><strong>"The master server hosts my server info."</strong> No — the master only stores your address. Your server answers the A2S query directly with its name/map/players.</li><li><strong>"I can connect by IP, so listing works."</strong> Direct connect bypasses the master entirely. Being joinable by IP proves inbound works but says nothing about the heartbeat; you can be fully playable and still invisible in the browser.</li><li><strong>"sv_lan doesn't matter on a public box."</strong> It matters most there — <code>sv_lan 1</code> suppresses the internet heartbeat completely.</li><li><strong>"A token is optional."</strong> Anonymous listing exists but is limited; a GSLT via <code>-sv_setsteamaccount</code> is the dependable route.</li><li><strong>"Missing from the list = server crashed."</strong> Usually it is running fine and just not heartbeating — check <code>sv_lan</code>, the token, and the master addresses before assuming a crash.</li></ul><h2>How to check on your server</h2><p>First confirm the basics in the console:</p><pre>sv_lan | |
| 10 | +heartbeat</pre><p><code>sv_lan</code> must read <code>0</code>; <code>heartbeat</code> forces an immediate announce to the master so you do not wait for the timer. Then verify from <em>outside</em> your network — have someone use the internet tab and search your server name, or query the address with an external A2S tool, to prove both the listing and the direct query path work. If you are joinable by IP but never appear in the browser, the heartbeat side is the culprit: re-check <code>sv_lan 0</code>, the <code>-sv_setsteamaccount</code> token, outbound UDP, and the <a href="/tutorials/cs16-masterserver-vdf">master address list</a>.</p> | |
| 0 | 11 |
