Add 6 tutorials (6 files)
Browse Source
Daemon666 committed
parent 489d5597a7
commit ef6a965ac3bc9d41d4b21e4f6b0d904f61b1d2ae
6 changed files
with 194 additions and 0 deletions
A
cs16-map-lighting-basics/en.md
+11 -0
A
install-cs16-server-anticheat/en.md
+44 -0
A
install-gungame-mod/en.md
+62 -0
A
install-warcraft3-ft-mod/en.md
+43 -0
A
light-environment-and-sky/en.md
+17 -0
A
what-is-regamedll/en.md
+17 -0
cs16-map-lighting-basics/en.md
A
| @@ -0,0 +1,11 @@ | ||
| 1 | +--- | |
| 2 | +title: "Lighting a CS 1.6 Map (light and light_environment)" | |
| 3 | +excerpt: "How GoldSrc lighting works: point lights, spotlights, the single light_environment sun tied to your sky, texture lights, and why hlrad bakes it all into lightmaps at compile time." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "lighting, rad" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Lighting in a GoldSrc map is not real-time — it is <strong>baked</strong>. The <code>hlrad</code> compile stage calculates how light bounces around your level and writes the result into lightmaps stored in the BSP. That means every lighting change requires a recompile, and it means a map with no light entities compiles <em>fullbright</em>: flat, shadowless, and obviously unfinished. This covers the entities you place and how they interact. It assumes you can already compile with <a href="/tutorials/zhlt-vhlt-compile-parameters">ZHLT/VHLT parameters</a>.</p><h2>1. The light entity (point light)</h2><p>The workhorse is <code>light</code> — a point that emits in all directions. Its key values:</p><pre>classname light | |
| 10 | +_light 255 255 200 300 // R G B brightness | |
| 11 | +</pre><p>The first three numbers are the colour (0–255 each), the fourth is brightness. Warm interior light might be <code>255 200 150</code>; a cold fluorescent <code>200 220 255</code>. Place a <code>light</code> under each lamp, in each room that needs fill, and anywhere a dark corner needs lifting. Brightness falls off with distance, so a big room needs several.</p><h2>2. The light_spot (directional cone)</h2><p><code>light_spot</code> emits a cone in a direction — a spotlight, a downlight, a lamp with a shade. Beyond the colour/brightness of a <code>light</code>, it adds a direction (aim it with the angle or a target) and inner/outer cone angles that control the hard and soft edges of the pool. Use it for focused pools under fixtures where an omni <code>light</code> would spill everywhere.</p><h2>3. The light_environment (the sun)</h2><p><code>light_environment</code> is the outdoor sun and skylight, and there must be <strong>exactly one per map</strong>. It works together with your <code>sky</code>-textured brushes: <code>hlrad</code> casts sunlight <em>through</em> every sky-textured face into the level, so wherever the player can see the skybox, sunlight falls in. Its keys set the sun colour/brightness, the <em>pitch</em> (how high the sun sits) and the <em>angle</em> (compass direction the light comes from), plus a separate ambient skylight colour for the diffuse fill in shadow. One <code>light_environment</code> plus sky brushes gives you directional sun and soft ambient in a single entity.</p><h2>4. Texture lights (surfaces that glow)</h2><p>Any texture can be made to emit light via the <code>lights.rad</code> file that <code>hlrad</code> reads — you list a texture name and an RGB+brightness, and every face using that texture becomes a light source. This is how ceiling light panels, glowing screens, and neon signs illuminate a room realistically, because the light comes from the whole surface rather than a point. It is the cleanest way to light large flat fixtures.</p><h2>5. Let hlrad bounce the light</h2><p>The reason baked lighting looks good is radiosity: <code>hlrad</code> bounces light off surfaces so a bright floor lifts the walls above it. Higher-quality <code>hlrad</code> settings (more bounces, finer sampling) give softer, more realistic results at the cost of compile time. During iteration, run fast/low-quality RAD to preview placement; do a full-quality RAD only for the final compile. Every change to any light entity means re-running RAD — nothing about lighting updates without a recompile.</p><h2>6. Avoid fullbright and pure black</h2><p>Two failure states bracket good lighting. <strong>Fullbright</strong> (everything evenly lit, no shadows) means <code>hlrad</code> found no lights or was skipped — add at least one light entity and run RAD. <strong>Pitch black</strong> areas mean no light reaches there — add fill lights or raise the ambient on the <code>light_environment</code>. Aim for contrast with detail visible in the shadows, not crushed black.</p><h2>Common errors</h2><ul><li><strong>Map is fullbright</strong> — no light entities exist, or <code>hlrad</code> did not run. Add lights and run the RAD stage of the compile.</li><li><strong>Outdoors is dark despite a sun</strong> — the sky brushes are not textured with the <code>sky</code> texture, so sunlight has nowhere to enter, or you have no <code>light_environment</code>.</li><li><strong>Weird double shadows / no sun direction</strong> — more than one <code>light_environment</code>. Delete extras; there must be exactly one.</li><li><strong>Lighting looks flat and blotchy</strong> — you ran fast/low RAD. Do a full-quality RAD for release.</li><li><strong>Changed a light but nothing updated in-game</strong> — you did not recompile. Lightmaps are baked; re-run the compile.</li></ul><h2>Verification</h2><p>Compile with a full RAD pass and load the map. Confirm nothing is fullbright, that outdoor areas under sky brushes get directional sun with soft ambient in shadow, and that interior lights cast believable pools with visible detail in the darker corners. Walk the whole map for pure-black spots and add fill where needed. If the outdoors is dark, check that your skybox brushes use the <code>sky</code> texture and that you have one working <code>light_environment</code>. For sky and sun specifics, see <a href="/tutorials/light-environment-and-sky">light_environment and sky</a>.</p> |
install-cs16-server-anticheat/en.md
A
| @@ -0,0 +1,44 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Add an Anti-Cheat to Your CS 1.6 Server (2026 Options)" | |
| 3 | +excerpt: "A realistic look at CS 1.6 anti-cheat in 2026: what VAC does and does not cover, the server-side statistical detection plugins that actually help, and how to combine detection with review." | |
| 4 | +category: "installation" | |
| 5 | +tags: "anticheat, security" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>There is no single button that makes a CS 1.6 server cheat-proof — the engine is old, the client is open, and non-Steam clients are unverified by design. What you can do is layer defences: understand what VAC covers, run server-side detection plugins that flag the common cheats, and back them with human review. This lays out the realistic 2026 options.</p> | |
| 10 | + | |
| 11 | +<h2>1. Understand what VAC does and does not cover</h2> | |
| 12 | +<p>VAC (Valve Anti-Cheat) only applies to genuine Steam clients connecting through Steam. It is delayed and opaque — bans come in waves, not in real time — and it does <strong>nothing</strong> for non-Steam players, who are the majority on most community servers. So if you run a non-Steam or mixed server behind <a href="/tutorials/install-reunion">Reunion</a> or <a href="/tutorials/configure-dproto-cfg">dproto</a>, treat VAC as absent and rely entirely on the server-side tools below.</p> | |
| 13 | + | |
| 14 | +<h2>2. Statistical detection: the ATAC approach</h2> | |
| 15 | +<p>The workhorse of CS 1.6 anti-cheat is statistical detection — a plugin that watches each player's shots and flags patterns no human produces. Our implementation is <a href="/plugins/csb-atac">CSB ATAC</a>, which tracks aim behaviour and warns admins when a player's numbers cross a threshold. It cannot see the client's memory, so it infers from behaviour: it will not catch a careful cheater instantly, but it reliably surfaces blatant ones for review. Install it like any <a href="/tutorials/install-amxx-plugin-files">AMXX plugin</a> and set its sensitivity conservatively at first so you are not drowning in false positives.</p> | |
| 16 | + | |
| 17 | +<h2>3. Aimbot detection</h2> | |
| 18 | +<p>Aimbots betray themselves through impossible aim: instant snaps to the head, tracking through walls before line of sight, superhuman consistency. <a href="/plugins/csb-aimbot-detect">CSB Aimbot Detect</a> watches for those signatures and raises a flag with the evidence for an admin to confirm. Use it as an early-warning system, not an auto-ban — a good movement player can trip a naive detector, which is why the flag should route to a human.</p> | |
| 19 | + | |
| 20 | +<h2>4. Wallhack and speedhack detection</h2> | |
| 21 | +<p>Two more common cheats have their own detectors:</p> | |
| 22 | +<ul> | |
| 23 | +<li><strong>Wallhack</strong> — <a href="/plugins/csb-wallhack-blocker">CSB Wallhack Blocker</a> reduces the information a wallhack can use (limiting what the server tells a client about players it should not yet see) and flags the tell-tale pre-aim through geometry.</li> | |
| 24 | +<li><strong>Speedhack</strong> — <a href="/plugins/csb-speedhack-detect">CSB Speedhack Detect</a> watches for movement and command rates that exceed what the engine should allow, the classic sign of a speed or command-rate cheat.</li> | |
| 25 | +</ul> | |
| 26 | +<p>Neither is perfect — determined cheaters adapt — but together they catch the drive-by scripts that make up most of what a public server actually faces.</p> | |
| 27 | + | |
| 28 | +<h2>5. Close the exploit surface too</h2> | |
| 29 | +<p>Cheating is not only aimbots. Malformed-packet exploits crash or hang an unprotected server, and that is a denial-of-service, not a gameplay cheat. Run <a href="/plugins/csb-anti-hlds-exploit">CSB Anti-HLDS-Exploit</a> to block the well-known engine exploits, and lock down the box itself — RCON password, firewalled ports (see <a href="/tutorials/cs16-server-firewall-ports">firewall ports</a>). A server that can be crashed does not need a cheater to be ruined.</p> | |
| 30 | + | |
| 31 | +<h2>6. Detection is half the job — review is the other half</h2> | |
| 32 | +<p>No CS 1.6 detector is trustworthy enough to auto-ban without a human, so build a review habit. When a plugin flags a player, spectate them, and if the demo matters, record it from your own client while following them — the file lets you review whether their aim tracks enemies through walls before line of sight. Cross-reference the flag with the server logs to tie it to a <a href="/tutorials/install-reunion">SteamID</a>, then ban with persistence. The detectors surface suspects; you and the demo make the call. That combination — automated flags plus human confirmation — is the honest state of the art on this engine.</p> | |
| 33 | + | |
| 34 | +<h2>Common errors</h2> | |
| 35 | +<ul> | |
| 36 | +<li><strong>Expecting VAC to protect a non-Steam server</strong> — it does not apply. Use server-side detection.</li> | |
| 37 | +<li><strong>Auto-banning on a detector flag</strong> — false positives ban good players. Route flags to a human.</li> | |
| 38 | +<li><strong>Detector sensitivity too high</strong> — a flood of false positives that admins learn to ignore. Start conservative and tighten.</li> | |
| 39 | +<li><strong>Only chasing aimbots</strong> — wallhack, speedhack and packet exploits go unhandled. Layer all of them.</li> | |
| 40 | +<li><strong>Bans keyed to colliding non-Steam ids</strong> — a shared id means banning one player blocks another. Fix identity with <a href="/tutorials/configure-reunion-cfg">Reunion</a> first.</li> | |
| 41 | +</ul> | |
| 42 | + | |
| 43 | +<h2>Verification</h2> | |
| 44 | +<p>Load the detection plugins and confirm they read <code>running</code> in <code>amxx plugins</code>. Set their sensitivity, then watch a normal session — a well-tuned setup should flag rarely and only on genuinely suspicious play. When a flag fires, spectate the player and confirm the plugin's judgement against what you see. If the detectors surface real suspects without burying admins in noise, and the exploit-blocker is live, your layered anti-cheat is working as well as this engine allows.</p> |
install-gungame-mod/en.md
A
| @@ -0,0 +1,62 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Install GunGame on CS 1.6" | |
| 3 | +excerpt: "Install the GunGame AMX Mod X plugin, set the weapon progression, enable respawning, and tune the leveling rules for a fast, addictive server." | |
| 4 | +category: "installation" | |
| 5 | +tags: "gungame, mods" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>GunGame is the mode that made a generation of players stay "one more round": every kill levels you up to the next weapon, from pistols through rifles to a final knife or grenade kill that wins the map. It is an <a href="/tutorials/install-amx-mod-x-1-9">AMX Mod X</a> plugin — no engine mod required — and the whole feel of the server comes down to the weapon order and the respawn settings. Here is a clean install.</p> | |
| 10 | +<h2>1. Confirm AMX Mod X is running</h2> | |
| 11 | +<pre>meta list | |
| 12 | +amxx version</pre> | |
| 13 | +<p>GunGame is an ordinary AMXX plugin and needs Metamod plus AMX Mod X already working. Install those first if <code>amxx version</code> returns nothing.</p> | |
| 14 | +<h2>2. Install the GunGame plugin</h2> | |
| 15 | +<p>Place the plugin binary in the plugins folder and register it:</p> | |
| 16 | +<pre>cstrike/addons/amxmodx/plugins/gungame.amxx</pre> | |
| 17 | +<p>Add the line to <code>addons/amxmodx/configs/plugins.ini</code>:</p> | |
| 18 | +<pre>gungame.amxx</pre> | |
| 19 | +<p>The general steps are in <a href="/tutorials/install-amxx-plugin-files">installing AMXX plugin files</a>. Our maintained build is <a href="/plugins/csb-gungame">CSB GunGame</a>, which packages the leveling, HUD and weapon-order handling together.</p> | |
| 20 | +<h2>3. Define the weapon progression</h2> | |
| 21 | +<p>The heart of GunGame is the ordered list of weapons players climb through. Most implementations read this from a config or a weapons-order file — typically a list of weapon names, one per level, ending with the knife:</p> | |
| 22 | +<pre>usp | |
| 23 | +glock18 | |
| 24 | +deagle | |
| 25 | +mp5navy | |
| 26 | +ump45 | |
| 27 | +m4a1 | |
| 28 | +ak47 | |
| 29 | +awp | |
| 30 | +knife</pre> | |
| 31 | +<p>Order it however suits your server — a short 8-level ladder for fast games, or a long 20+ level climb for a grind. The final level is conventionally a <strong>knife</strong> kill: reaching it and getting one more kill wins the map, which is what makes the last level so tense.</p> | |
| 32 | +<h2>4. Enable respawning</h2> | |
| 33 | +<p>GunGame is unplayable without instant respawn — players must jump straight back in after dying to keep leveling. Enable respawning through the plugin's cvars (in <code>amxx.cfg</code> or the plugin's own config), and disable the normal round economy so nobody buys:</p> | |
| 34 | +<pre>mp_freezetime 0 | |
| 35 | +mp_buytime 0 | |
| 36 | +mp_startmoney 0 | |
| 37 | +mp_roundtime 9</pre> | |
| 38 | +<p>If your GunGame build does not include respawn, pair it with <a href="/plugins/csb-respawn-on-join">CSB Respawn on Join</a> or a dedicated respawn plugin. The relevant round cvars are covered in <a href="/tutorials/essential-server-cvars">essential server cvars</a>.</p> | |
| 39 | +<h2>5. Tune the leveling rules</h2> | |
| 40 | +<p>Through the plugin's cvars you control the details that shape the mode:</p> | |
| 41 | +<ul> | |
| 42 | +<li><strong>Knife-steal / level-down</strong> — a knife kill on an enemy knocks them down a level, a classic GunGame rule that keeps leaders honest.</li> | |
| 43 | +<li><strong>HE-grenade level</strong> — some servers add a grenade level before the knife for a skill spike.</li> | |
| 44 | +<li><strong>Level-up bonus</strong> — refill HP or give a brief effect on leveling to reward momentum.</li> | |
| 45 | +</ul> | |
| 46 | +<p>Set these to match your audience; a competitive crowd likes knife-steal, a casual one may find it frustrating.</p> | |
| 47 | +<h2>6. Change the map to load it</h2> | |
| 48 | +<pre>changelevel de_dust2</pre> | |
| 49 | +<p><code>plugins.ini</code> and configs are read at map load, so restart or change the map after editing. Advertise the <code>/gungame</code> style help and rules with a <a href="/plugins/csb-server-adverts">server-adverts plugin</a> so newcomers understand the level ladder.</p> | |
| 50 | +<h2>7. Team play, free-for-all, and objectives</h2> | |
| 51 | +<p>GunGame can run team-based or free-for-all, and the choice shapes everything. In team mode the normal T/CT sides remain, and you level up by killing the other team — simple and familiar. In free-for-all every player is an enemy, which most implementations achieve by disabling friendly-fire protection and treating teammates as targets; it is the purer GunGame experience but needs the plugin to support FFA cleanly. Whichever you pick, you also want to neutralize the map objective: on a <code>de_</code> map the bomb is irrelevant to GunGame and a planted bomb ending the round early disrupts the leveling, so most GunGame configs run on <code>aim_</code> or <code>fy_</code> maps, or disable the objective. Pick maps with tight, open sightlines — GunGame is about constant fragging, and sprawling objective maps kill the pace.</p> | |
| 52 | +<h2>8. Balance the weapon ladder</h2> | |
| 53 | +<p>The single biggest tuning lever is the weapon order itself. Front-loading hard weapons — putting a low-damage pistol or the AWP early — creates skill walls where weaker players stall, while a smooth ramp from easy to hard keeps everyone climbing. A good default eases players in with forgiving weapons, spikes difficulty in the middle, and reserves the knife for last so the win always demands a close-range kill under pressure. Test your ladder with real players and move any weapon that becomes a persistent bottleneck; a ladder nobody can finish is not fun, and one everybody blitzes through has no tension.</p> | |
| 54 | +<h2>Troubleshooting</h2> | |
| 55 | +<ul> | |
| 56 | +<li><strong>Players do not level up on kills</strong> — the plugin loaded but the weapon-order config is empty or unreadable. Check <code>amxx plugins</code> shows <code>gungame.amxx</code> as <code>running</code> and that the order file exists.</li> | |
| 57 | +<li><strong>No respawn, everyone waits out the round</strong> — respawn is disabled. Enable it in the plugin cvars or add a respawn plugin.</li> | |
| 58 | +<li><strong>Buy menu still appears</strong> — buy time and start money are non-zero. Set <code>mp_buytime 0</code> and <code>mp_startmoney 0</code>.</li> | |
| 59 | +<li><strong><code>bad load</code></strong> in <code>amxx plugins</code> — the plugin was compiled for a different AMXX version or a missing module. Recompile against your <a href="/tutorials/install-amx-mod-x-1-9">AMX Mod X</a> version.</li> | |
| 60 | +</ul> | |
| 61 | +<h2>Verification</h2> | |
| 62 | +<p>Join with a bot or a friend, get a kill, and confirm your weapon changes to the next level and the HUD shows your level advancing. Die and confirm you respawn immediately. Then reach the final knife level and land a knife kill — the map should end and declare the winner. If leveling, respawn and the knife win all work, GunGame is installed correctly.</p> |
install-warcraft3-ft-mod/en.md
A
| @@ -0,0 +1,43 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Install Warcraft 3 Frozen Throne Mod (WC3 FT)" | |
| 3 | +excerpt: "Install the Warcraft 3 Frozen Throne RPG mod on an AMX Mod X server, from plugins and custom resources to how player XP is saved." | |
| 4 | +category: "installation" | |
| 5 | +tags: "warcraft3, mods" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Warcraft 3 Frozen Throne (WC3 FT) is a long-running Counter-Strike 1.6 mod that turns the game into an RPG: players pick a <em>race</em>, gain XP for kills and objectives, level up, and spend skill points on abilities. It is built entirely as AMX Mod X plugins plus custom models and sounds — there is no engine or game-DLL swap. This guide installs WC3 FT on an AMXX server.</p> | |
| 10 | +<h2>1. Start from a working AMXX server</h2> | |
| 11 | +<p>WC3 FT is a pile of AMXX plugins, so AMX Mod X must be installed and loading first — see <a href="/tutorials/install-amx-mod-x-1-9">the AMX Mod X 1.9 guide</a>. Confirm <code>amxx plugins</code> works before adding the mod. WC3 leans on several standard AMXX modules (<code>fakemeta</code>, <code>hamsandwich</code>, <code>cstrike</code>, <code>fun</code>, and a saving backend), so make sure a normal module set is enabled in <code>modules.ini</code>.</p> | |
| 12 | +<h2>2. Copy the plugin files in</h2> | |
| 13 | +<p>WC3 FT ships as a main plugin plus a folder of race plugins and includes. Put the compiled plugins in the plugins folder:</p> | |
| 14 | +<pre>addons/amxmodx/plugins/wc3ft.amxx | |
| 15 | +addons/amxmodx/plugins/ (race sub-plugins, if the build splits them)</pre> | |
| 16 | +<p>Follow the general procedure in <a href="/tutorials/install-amxx-plugin-files">installing AMXX plugin files</a> — drop the <code>.amxx</code> in, add it to <code>plugins.ini</code>, change map. If your WC3 build splits each race into its own plugin, every race plugin gets its own <code>plugins.ini</code> line.</p> | |
| 17 | +<h2>3. Install the custom models and sounds</h2> | |
| 18 | +<p>The abilities use custom sprites, models and sounds — the lightning of Chain Lightning, the shockwave, the healing wave. These resources live under <code>cstrike/</code> in the paths the plugins precache:</p> | |
| 19 | +<pre>cstrike/models/... | |
| 20 | +cstrike/sound/... | |
| 21 | +cstrike/sprites/...</pre> | |
| 22 | +<p>They must exist server-side or the server fails to precache and refuses to start the map (a "precache" error naming a missing file). They must also reach clients, so serve them over <a href="/tutorials/fix-fastdl-not-working">FastDL</a> — without the download, players get missing-model errors even though the server is fine.</p> | |
| 23 | +<h2>4. Register the plugins and load their configs</h2> | |
| 24 | +<p>Add the main plugin (and any race plugins) to <code>addons/amxmodx/configs/plugins.ini</code>. WC3 FT keeps its own config — race balance, XP curve, which races are enabled — typically under <code>addons/amxmodx/configs/</code>. Load order: keep the main WC3 plugin above the race plugins if the build depends on it initialising first; see <a href="/tutorials/plugins-ini-load-order">plugins.ini load order</a>.</p> | |
| 25 | +<h2>5. Choose how XP is saved</h2> | |
| 26 | +<p>Players expect their level to persist between sessions, so WC3 FT saves XP keyed by SteamID. Builds use one of two backends:</p> | |
| 27 | +<ul> | |
| 28 | +<li><strong>nvault</strong> — a local file database (the <code>nvault</code> module). Zero setup, data lives in <code>addons/amxmodx/data/</code>. Fine for a single server.</li> | |
| 29 | +<li><strong>MySQL</strong> — the <code>sqlx</code> module writing to a database. Use this if you run several servers that must share one set of levels.</li> | |
| 30 | +</ul> | |
| 31 | +<p>Set the saving cvars in the WC3 config to match. Whichever you pick, XP is keyed by SteamID, so on a non-Steam server you need stable IDs (Reunion configured with a proper hash salt) or players share and overwrite each other's levels.</p> | |
| 32 | +<h2>6. Balance for your player count</h2> | |
| 33 | +<p>WC3 FT changes the pace of the game — high-level abilities can snowball a round — so the config exposes cvars for the XP required per level, the maximum level, whether items are enabled, and per-race tuning. On a small server, cap the maximum level lower so newcomers are not facing maxed-out veterans; on a busy one, a higher cap keeps long-term players invested. Enable only the races you have tested together, because a race added by a broken sub-plugin drags the whole mod down. Advertise the race menu and the level system in your <a href="/plugins/csb-server-adverts">server adverts</a> so new players know to pick a race on their first join.</p> | |
| 34 | +<h2>Troubleshooting</h2> | |
| 35 | +<ul> | |
| 36 | +<li><strong>Server will not start / "host_error: PF_precache" naming a model</strong> — a custom resource the mod precaches is missing server-side. Put the exact file at the path in the error.</li> | |
| 37 | +<li><strong>Clients see missing models but the server runs</strong> — the resources are on the server but not downloading. Fix <a href="/tutorials/fix-fastdl-not-working">FastDL</a> so clients pull them.</li> | |
| 38 | +<li><strong>Levels reset every reconnect</strong> — the saving backend is not writing. For nvault, the <code>data/</code> folder is not writable; for MySQL, the connection cvars are wrong. Check the AMXX log.</li> | |
| 39 | +<li><strong>Some abilities do nothing</strong> — a race plugin failed to load (<code>bad load</code> in <code>amxx plugins</code>), usually a missing module it needs.</li> | |
| 40 | +<li><strong>Everyone shares one level on a non-Steam server</strong> — colliding SteamIDs. Configure Reunion so each player gets a stable ID.</li> | |
| 41 | +</ul> | |
| 42 | +<h2>Verification</h2> | |
| 43 | +<p>Change map, run <code>amxx plugins</code>, and confirm the WC3 main plugin and every race plugin read <code>running</code>. Join, open the race menu (usually a chat command such as <code>/changerace</code> or a bound menu key), pick a race, get a kill and confirm you earn XP and eventually level up. Then disconnect and reconnect — your level should be restored, which proves the saving backend works. If it is, the mod is fully installed; tune the XP curve and race balance in the WC3 config to taste.</p> |
light-environment-and-sky/en.md
A
| @@ -0,0 +1,17 @@ | ||
| 1 | +--- | |
| 2 | +title: "Setting Up Sky and Sunlight (light_environment + Skybox)" | |
| 3 | +excerpt: "How to light an outdoor CS 1.6 map with a single light_environment, aim the sun with angle and pitch, and set the skybox name so gfx/env files render." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "lighting, skybox" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Outdoor lighting in GoldSrc is two cooperating pieces: a <code>light_environment</code> entity that <code>hlrad</code> uses as the sun, and a <strong>skybox</strong> — brushes textured with <code>SKY</code> plus the six <code>gfx/env/</code> images the engine draws behind them. Get both right and the map has directional sunlight and a real sky; get one wrong and you have flat lighting or a black void overhead. Here is the correct setup.</p><h2>1. Place exactly one light_environment</h2><p>A map should have <strong>one</strong> <code>light_environment</code>. It is not a positional light — its location does not matter — it defines the sun for the whole level. Place it anywhere convenient and set its properties:</p><pre>classname light_environment | |
| 10 | +_light 255 255 200 200 // R G B brightness | |
| 11 | +pitch -45 // sun elevation, negative points down | |
| 12 | +angle 135 // sun compass direction (yaw)</pre><p>The <code>_light</code> value is the sun colour and intensity; the fourth number is brightness. Warm sun is high R/G with slightly lower B; a harsh noon sun is near-white and bright. Multiple <code>light_environment</code> entities fight each other — keep exactly one.</p><h2>2. Aim the sun with angle and pitch</h2><p>Two fields set the sun direction. <code>angle</code> is the yaw (compass heading the light comes from), and <code>pitch</code> is the vertical angle — <strong>negative pitch points the sun downward</strong> toward the ground, which is what you want for daylight. A <code>pitch</code> of <code>-90</code> is directly overhead (short shadows); <code>-25</code> is a low, long-shadow evening sun. Note that in some tools the <code>angles</code>/<code>pitch</code> keys interact, so set <code>pitch</code> explicitly rather than relying on the angle circle alone, or shadows point the wrong way.</p><h2>3. Texture the sky with the SKY texture</h2><p>The engine only draws the skybox where it sees the <code>SKY</code> tool texture. Cap every opening to the outdoors — the top of your outdoor area, window gaps to the sky — with brushes faced in <code>SKY</code>. <code>hlrad</code> also emits the sun light <em>through</em> SKY faces, so the sun only reaches the ground where a SKY brush lets it in. No SKY face means no sky drawn and no sunlight entering. Face the hidden sides of those brushes with <code>NULL</code> as usual.</p><h2>4. Set the skybox name</h2><p>The six sky images live in <code>gfx/env/</code> and are named after your sky with directional suffixes:</p><pre>gfx/env/desert_up.tga | |
| 13 | +gfx/env/desert_dn.tga | |
| 14 | +gfx/env/desert_lf.tga | |
| 15 | +gfx/env/desert_rt.tga | |
| 16 | +gfx/env/desert_ft.tga | |
| 17 | +gfx/env/desert_bk.tga</pre><p>Tell the map which set to use by putting the base name (here <code>desert</code>) in the map's environment map / skybox field — in Hammer, <strong>Map → Map Properties → environment map (cl_skyname)</strong>. The engine appends the six suffixes automatically. The name must match the files exactly, or the sky is blank. CS ships several stock skies; a custom one must be delivered to players (list all six in your <a href="/tutorials/generate-res-file">.res file</a>).</p><h2>5. Add fill light so shadows are not pure black</h2><p><code>light_environment</code> gives you the sun and its shadows, but shadowed areas can go almost black. The <code>_light</code> ambient handling in ZHLT/VHLT adds a base ambient, but for interiors and deep shade add ordinary <code>light</code> entities to lift the darkness. This is the same balancing act covered in <a href="/tutorials/cs16-map-lighting-basics">map lighting basics</a>.</p><h2>Common errors</h2><ul><li><strong>Lighting is flat, no shadows</strong> — <code>pitch</code> is <code>0</code> or positive so the sun points up/level. Set a negative <code>pitch</code> like <code>-45</code>.</li><li><strong>Sky area is black / no sky drawn</strong> — the opening is not faced with the <code>SKY</code> texture, or <code>cl_skyname</code> is unset. Add SKY brushes and set the sky name.</li><li><strong>Sunlight does not reach the ground</strong> — there is no <code>SKY</code> face for the sun to pass through. The sun enters only through SKY faces.</li><li><strong>Sky is blank for players but fine for you</strong> — custom sky images are not delivered. List all six <code>gfx/env/</code> files in the <a href="/tutorials/generate-res-file">.res</a>.</li><li><strong>Two suns / weird double shadows</strong> — more than one <code>light_environment</code>. Delete all but one.</li></ul><h2>Verification</h2><p>Compile with a full <code>hlrad</code> pass, load the map outdoors, and check three things: the sky renders overhead (not black), the sun casts shadows in the direction your <code>angle</code>/<code>pitch</code> imply, and shaded areas are dark but not pitch black. Rotate to face the sun and confirm the light comes from where you aimed it. If the sky is blank on a clean client, the custom sky files are missing from delivery; if shadows point up, fix the <code>pitch</code>. Then round out interior lighting with <a href="/tutorials/cs16-map-lighting-basics">lighting basics</a>.</p> |
what-is-regamedll/en.md
A
| @@ -0,0 +1,17 @@ | ||
| 1 | +--- | |
| 2 | +title: "What Is ReGameDLL_CS and Should You Use It?" | |
| 3 | +excerpt: "ReGameDLL_CS is an open reimplementation of the CS game logic library that unlocks cvars like mp_maxrounds, fixes long-standing bugs, and exposes ReAPI hooks; here is what it is and when to run it." | |
| 4 | +category: "misc" | |
| 5 | +tags: "regamedll, basics" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>The stock Counter-Strike game logic — <code>cs.so</code> on Linux, <code>mp.dll</code> on Windows — is a closed Valve binary. <strong>ReGameDLL_CS</strong> is an open-source reimplementation of it, and it is one of the highest-value upgrades a modern CS 1.6 server can make. Here is what it replaces, what it unlocks, and whether you should run it.</p><h2>1. What ReGameDLL_CS replaces</h2><p>The game DLL is where the actual Counter-Strike rules live: buying, round logic, bomb planting, win conditions, damage, spawning. ReGameDLL_CS is a from-scratch open reimplementation of that library, maintained by the same <code>rehlds</code> GitHub organisation behind ReHLDS. You drop it in place of the stock <code>cs.so</code>/<code>mp.dll</code>, and the game plays identically by default — but now the game logic is open, configurable, and hookable. See <a href="/tutorials/install-regamedll-cs16">installing ReGameDLL_CS</a> for the setup.</p><h2>2. What it unlocks: cvars and fixes</h2><p>Because the round logic is now open, ReGameDLL adds and re-enables cvars the stock DLL never exposed. The most-cited example is round control:</p><pre>mp_maxrounds 30 | |
| 10 | +mp_winlimit 16 | |
| 11 | +mp_round_infinite 0</pre><p><code>mp_maxrounds</code> and <code>mp_winlimit</code> — the round-based map-ending limits every competitive setup relies on — are provided by ReGameDLL. On stock CS they do nothing; the value goes nowhere. ReGameDLL also carries a long list of gameplay cvars (weapon behaviour, buy-time, freeze-time tweaks, C4 timer, free-armor, and more) plus <strong>bug fixes</strong> for long-standing GoldSrc CS quirks that Valve never patched. It effectively turns hard-coded behaviour into configuration. A few examples of what becomes tunable:</p><pre>mp_buytime 45 | |
| 12 | +mp_startmoney 800 | |
| 13 | +mp_c4timer 35 | |
| 14 | +mp_freeforall 0 | |
| 15 | +mp_free_armor 0 | |
| 16 | +mp_give_player_c4 1</pre><p>None of these are adjustable on the stock Valve DLL — the values are baked into the closed binary. ReGameDLL exposes them, along with fixes for GoldSrc CS bugs Valve never addressed (grenade and hitbox edge cases, buy-menu quirks, spawn-protection behaviour), so a lot of the "that's just how CS is" annoyances become things you can configure or that are simply fixed.</p><h2>3. What it enables: ReAPI hooks</h2><p>The other big payoff is <strong>ReAPI</strong>. ReAPI is an AMX Mod X module that exposes ReHLDS and ReGameDLL internals to plugins through <code>RegisterHookChain</code> — letting a plugin hook game events (a player buying, taking damage, spawning, planting) cleanly and efficiently, instead of the older, hackier <code>fakemeta</code>/<code>hamsandwich</code> workarounds. A plugin that <code>#include <reapi></code> <strong>requires ReGameDLL</strong> to run, because the hooks it calls live in the ReGameDLL implementation. So if you want to run the modern generation of reapi-based plugins, ReGameDLL is a prerequisite — see <a href="/tutorials/install-reapi">installing ReAPI</a>.</p><h2>4. The Re- stack: how the pieces fit</h2><p>ReGameDLL is one layer of a coordinated modern stack:</p><ul><li><strong>ReHLDS</strong> — the open engine replacing HLDS. See <a href="/tutorials/hlds-vs-rehlds-explained">HLDS vs ReHLDS</a>.</li><li><strong>ReGameDLL_CS</strong> — the open game logic replacing <code>cs.so</code>/<code>mp.dll</code> (this page).</li><li><strong>Metamod-r</strong> — the loader; then AMX Mod X on top.</li><li><strong>ReAPI</strong> — the AMXX module exposing ReHLDS/ReGameDLL hooks to plugins.</li></ul><p>They are designed to run together. You can run ReGameDLL on ReHLDS and get the full benefit; it also weathered the <a href="/tutorials/25th-anniversary-update-recap">25th anniversary update</a> far better than stock binaries.</p><h2>5. Should you use it?</h2><p><strong>Yes for almost every modern server.</strong> Run ReGameDLL if you want: round-based map limits (<code>mp_maxrounds</code>/<code>mp_winlimit</code>), the gameplay cvars, the accumulated bug fixes, or any reapi-based plugin. The default behaviour matches stock CS, so you are not changing how the game feels unless you deliberately set the new cvars. <strong>Skip it only</strong> if you are pinned to a stock-Valve setup for a specific reason and use no reapi plugins — a shrinking niche.</p><h2>Common misconceptions</h2><ul><li><strong>"ReGameDLL changes how the game plays."</strong> Not by default — it reproduces stock behaviour and only changes things when you set its cvars.</li><li><strong>"It replaces the engine."</strong> No — that is ReHLDS. ReGameDLL replaces the <em>game logic</em> DLL, a different layer. They are complementary.</li><li><strong>"mp_maxrounds just needs enabling in the config."</strong> On stock CS it does not exist; the cvar comes from ReGameDLL. No config trick enables it without the library.</li><li><strong>"ReAPI works without ReGameDLL."</strong> No — a plugin using <code>#include <reapi></code> requires ReGameDLL (and typically ReHLDS). Set both <code>reapi_required</code> and <code>regamedll_required</code> for such plugins.</li><li><strong>"It's a mod players must download."</strong> It is a server-side library. Clients need nothing.</li></ul><h2>How to check it is running</h2><p>The simplest confirmation is that a ReGameDLL-only cvar exists. In the server console:</p><pre>mp_maxrounds | |
| 17 | +mp_round_infinite</pre><p>On stock CS these are unknown; on ReGameDLL they return a value. You can also check the game DLL your server loaded in the startup log — a ReGameDLL build identifies itself there. If <code>mp_maxrounds</code> is unknown and you want round-based limits or reapi plugins, install <a href="/tutorials/install-regamedll-cs16">ReGameDLL_CS</a>, ideally on <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a>, and then add <a href="/tutorials/install-reapi">ReAPI</a> for the modern hook API.</p> | |
| 0 | 18 |
