Correct facts in 11 tutorials (checked against the project sources)
Browse SourceAMX Mod X error lines quoted as AMXX prints them (not exisitng/not existing function, Module/Library required, unknown function), module lines are in the L log, a newer-compiled plugin fails with an unknown function rather than Invalid Plugin; ReHLDS is checked with `version` (rehlds_version is not a command), flood-limit defaults 250/500, force_dlmax is a fragment size, cvar comments fixed; GoldSrc rcon uses the game's UDP port; ReChecker resources.ini real syntax (UNKNOWN/MISSING/IGNORE/BREAK, commands, rch_log logs); ReVoice real revoice.cfg, Reunion above ReVoice, no sv_voicecodec/quality.
11 changed files
with 103 additions and 87 deletions
M
fix-amxx-module-failed-to-load/en.md
+4 -4
M
fix-invalid-plugin-amxx/en.md
+3 -3
M
fix-plugins-bad-load-after-19/en.md
+5 -5
M
install-amx-mod-x-1-10/en.md
+4 -4
M
install-amxx-modules/en.md
+5 -5
M
install-cs16-dedicated-server-windows/en.md
+3 -4
M
install-rechecker/en.md
+32 -19
M
install-rehlds-on-linux/en.md
+14 -9
M
install-reunion/en.md
+2 -2
M
install-revoice/en.md
+23 -24
M
rehlds-performance-cvars/en.md
+8 -8
fix-amxx-module-failed-to-load/en.md
M
| @@ -9,7 +9,7 @@ read_time: "8 min read" | ||
| 9 | 9 | <p>When AMX Mod X cannot bring a module online you see it in the console at boot and in <code>amxx modules</code>: a module sitting at <code>error</code> or <code>bad load</code> instead of <code>running</code>. Modules are native <code>.so</code>/<code>.dll</code> binaries (MySQL, GeoIP, SQLite, cURL, and so on) that expose natives to your plugins, so a failed module takes down every plugin that depends on it. The reason is almost always one of four things, and the AMXX log names which.</p> |
| 10 | 10 | |
| 11 | 11 | <h2>1. Read the actual reason</h2> |
| 12 | -<p>Do not guess from the console. Open the dated log under <code>addons/amxmodx/logs/</code> and find the module line. AMXX states the cause explicitly — <em>compiled for a newer AMX Mod X</em>, <em>couldn't find</em>, <em>wrong architecture</em>. In the console:</p> | |
| 12 | +<p>Do not guess from the console. Open the dated log under <code>addons/amxmodx/logs/</code> and find the module line. AMXX states the cause explicitly — <em>requested a not existing function</em>, <em>couldn't find</em>, <em>wrong architecture</em>. In the console:</p> | |
| 13 | 13 | <pre>amxx modules</pre> |
| 14 | 14 | <p>lists every module with its status. That plus the log is your whole diagnosis.</p> |
| 15 | 15 | |
| @@ -25,7 +25,7 @@ file mysql_amxx_i386.so</pre> | ||
| 25 | 25 | <p>Any line reading <code>not found</code> is a missing dependency you must install as its 32-bit (<code>:i386</code>) package. This is the same class of problem as the engine's missing loader — see <a href="/tutorials/install-32bit-libraries-cs16-linux">the 32-bit library guide</a>. For the database modules specifically, <a href="/tutorials/install-mysql-module-amxx">installing the MySQL module</a> covers exactly which library the loader wants.</p> |
| 26 | 26 | |
| 27 | 27 | <h2>4. Version mismatch</h2> |
| 28 | -<p>A module compiled against a newer AMXX than you run will refuse to load with a message like <em>module is compiled for a newer version of AMX Mod X</em>. The fix is to match them: either upgrade AMXX, or use a module build for your version. This is why mixing a fresh module into an ancient 1.8.2 install so often fails — the natives it expects do not exist yet. If you are still on 1.8.2, this is a good moment to read <a href="/tutorials/upgrade-amxmodx-1-8-2-to-1-10">upgrading to 1.10</a>. Conversely, a <em>very</em> old module can fail against a current AMXX; keep the whole set from one era.</p> | |
| 28 | +<p>A module compiled against a newer AMXX than you run will refuse to load: <code>amxx modules</code> shows it as <code>newer</code>, and the log reads <em>Module requested a not existing function</em> (1.8.2 spells it <em>not exisitng</em>) followed by the missing function, for example <code>GetConfigManager</code> for a 1.9 or 1.10 module on 1.8.2. See <a href="/tutorials/fix-module-compiled-newer-amxx">that error</a>. The fix is to match them: either upgrade AMXX, or use a module build for your version. This is why mixing a fresh module into an ancient 1.8.2 install so often fails — the core functions it asks for do not exist yet. If you are still on 1.8.2, this is a good moment to read <a href="/tutorials/upgrade-amxmodx-1-8-2-to-1-10">upgrading to 1.10</a>. Conversely, a <em>very</em> old module can fail against a current AMXX; keep the whole set from one era.</p> | |
| 29 | 29 | |
| 30 | 30 | <h2>5. It is not being loaded at all</h2> |
| 31 | 31 | <p>If the module is not even listed, it is not being loaded. Modules load from <code>addons/amxmodx/configs/modules.ini</code>, or automatically when a plugin declares it needs them. Make sure the file is present in <code>addons/amxmodx/modules/</code> and, if you use an explicit list, that its name is in <code>modules.ini</code> without a leading semicolon (which comments it out). See <a href="/tutorials/install-amxx-modules">installing AMXX modules</a> for the load mechanics.</p> |
| @@ -33,8 +33,8 @@ file mysql_amxx_i386.so</pre> | ||
| 33 | 33 | |
| 34 | 34 | <h2>Common errors</h2> |
| 35 | 35 | <ul> |
| 36 | -<li><strong><code>Module requires newer AMX Mod X</code></strong> — version mismatch, step 4. Match module and core versions.</li> | |
| 37 | -<li><strong><code>Cstrike module required</code> from a plugin, not a module</strong> — that is a plugin failing because a module it needs is not loaded, often because the module itself failed here. Fix the module first. Details in <a href="/tutorials/fix-module-cstrike-required">that error</a>.</li> | |
| 36 | +<li><strong><code>Module requested a not existing function</code></strong> — version mismatch, step 4. Match module and core versions.</li> | |
| 37 | +<li><strong><code>Module/Library "cstrike" required for plugin</code> from a plugin, not a module</strong> — that is a plugin failing because a module it needs is not loaded, often because the module itself failed here. Fix the module first. Details in <a href="/tutorials/fix-module-cstrike-required">that error</a>.</li> | |
| 38 | 38 | <li><strong>Module <code>running</code> but a plugin still says it is missing</strong> — the plugin needs a native the module does not export in your version. Upgrade the module.</li> |
| 39 | 39 | <li><strong><code>libmysqlclient.so.XX: cannot open shared object file</code></strong> — the exact "missing 32-bit library" case from step 3. Install the i386 MySQL client library.</li> |
| 40 | 40 | </ul> |
fix-invalid-plugin-amxx/en.md
M
| @@ -1,11 +1,11 @@ | ||
| 1 | 1 | --- |
| 2 | 2 | title: "Fix: 'Plugin failed to load: Invalid Plugin' (AMX Mod X)" |
| 3 | -excerpt: "What 'Invalid Plugin' means in AMX Mod X, the version and architecture mismatch between .amxx and your AMXX build, corrupted uploads, wrong compiler, and reading amxx plugins status." | |
| 3 | +excerpt: "What 'Invalid Plugin' means in AMX Mod X: a corrupted upload or a file that is not a real .amxx, how it differs from version problems, the wrong compiler, and reading amxx plugins status." | |
| 4 | 4 | category: "errors" |
| 5 | 5 | tags: "amxmodx, plugins" |
| 6 | 6 | image: "" |
| 7 | 7 | read_time: "8 min read" |
| 8 | 8 | --- |
| 9 | -<p>AMX Mod X loads your plugin list and one line reports:</p><blockquote>Plugin failed to load: Invalid Plugin</blockquote><p>and <code>amxx plugins</code> shows it as <code>bad load</code>. "Invalid Plugin" specifically means AMX Mod X could not recognise the <code>.amxx</code> as a plugin it can run — the file is corrupt, compiled for the wrong AMXX version, or not a real <code>.amxx</code> at all. This is distinct from a plugin that loads but errors at runtime. Here is how to pin it down.</p><h2>1. Read the exact status</h2><p>Get the per-plugin verdict from the server console:</p><pre>amxx plugins</pre><p>Each plugin shows <code>running</code>, <code>paused</code>, <code>bad load</code>, or <code>debug</code>. "Invalid Plugin" corresponds to <code>bad load</code> with an invalid-format reason. Note which plugin and pair it with the load line in the AMXX log under <code>addons/amxmodx/logs/</code>, which often adds a more specific reason such as a bad file magic or version.</p><h2>2. Check the file is a real, complete .amxx</h2><p>A truncated or corrupted upload — interrupted transfer, or FTP in ASCII mode mangling a binary — produces an invalid plugin. Confirm the file has real size and is binary:</p><pre>ls -l addons/amxmodx/plugins/myplugin.amxx</pre><p>A near-zero-byte file, or a file that opens as text/HTML (you accidentally saved a web page), is invalid. Re-upload in <strong>binary</strong> mode. If you compiled it yourself, make sure you copied the <code>.amxx</code> output, not the <code>.sma</code> source — a <code>.sma</code> renamed to <code>.amxx</code> is invalid because it is Pawn text, not compiled bytecode.</p><h2>3. Match the plugin's AMXX version to your server</h2><p>A plugin compiled for a newer AMX Mod X than you run can be rejected as invalid, and one compiled for a much older branch may also fail. The safe path is to compile against the version you run — <strong>1.9</strong> is the stable default. If you downloaded a precompiled <code>.amxx</code> that will not load, recompile the <code>.sma</code> with the matching compiler. On this platform the <a href="/plugins/">plugin directory</a> compiles source on demand against pinned 1.8.2 / 1.9 / 1.10 toolchains, which sidesteps the mismatch entirely.</p><h2>4. Rule out an architecture/format mismatch</h2><p>The <code>.amxx</code> format carries a version tag AMX Mod X checks on load. If someone hand-edited the file, or it was produced by an incompatible or unofficial compiler, the tag will not match and it loads as invalid. Recompile from clean source with the official <code>amxxpc</code> for your target version rather than trusting a mystery binary.</p><h2>5. Confirm the line in plugins.ini is right</h2><p>The plugin is listed in <code>addons/amxmodx/configs/plugins.ini</code>. A line pointing at a filename that does not exist, or a stray path, produces a load failure too. Keep it to the bare filename:</p><pre>myplugin.amxx | |
| 9 | +<p>AMX Mod X loads your plugin list and one line reports:</p><blockquote>Plugin failed to load: Invalid Plugin</blockquote><p>and <code>amxx plugins</code> shows it as <code>bad load</code>. "Invalid Plugin" specifically means AMX Mod X could not recognise the <code>.amxx</code> as a plugin it can run — the file is corrupt or not a real <code>.amxx</code> at all. This is distinct from a plugin that loads but errors at runtime. Here is how to pin it down.</p><h2>1. Read the exact status</h2><p>Get the per-plugin verdict from the server console:</p><pre>amxx plugins</pre><p>Each plugin shows <code>running</code>, <code>paused</code>, <code>bad load</code>, or <code>debug</code>. "Invalid Plugin" corresponds to <code>bad load</code> with an invalid-format reason. Note which plugin and pair it with the line in the AMXX logs under <code>addons/amxmodx/logs/</code>: AMX Mod X records it as <code>Invalid Plugin</code> with the plugin's file name, in <code>error_YYYYMMDD.log</code>.</p><h2>2. Check the file is a real, complete .amxx</h2><p>A truncated or corrupted upload — interrupted transfer, or FTP in ASCII mode mangling a binary — produces an invalid plugin. Confirm the file has real size and is binary:</p><pre>ls -l addons/amxmodx/plugins/myplugin.amxx</pre><p>A near-zero-byte file, or a file that opens as text/HTML (you accidentally saved a web page), is invalid. Re-upload in <strong>binary</strong> mode. If you compiled it yourself, make sure you copied the <code>.amxx</code> output, not the <code>.sma</code> source — a <code>.sma</code> renamed to <code>.amxx</code> is invalid because it is Pawn text, not compiled bytecode.</p><h2>3. Match the plugin's AMXX version to your server</h2><p>A plugin compiled for a newer AMX Mod X than you run is not rejected as invalid, because the 1.8.2, 1.9 and 1.10 compilers write the same file format. It fails differently: if it calls a native your version lacks, the log says <code>Plugin uses an unknown function (name "...")</code> and it shows as <code>bad load</code>. One compiled for a much older branch may also fail. The safe path is to compile against the version you run — <strong>1.9</strong> is the stable default. If you downloaded a precompiled <code>.amxx</code> that will not load, recompile the <code>.sma</code> with the matching compiler. On this platform the <a href="/plugins/">plugin directory</a> compiles source on demand against pinned 1.8.2 / 1.9 / 1.10 toolchains, which sidesteps the mismatch entirely.</p><h2>4. Rule out an architecture/format mismatch</h2><p>The <code>.amxx</code> format carries a version tag AMX Mod X checks on load. If someone hand-edited the file, or it was produced by an incompatible or unofficial compiler, the check fails: a damaged file loads as invalid, and a header the loader does not accept (a very old or non-standard compiler) is refused with <code>Plugin uses deprecated format. Update compiler</code>. Recompile from clean source with the official <code>amxxpc</code> for your target version rather than trusting a mystery binary.</p><h2>5. Confirm the line in plugins.ini is right</h2><p>The plugin is listed in <code>addons/amxmodx/configs/plugins.ini</code>. A line pointing at a filename that does not exist, or a stray path, produces a load failure too. Keep it to the bare filename:</p><pre>myplugin.amxx | |
| 10 | 10 | ; not a path, not myplugin.sma, not a commented mess |
| 11 | -</pre><p>Plugins load only at map change, so after fixing the file or the line, change the map (or restart) to reload — editing on a live map changes nothing until then, as covered in <a href="/tutorials/update-plugins-live-server">updating plugins on a live server</a>.</p><h2>6. Compile against the version you run</h2><p>The cleanest way to avoid "Invalid Plugin" for good is to never ship a binary compiled for a version you do not run. If you maintain your own plugins, keep a copy of the <code>amxxpc</code> compiler that matches your server — 1.8.2, 1.9 or 1.10 — and compile there. A plugin that uses a native introduced in 1.9 (for example the coloured chat natives) will not even compile on 1.8.2, and a 1.10-compiled binary can be rejected by a 1.8.2 loader as an invalid format. Pin one AMXX version across your whole server and compile everything against it; mixing compilers is the fastest route back to this error.</p><h2>Common errors</h2><ul><li><strong><code>bad load</code> / Invalid Plugin</strong> — wrong AMXX version or a corrupt file. Recompile against your version, re-upload in binary.</li><li><strong>Renamed <code>.sma</code> to <code>.amxx</code></strong> — that is source, not bytecode. Compile it first.</li><li><strong>File is tiny or opens as text</strong> — a truncated or ASCII-mangled upload. Transfer in binary mode.</li><li><strong>Precompiled download will not load</strong> — it targets a different AMXX branch. Recompile the <code>.sma</code>.</li><li><strong>Fixed the file but nothing changed</strong> — plugins reload at map change; change the map.</li></ul><h2>Verification</h2><p>After recompiling/re-uploading and changing the map, re-check:</p><pre>amxx plugins</pre><p>The plugin should now read <code>running</code> instead of <code>bad load</code>. Cross-check the AMXX log for the load line — a clean load with no invalid-format entry confirms the fix. If it loads but then throws runtime errors, that is a different layer (a missing module or a code bug); a plugin that needs a module you lack shows as <code>bad load</code> for a different reason, addressed in the module-load troubleshooting. Test the plugin's actual feature in-game to be sure it is genuinely working, not merely listed.</p> | |
| 11 | +</pre><p>Plugins load only at map change, so after fixing the file or the line, change the map (or restart) to reload — editing on a live map changes nothing until then, as covered in <a href="/tutorials/update-plugins-live-server">updating plugins on a live server</a>.</p><h2>6. Compile against the version you run</h2><p>The cleanest way to avoid version-related load failures for good is to never ship a binary compiled for a version you do not run. If you maintain your own plugins, keep a copy of the <code>amxxpc</code> compiler that matches your server — 1.8.2, 1.9 or 1.10 — and compile there. A plugin that uses a native introduced in 1.9 (for example the coloured chat natives) will not even compile on 1.8.2, and a 1.10-compiled binary that calls one is not rejected by a 1.8.2 loader as an invalid format: it fails with <code>Plugin uses an unknown function (name "client_print_color") - check your modules.ini.</code> instead (see <a href="/tutorials/fix-module-compiled-newer-amxx">version mismatches</a>). Pin one AMXX version across your whole server and compile everything against it; mixing compilers is the fastest route to a <code>bad load</code>.</p><h2>Common errors</h2><ul><li><strong><code>bad load</code> / Invalid Plugin</strong> — a corrupt file or not a real <code>.amxx</code>; a wrong AMXX version shows <code>Plugin uses an unknown function</code> instead. Recompile against your version, re-upload in binary.</li><li><strong>Renamed <code>.sma</code> to <code>.amxx</code></strong> — that is source, not bytecode. Compile it first.</li><li><strong>File is tiny or opens as text</strong> — a truncated or ASCII-mangled upload. Transfer in binary mode.</li><li><strong>Precompiled download will not load</strong> — it targets a different AMXX branch. Recompile the <code>.sma</code>.</li><li><strong>Fixed the file but nothing changed</strong> — plugins reload at map change; change the map.</li></ul><h2>Verification</h2><p>After recompiling/re-uploading and changing the map, re-check:</p><pre>amxx plugins</pre><p>The plugin should now read <code>running</code> instead of <code>bad load</code>. Cross-check the AMXX log for the load line — a clean load with no invalid-format entry confirms the fix. If it loads but then throws runtime errors, that is a different layer (a missing module or a code bug); a plugin that needs a module you lack shows as <code>bad load</code> for a different reason, addressed in <a href="/tutorials/fix-module-cstrike-required">the module-load troubleshooting</a>. Test the plugin's actual feature in-game to be sure it is genuinely working, not merely listed.</p> |
fix-plugins-bad-load-after-19/en.md
M
| @@ -6,7 +6,7 @@ tags: "amxmodx, upgrade" | ||
| 6 | 6 | image: "" |
| 7 | 7 | read_time: "8 min read" |
| 8 | 8 | --- |
| 9 | -<p>You dropped a newer AMX Mod X over an old install, restarted, and now half your plugins sit in the list with the status <code>bad load</code>. This is almost never a corrupt plugin. It is a version-mixing problem: the AMXX core got upgraded but its <em>modules</em> did not, and a plugin that needs a module the core can no longer load fails at start. The good news is that <code>bad load</code> is a precise symptom, and once you know where to read it, the fix is mechanical.</p> | |
| 9 | +<p>You dropped a newer AMX Mod X over an old install, restarted, and now half your plugins sit in the list with the status <code>bad load</code>. This is almost never a corrupt plugin. It is a version-mixing problem: the AMXX core got upgraded but its <em>modules</em> did not, and a plugin that needs a native the old module does not have fails at start. The good news is that <code>bad load</code> is a precise symptom, and once you know where to read it, the fix is mechanical.</p> | |
| 10 | 10 | |
| 11 | 11 | <h2>1. Read the right list first</h2> |
| 12 | 12 | <p>There are two different "bad load" states and they live in two different lists. Check both from the server console (or RCON):</p> |
| @@ -25,17 +25,17 @@ amxx modules</pre> | ||
| 25 | 25 | <p>Fix that before touching anything else — nothing below matters until <code>meta list</code> shows <code>amxmodx_mm</code> as <code>RUN</code>.</p> |
| 26 | 26 | |
| 27 | 27 | <h2>3. Replace the modules, not just the core</h2> |
| 28 | -<p>This is the actual cause in the large majority of upgrade cases. AMXX modules (<code>fakemeta_amxx_i386.so</code>, <code>hamsandwich_amxx_i386.so</code>, <code>cstrike_amxx_i386.so</code>, <code>sqlite_amxx_i386.so</code>, and so on) are versioned <strong>together</strong> with the core. When you upgraded, you likely overwrote <code>dlls/amxmodx_mm_i386.so</code> and the <code>plugins/</code> folder but left the old 1.8.2 modules in <code>addons/amxmodx/modules/</code>. A 1.8.2 module against a 1.10 core fails to load, and every plugin that <code>#include</code>d it is now missing its natives.</p> | |
| 28 | +<p>This is the actual cause in the large majority of upgrade cases. AMXX modules (<code>fakemeta_amxx_i386.so</code>, <code>hamsandwich_amxx_i386.so</code>, <code>cstrike_amxx_i386.so</code>, <code>sqlite_amxx_i386.so</code>, and so on) are versioned <strong>together</strong> with the core. When you upgraded, you likely overwrote <code>dlls/amxmodx_mm_i386.so</code> and the <code>plugins/</code> folder but left the old 1.8.2 modules in <code>addons/amxmodx/modules/</code>. A 1.8.2 module still loads on a 1.10 core and shows <code>running</code>, but it lacks every native added since 1.8.2, so a plugin built for the new version that <code>#include</code>s it and calls one of those natives fails to load.</p> | |
| 29 | 29 | <p>Copy the entire modules directory from the same release you upgraded to:</p> |
| 30 | 30 | <pre>cp /path/to/amxx-1.10/addons/amxmodx/modules/*.so \ |
| 31 | 31 | /home/steam/hlds/cstrike/addons/amxmodx/modules/</pre> |
| 32 | 32 | <p>Then check what actually loaded:</p> |
| 33 | 33 | <pre>amxx modules</pre> |
| 34 | -<p>Any module that is not <code>running</code> here is your smoking gun. The AMXX log will name it — look in <code>addons/amxmodx/logs/</code> for a line such as <code>Module requires a newer version of AMX Mod X</code> or a native-not-found error.</p> | |
| 34 | +<p>Any module that is not <code>running</code> here is your smoking gun. The AMXX log will name it — look in <code>addons/amxmodx/logs/</code> for a line such as <code>Module requested a not existing function</code> (a module newer than the core) or the native-not-found error <code>Plugin uses an unknown function</code>. A leftover old module still reads <code>running</code>, so also compare the version column: a module showing 1.8.2 next to a 1.10 core is one to replace.</p> | |
| 35 | 35 | |
| 36 | 36 | <h2>4. Recompile plugins that use changed natives</h2> |
| 37 | 37 | <p>Old <code>.amxx</code> bytecode usually keeps working across versions, but a plugin that called a native which was renamed or removed will still <code>bad load</code> even with the right module present. The log entry looks like:</p> |
| 38 | -<pre>Plugin "yourplugin.amxx" failed to load: Function not found</pre> | |
| 38 | +<pre>[AMXX] Plugin "yourplugin.amxx" failed to load: Plugin uses an unknown function (name "some_native") - check your modules.ini.</pre> | |
| 39 | 39 | <p>Recompile the <code>.sma</code> against the matching AMXX includes. If you do not have the source, you have to find a build that targets your version. See <a href="/tutorials/install-amx-mod-x-1-9">installing AMXX 1.9</a> for how the versions line up, and <a href="/tutorials/upgrade-amxmodx-1-8-2-to-1-10">the full 1.8.2 to 1.10 upgrade</a> for the complete file list you must swap.</p> |
| 40 | 40 | |
| 41 | 41 | <h2>5. Check plugins.ini and configs</h2> |
| @@ -44,7 +44,7 @@ amxx modules</pre> | ||
| 44 | 44 | <h2>Common errors</h2> |
| 45 | 45 | <ul> |
| 46 | 46 | <li><strong><code>bad load</code> in <code>amxx plugins</code> but modules are fine</strong> — the plugin needs a native from a module that is present but a different version. Line up all modules to one release.</li> |
| 47 | -<li><strong><code>Module requires a newer version of AMX Mod X</code></strong> — a module is <em>newer</em> than the core. You upgraded modules but not the core; do both.</li> | |
| 47 | +<li><strong><code>Module requested a not existing function</code></strong> — a module is <em>newer</em> than the core (<code>amxx modules</code> shows it as <code>newer</code>; 1.8.2 spells the message <code>not exisitng</code>). You upgraded modules but not the core; do both. See <a href="/tutorials/fix-module-compiled-newer-amxx">that error</a>.</li> | |
| 48 | 48 | <li><strong>Everything is <code>bad load</code> at once</strong> — read <code>meta list</code>; the AMXX core itself failed and this is not a per-plugin issue.</li> |
| 49 | 49 | <li><strong>Works on Windows, breaks on Linux after copying</strong> — filename case, or you copied <code>_amxx.dll</code> modules into a Linux install. Linux needs the <code>_i386.so</code> files.</li> |
| 50 | 50 | </ul> |
install-amx-mod-x-1-10/en.md
M
| @@ -62,13 +62,13 @@ amxx modules</pre> | ||
| 62 | 62 | [ 2] Admin Commands 1.10.0 AMXX Dev Team admincmd.amxx running |
| 63 | 63 | … |
| 64 | 64 | 25 plugins, 25 running</pre> |
| 65 | -<p><code>amxx modules</code> should show each module as <code>running</code> with its version. A module listed as <code>error</code> or missing entirely is a version mismatch — a 1.9 module in a 1.10 <code>modules/</code> directory. Delete the stale file; the 1.10 packages ship all of them.</p> | |
| 65 | +<p><code>amxx modules</code> should show each module as <code>running</code> with its version. A module that is not <code>running</code>, or that shows a different version from the core, is a problem. A 1.9 module left in a 1.10 <code>modules/</code> directory still loads and says <code>running</code>, so check the version column for it. Delete the stale file; the 1.10 packages ship all of them.</p> | |
| 66 | 66 | |
| 67 | 67 | <h2>7. Old plugins on a new core</h2> |
| 68 | 68 | <p>This is the whole reason people hesitate to move to 1.10. Three outcomes for an old <code>.amxx</code>:</p> |
| 69 | 69 | <ul> |
| 70 | 70 | <li><strong>It just works.</strong> Most simple plugins do.</li> |
| 71 | -<li><strong><code>Plugin failed to load: Invalid Plugin</code></strong> — the bytecode version is not accepted. You need the <code>.sma</code> and a recompile.</li> | |
| 71 | +<li><strong><code>Plugin failed to load: Invalid Plugin</code></strong> — not a version problem: 1.8.2, 1.9 and 1.10 compilers write the same file format, so the file is damaged or is not a real <code>.amxx</code>. Re-upload it, or recompile from the <code>.sma</code>.</li> | |
| 72 | 72 | <li><strong>It loads and then throws <code>Run time error 10: native error</code></strong> — it calls a native whose behaviour changed, or one that was removed. Again: recompile from source, fix what the compiler complains about.</li> |
| 73 | 73 | </ul> |
| 74 | 74 | <p>Recompiling is usually trivial:</p> |
| @@ -78,8 +78,8 @@ amxx modules</pre> | ||
| 78 | 78 | |
| 79 | 79 | <h2>Common errors</h2> |
| 80 | 80 | <ul> |
| 81 | -<li><strong><code>Module was compiled for a newer AMXX version</code></strong> — you have a 1.10 module sitting in a 1.9 install (or vice versa). Modules and core must come from the same release. See <a href="/tutorials/fix-module-compiled-newer-amxx">that error</a>.</li> | |
| 82 | -<li><strong><code>Plugin failed to load: Invalid Plugin</code></strong> — bytecode from a different AMXX major. Recompile.</li> | |
| 81 | +<li><strong><code>Module requested a not existing function</code></strong> — you have a 1.9 or 1.10 module sitting in a 1.8.2 install; <code>amxx modules</code> shows it as <code>newer</code>, and 1.8.2 spells the message <code>not exisitng</code>. Modules and core must come from the same release. See <a href="/tutorials/fix-module-compiled-newer-amxx">that error</a>.</li> | |
| 82 | +<li><strong><code>Plugin uses an unknown function (name "...")</code></strong> — the plugin calls a native your core or modules do not provide, for example one added in 1.9 (such as <code>client_print_color</code>) in a plugin loaded on 1.8.2, or one from a module you have not installed. Recompile against your version, or install the module. (<code>Invalid Plugin</code> is not a version mismatch; it means a damaged or non-<code>.amxx</code> file.)</li> | |
| 83 | 83 | <li><strong>Plugins show <code>bad load</code> after the upgrade</strong> — the common upgrade symptom; see <a href="/tutorials/fix-plugins-bad-load-after-19">plugins bad load after upgrading</a>.</li> |
| 84 | 84 | <li><strong><code>Run time error 4: index out of bounds</code></strong> in a plugin that used to work — an array-bounds bug that 1.8.2 tolerated and 1.10 catches. That is the newer core doing its job; fix the plugin.</li> |
| 85 | 85 | <li><strong>Server crashes at map start after the upgrade</strong> — two AMXX cores in <code>metamod/plugins.ini</code>, or a leftover <code>modules/</code> from the old version.</li> |
install-amxx-modules/en.md
M
| @@ -24,7 +24,7 @@ read_time: "8 min read" | ||
| 24 | 24 | <li><strong>Explicit</strong> — a line in <code>configs/modules.ini</code> loads that module at startup, whether or not any plugin needs it.</li> |
| 25 | 25 | <li><strong>On demand</strong> — when a plugin declares <code>#include <cstrike></code>, its compiled <code>.amxx</code> records that it requires the <code>cstrike</code> library. AMXX will load the matching module automatically if it can find it in <code>modules/</code>.</li> |
| 26 | 26 | </ol> |
| 27 | -<p>So a module can load even if it is not in <code>modules.ini</code>. The corollary matters: <strong>a module that is not on disk cannot be auto-loaded</strong>, and you get <code>Module "cstrike" required for plugin "x.amxx"</code> at startup. See <a href="/tutorials/fix-module-cstrike-required">that error</a>.</p> | |
| 27 | +<p>So a module can load even if it is not in <code>modules.ini</code>. The corollary matters: <strong>a module that is not on disk cannot be auto-loaded</strong>, and you get <code>Plugin "x.amxx" failed to load: Module/Library "cstrike" required for plugin</code> at startup. See <a href="/tutorials/fix-module-cstrike-required">that error</a>.</p> | |
| 28 | 28 | |
| 29 | 29 | <h2>modules.ini format</h2> |
| 30 | 30 | <pre>; AMX Mod X modules |
| @@ -52,7 +52,7 @@ hamsandwich | ||
| 52 | 52 | <h2>Installing a third-party module</h2> |
| 53 | 53 | <p>The procedure is the same whether it is ReAPI, Orpheu, or something from a forum:</p> |
| 54 | 54 | <ol> |
| 55 | -<li>Get a build for <strong>your AMXX version and platform</strong>. A 1.10 module in a 1.9 install fails with <code>Module was compiled for a newer AMXX version</code>.</li> | |
| 55 | +<li>Get a build for <strong>your AMXX version and platform</strong>. A 1.9 or 1.10 module in a 1.8.2 install fails with <code>Module requested a not exisitng function</code> (1.8.2's own spelling) and shows as <code>newer</code>; see <a href="/tutorials/fix-module-compiled-newer-amxx">that error</a>.</li> | |
| 56 | 56 | <li>Copy it into <code>modules/</code>: |
| 57 | 57 | <pre>cp reapi_amxx_i386.so /home/steam/hlds/cstrike/addons/amxmodx/modules/ |
| 58 | 58 | chmod 644 /home/steam/hlds/cstrike/addons/amxmodx/modules/reapi_amxx_i386.so</pre></li> |
| @@ -101,8 +101,8 @@ chmod 644 /home/steam/hlds/cstrike/addons/amxmodx/modules/reapi_amxx_i386.so</pr | ||
| 101 | 101 | <h2>Common errors</h2> |
| 102 | 102 | <ul> |
| 103 | 103 | <li><strong><code>Module failed to load</code></strong> — file missing, wrong architecture, or built for a different AMXX. See <a href="/tutorials/fix-amxx-module-failed-to-load">the full fix</a>.</li> |
| 104 | -<li><strong><code>Module "cstrike" required for plugin "x.amxx"</code></strong> — the <code>.so</code> is not in <code>modules/</code>. You extracted the AMXX base package but not the Counter-Strike addon.</li> | |
| 105 | -<li><strong><code>Module was compiled for a newer AMXX version</code></strong> — version mismatch. Modules must come from the same AMXX release as the core.</li> | |
| 104 | +<li><strong><code>Module/Library "cstrike" required for plugin</code></strong> — the <code>.so</code> is not in <code>modules/</code>. You extracted the AMXX base package but not the Counter-Strike addon.</li> | |
| 105 | +<li><strong><code>Module requested a not existing function</code></strong> — version mismatch: the module is newer than the core, and <code>amxx modules</code> shows it as <code>newer</code> (1.8.2 spells the message <code>not exisitng</code>). Modules must come from the same AMXX release as the core. See <a href="/tutorials/fix-module-compiled-newer-amxx">that error</a>.</li> | |
| 106 | 106 | <li><strong>Module listed in <code>modules.ini</code> but not in <code>amxx modules</code></strong> — the name is misspelled, or you added a file extension. Use the short name only.</li> |
| 107 | 107 | <li><strong>Module loads but the plugin still says the native is missing</strong> — the plugin was compiled without the module's <code>.inc</code>, or against a different version of it. Recompile with the matching include; see <a href="/tutorials/fix-reapi-native-not-found">native not found after installing ReAPI</a>.</li> |
| 108 | 108 | </ul> |
| @@ -111,5 +111,5 @@ chmod 644 /home/steam/hlds/cstrike/addons/amxmodx/modules/reapi_amxx_i386.so</pr | ||
| 111 | 111 | <ol> |
| 112 | 112 | <li><code>amxx modules</code> ends with <em>N modules, N correct</em>.</li> |
| 113 | 113 | <li><code>amxx plugins</code> shows nothing in <code>bad load</code>.</li> |
| 114 | -<li><code>addons/amxmodx/logs/error_*.log</code> has no <code>Module</code> lines after a restart.</li> | |
| 114 | +<li>The daily log, <code>addons/amxmodx/logs/LYYYYMMDD.log</code>, has no <code>Module</code> lines after a restart (module errors are written there, not to <code>error_*.log</code>).</li> | |
| 115 | 115 | </ol> |
install-cs16-dedicated-server-windows/en.md
M
| @@ -6,7 +6,7 @@ tags: "windows, hlds, server-setup" | ||
| 6 | 6 | image: "" |
| 7 | 7 | read_time: "8 min read" |
| 8 | 8 | --- |
| 9 | -<p>A Windows CS 1.6 server is the fastest way to get something running, and it is perfectly fine for a LAN, a test box, or a small public server. It is not what you want for a busy 32-slot public — Windows HLDS is measurably slower per tick than <code>hlds_linux</code> and the tooling around it is worse. But the install is short and the failure modes are well understood.</p> | |
| 9 | +<p>A Windows CS 1.6 server is the fastest way to get something running, and it is perfectly fine for a LAN, a test box, or a small public server. It is not what you want for a busy 32-slot public — Windows sleeps less precisely between server frames than Linux, so a high, steady server FPS is harder to hold, and the tooling around it is worse. But the install is short and the failure modes are well understood.</p> | |
| 10 | 10 | |
| 11 | 11 | <h2>1. Download SteamCMD</h2> |
| 12 | 12 | <p>Grab <code>steamcmd.zip</code> from Valve's developer wiki and extract it to a path with <strong>no spaces and no non-ASCII characters</strong> — for example <code>C:\steamcmd</code>. Paths like <code>C:\Users\Bogdan\Desktop\Neue Ordner\</code> break the HLDS console in ways that are not worth debugging.</p> |
| @@ -56,9 +56,8 @@ pause</pre> | ||
| 56 | 56 | |
| 57 | 57 | <h2>5. Windows Firewall</h2> |
| 58 | 58 | <p>Windows will pop a prompt the first time <code>hlds.exe</code> binds a socket, and people reflexively click <em>Cancel</em>. Add the rules explicitly instead. Open an <strong>Administrator</strong> PowerShell:</p> |
| 59 | -<pre>New-NetFirewallRule -DisplayName "HLDS UDP 27015" -Direction Inbound -Protocol UDP -LocalPort 27015 -Action Allow | |
| 60 | -New-NetFirewallRule -DisplayName "HLDS TCP 27015" -Direction Inbound -Protocol TCP -LocalPort 27015 -Action Allow</pre> | |
| 61 | -<p>UDP 27015 is the game. TCP 27015 is RCON. If your server is at home behind a router, you also need to forward both to the machine's LAN IP — see <a href="/tutorials/run-cs16-server-behind-nat">running a server behind NAT</a>.</p> | |
| 59 | +<pre>New-NetFirewallRule -DisplayName "HLDS UDP 27015" -Direction Inbound -Protocol UDP -LocalPort 27015 -Action Allow</pre> | |
| 60 | +<p>UDP 27015 carries the game, server queries and RCON: GoldSrc RCON uses the game's UDP port, so HLDS needs no TCP rule. If your server is at home behind a router, you also need to forward UDP 27015 to the machine's LAN IP — see <a href="/tutorials/run-cs16-server-behind-nat">running a server behind NAT</a>.</p> | |
| 62 | 61 | |
| 63 | 62 | <h2>6. Optional: run it as a service</h2> |
| 64 | 63 | <p>HLDS has no service mode. If you want it to survive a reboot without a logged-in session, the practical options are Task Scheduler (trigger: <em>At startup</em>, run whether user is logged on or not, working directory <code>C:\hlds</code>) or a supervisor such as NSSM. Task Scheduler is enough for most people; just remember to set <strong>Start in</strong> to <code>C:\hlds</code> or HLDS will not find <code>cstrike</code> and will die with <code>Could not find liblist.gam</code>.</p> |
install-rechecker/en.md
M
| @@ -22,40 +22,52 @@ linux addons/amxmodx/dlls/amxmodx_mm_i386.so</pre> | ||
| 22 | 22 | <p>Restart. Metamod plugins load at server start, not on map change.</p> |
| 23 | 23 | |
| 24 | 24 | <h2>2. resources.ini — the rules</h2> |
| 25 | -<p>This is the whole product. Each line is a check against a client-side file path, an expected hash (or a keyword), and an action.</p> | |
| 26 | -<pre>; <file> <hash or keyword> <action> ["message"] | |
| 25 | +<p>This is the whole product. Each line names a client-side file, a hash or keyword, and a server command to run when the rule matches, plus an optional flag.</p> | |
| 26 | +<pre>; "file" hash-or-keyword "server command" (or IGNORE) [flag] | |
| 27 | 27 | |
| 28 | -; kick anyone whose opengl32.dll differs from the one we expect | |
| 29 | -"opengl32.dll" "d41d8cd98f00b204e9800998ecf8427e" "kick" "Modified opengl32.dll" | |
| 28 | +; any opengl32.dll in the game root (this rule is in the shipped sample) | |
| 29 | +"../opengl32.dll" UNKNOWN "kick [userid] 'OpenGL32 Detected'" BREAK | |
| 30 | 30 | |
| 31 | -; the file must not exist at all | |
| 32 | -"cstrike/wallhack.cfg" "missing" "kick" "Cheat config detected" | |
| 31 | +; a cheat config: UNKNOWN fires when the file EXISTS, with any hash | |
| 32 | +"wallhack.cfg" UNKNOWN "kick [userid] 'Cheat config detected'" BREAK | |
| 33 | 33 | |
| 34 | -; the file must exist and match, or the client is kicked | |
| 35 | -"cstrike/models/player/vip/vip.mdl" "<md5>" "kick" "Bad player model" | |
| 34 | +; a model you ship: whitelist its hash (yours, not 1a2b3c4d), act on any other | |
| 35 | +"models/player/vip/vip.mdl" 1a2b3c4d IGNORE | |
| 36 | +"models/player/vip/vip.mdl" UNKNOWN "kick [userid] 'Bad player model'" BREAK | |
| 36 | 37 | |
| 37 | -; log only, do not act — use this while you are calibrating | |
| 38 | -"cstrike/config.cfg" "any" "log"</pre> | |
| 39 | -<p>Actions available in typical builds: <code>kick</code>, <code>log</code>, <code>console</code>, and passing the result to a plugin. Read the <code>resources.ini</code> that ships with your build for the exact keyword set — it has changed between versions and inventing an action silently disables the rule.</p> | |
| 38 | +; log only, do not act: use this while you are calibrating | |
| 39 | +"../hw.dll" UNKNOWN "echo '[rch] [file_name] [file_md5hash] [steamid] [name]'"</pre> | |
| 40 | +<p>There are no action keywords: the third column is an ordinary server command, run when the rule fires. Single quotes in it become double quotes, and <code>[userid]</code>, <code>[name]</code>, <code>[steamid]</code>, <code>[ip]</code>, <code>[id]</code>, <code>[file_name]</code>, <code>[file_hash]</code> and <code>[file_md5hash]</code> are filled in. The only keywords are these:</p> | |
| 41 | +<ul> | |
| 42 | +<li><code>UNKNOWN</code> (hash column) - fires when the file exists with any hash that is not whitelisted by an <code>IGNORE</code> line above it.</li> | |
| 43 | +<li><code>MISSING</code> (hash column) - fires when the file is <em>absent</em>. That is the opposite of a cheat-file rule: a <code>MISSING</code> rule on a cheat file fires on every clean client.</li> | |
| 44 | +<li><code>IGNORE</code> (in place of the command) - whitelists that hash for that file.</li> | |
| 45 | +<li><code>BREAK</code> (optional last column) - once this rule fires, ReChecker runs no later rule's command for that player.</li> | |
| 46 | +</ul> | |
| 47 | +<p>Anything else in the hash column is read as a hex hash, so a misspelled keyword becomes a rule that silently never matches. Paths are relative to the client's <code>cstrike</code> folder, and <code>../</code> reaches the game root. Note that the <code>resources.ini</code> in the release archive is a live rule set, not a template: nearly all of its rules kick, so read it before you start the server with it.</p> | |
| 40 | 48 | |
| 41 | 49 | <h2>3. Get the hashes right</h2> |
| 42 | 50 | <p>The hash in <code>resources.ini</code> must be the MD5 of the file <strong>as it exists on the client</strong>, not on your server. For files you ship (custom models, sprites, sounds), those are the same file, so:</p> |
| 43 | 51 | <pre>md5sum cstrike/models/player/vip/vip.mdl</pre> |
| 52 | +<p>ReChecker only compares the first 8 hex characters (4 bytes) of the MD5, which is why the sample file lists hashes like <code>3cc7f256</code>. Writing the full 32-character MD5 also works; only its first 8 characters count.</p> | |
| 44 | 53 | <p>For client-side game files (<code>opengl32.dll</code>, <code>hw.dll</code>), they are <em>not</em> the same — you need the hash from a clean client install, and it differs between the Steam build and every non-Steam build in circulation. This is where people get themselves into trouble.</p> |
| 45 | 54 | |
| 46 | 55 | <h2>4. Start in log-only mode. Always.</h2> |
| 47 | -<p>Set every rule to <code>log</code> for the first week. Then read what actually shows up:</p> | |
| 48 | -<pre>tail -f /home/steam/hlds/cstrike/addons/rechecker/rechecker.log</pre> | |
| 56 | +<p>For the first week, give every rule an <code>echo</code> command instead of a <code>kick</code> (like the last rule in section 2), and turn on ReChecker's own log by adding this to <code>server.cfg</code>:</p> | |
| 57 | +<pre>rch_log 1</pre> | |
| 58 | +<p>With <code>rch_log 1</code>, ReChecker writes a line for every rule that fires, including the client's hash as <code>md5hex</code> and the exact command it ran, to a dated file in <code>addons/rechecker/logs/</code> named <code>L_DD_MM_YYYY.log</code>. <code>rch_log 2</code> also logs every <code>IGNORE</code> rule check and the rule list loaded at each map start. ReChecker re-reads <code>resources.ini</code> at every map load, so a <code>changelevel</code> applies your edits. Then read what actually shows up:</p> | |
| 59 | +<pre>tail -f "$(ls -t /home/steam/hlds/cstrike/addons/rechecker/logs/L_*.log | head -1)"</pre> | |
| 49 | 60 | <p>You will discover that legitimate players have a dozen different <code>opengl32.dll</code> hashes, because they are on different client builds — Steam, <code>steam_legacy</code>, and half a dozen non-Steam packs. If you had shipped that rule as <code>kick</code>, you would have kicked most of your regulars on day one. That is exactly the failure described in <a href="/tutorials/fix-rechecker-kicking-legit-players">ReChecker kicking legitimate players</a>, and it is entirely avoidable by not skipping this step.</p> |
| 50 | 61 | <p>Only after you have a week of logs, and you understand which hashes are normal on <em>your</em> player base, do you convert a rule to <code>kick</code>. Convert one rule at a time.</p> |
| 62 | +<p>Whitelist each legitimate hash with an <code>IGNORE</code> line placed <em>above</em> the <code>UNKNOWN</code> rule for that file, because ReChecker reads the file top to bottom. Copy the <code>md5hex</code> value from the log, not <code>got</code> (the same bytes reversed), and pad it back to 8 characters if the log dropped a leading zero.</p> | |
| 51 | 63 | |
| 52 | 64 | <h2>5. Verify</h2> |
| 53 | 65 | <pre>meta list</pre> |
| 54 | -<pre> [ 1] ReChecker RUN - rechecker_mm_i386. 2.x ini Start ANY</pre> | |
| 66 | +<pre> [ 1] Rechecker RUN - rechecker_mm_i386. 2.x ini Chlvl ANY</pre> | |
| 55 | 67 | <p>Then test the pipeline end to end with a rule you can trigger on purpose. Create a file on a test client:</p> |
| 56 | 68 | <pre>echo test > cstrike/rechecker_test.cfg</pre> |
| 57 | -<p>and a rule:</p> | |
| 58 | -<pre>"cstrike/rechecker_test.cfg" "missing" "kick" "Test rule"</pre> | |
| 69 | +<p>and a rule, then <code>changelevel</code> so ReChecker reads it:</p> | |
| 70 | +<pre>"rechecker_test.cfg" UNKNOWN "kick [userid] 'Test rule'"</pre> | |
| 59 | 71 | <p>Connect from that client. You should be kicked with your message. Connect from a client without the file — you should not be. That proves the plugin loads, parses the config, queries the client, and acts on the answer. Nothing short of that proves ReChecker is working.</p> |
| 60 | 72 | |
| 61 | 73 | <h2>Rules that are worth writing</h2> |
| @@ -68,15 +80,16 @@ linux addons/amxmodx/dlls/amxmodx_mm_i386.so</pre> | ||
| 68 | 80 | <h2>Common errors</h2> |
| 69 | 81 | <ul> |
| 70 | 82 | <li><strong><code>bad load</code> in <code>meta list</code></strong> — wrong architecture. <code>file rechecker_mm_i386.so</code> must report <em>ELF 32-bit, Intel 80386</em>. See <a href="/tutorials/fix-metamod-bad-load">bad load</a>.</li> |
| 71 | -<li><strong>Rules never fire</strong> — <code>resources.ini</code> is in the wrong directory, or a syntax error made the parser drop the file. It must sit next to the <code>.so</code> in <code>addons/rechecker/</code>.</li> | |
| 72 | -<li><strong>Everyone gets kicked at once</strong> — you hashed a file from <em>your</em> machine and it does not match any real client. Set the rule back to <code>log</code> immediately, then read the logs.</li> | |
| 83 | +<li><strong>Rules never fire</strong> - <code>resources.ini</code> is in the wrong directory (it must sit next to the <code>.so</code> in <code>addons/rechecker/</code>, and a missing file produces no message at all), a line failed to parse (ReChecker skips that line and prints <code>Failed to load "resources.ini"</code> with the reason and line number in the console at map load), or a misspelled keyword is being read as a hash.</li> | |
| 84 | +<li><strong>Everyone gets kicked at once</strong> - you hashed a file from <em>your</em> machine and it does not match any real client. Switch the rule's command back to <code>echo</code> and <code>changelevel</code>, or run <code>meta unload rechecker</code> to stop it instantly, then read the logs. <a href="/tutorials/fix-rechecker-kicking-legit-players">ReChecker kicking legitimate players</a> has the full recovery.</li> | |
| 85 | +<li><strong>Every clean player is kicked by a cheat-file rule</strong> - the rule uses <code>MISSING</code>, which fires when the file is absent. Use <code>UNKNOWN</code> to act when a file is present.</li> | |
| 73 | 86 | <li><strong>Non-Steam players are kicked, Steam players are not</strong> — you are hashing a client binary. Non-Steam builds differ. Drop that rule.</li> |
| 74 | 87 | </ul> |
| 75 | 88 | |
| 76 | 89 | <h2>Verification checklist</h2> |
| 77 | 90 | <ol> |
| 78 | 91 | <li><code>meta list</code> — ReChecker <code>RUN</code>.</li> |
| 79 | -<li>The log file is being written with entries for connecting players.</li> | |
| 92 | +<li><code>rch_log 1</code> is set, and <code>addons/rechecker/logs/</code> gets an entry whenever one of your echo rules fires.</li> | |
| 80 | 93 | <li>A deliberately-planted test file triggers a kick with your message.</li> |
| 81 | 94 | <li>After a week in log-only mode, zero legitimate players would have been kicked by your rules.</li> |
| 82 | 95 | </ol> |
install-rehlds-on-linux/en.md
M
| @@ -26,28 +26,33 @@ cp hlds_linux hlds_linux.valve.bak | ||
| 26 | 26 | cp /path/to/rehlds/engine_i486.so ./engine_i486.so |
| 27 | 27 | cp /path/to/rehlds/hlds_linux ./hlds_linux |
| 28 | 28 | chmod +x hlds_linux hlds_run</pre> |
| 29 | -<p>Both files go in the <strong>server root</strong> (next to <code>hlds_run</code>), never inside <code>cstrike/</code>. Copying <code>engine_i486.so</code> into <code>cstrike/</code> is a classic mistake — the server keeps running the Valve engine and you spend an hour wondering why <code>rehlds_version</code> is unknown.</p> | |
| 29 | +<p>Both files go in the <strong>server root</strong> (next to <code>hlds_run</code>), never inside <code>cstrike/</code>. Copying <code>engine_i486.so</code> into <code>cstrike/</code> is a classic mistake — the server keeps running the Valve engine and you spend an hour wondering why <code>version</code> shows no <code>ReHLDS version:</code> line.</p> | |
| 30 | 30 | |
| 31 | 31 | <h2>4. Start the server</h2> |
| 32 | 32 | <pre>cd /home/steam/hlds |
| 33 | 33 | ./hlds_run -game cstrike -strictportbind -ip 0.0.0.0 -port 27015 \ |
| 34 | 34 | +map de_dust2 +maxplayers 20 +sv_lan 0</pre> |
| 35 | -<p>On startup ReHLDS prints its banner. Look for a line naming ReHLDS and its version — if you only see the Valve <code>Half-Life Dedicated Server</code> banner, the engine file was not replaced.</p> | |
| 35 | +<p>The startup output looks the same as Valve's (<code>Protocol version</code>, <code>Exe version</code> and <code>Exe build</code> lines) and does not name ReHLDS, so do not judge by it. The check in the next step is the one that counts.</p> | |
| 36 | 36 | |
| 37 | 37 | <h2>5. Verify it is actually running</h2> |
| 38 | 38 | <p>In the server console:</p> |
| 39 | -<pre>rehlds_version</pre> | |
| 40 | -<p>A stock HLDS answers <code>Unknown command: rehlds_version</code>. ReHLDS prints its version string. That single command is the whole verification — do not trust the file timestamp, trust the cvar.</p> | |
| 39 | +<pre>version</pre> | |
| 40 | +<p>ReHLDS prints a line starting <code>ReHLDS version:</code> with its version number, followed by <code>Build date</code> and <code>Build from</code> lines. A stock HLDS prints only the <code>Protocol version</code>, <code>Exe version</code> and <code>Exe build</code> lines. That single command is the whole verification — do not trust the file timestamp, trust the command.</p> | |
| 41 | 41 | |
| 42 | 42 | <h2>6. ReHLDS-specific cvars worth setting</h2> |
| 43 | 43 | <p>Put these in <code>cstrike/server.cfg</code>. They are the reason people install ReHLDS in the first place:</p> |
| 44 | -<pre>// reject malformed / oversized packets instead of crashing | |
| 44 | +<pre>// optional behaviour fixes, not packet filters: | |
| 45 | +// stops fast leg animation on players with attached models (can lag at low cl_updaterate) | |
| 45 | 46 | sv_rehlds_attachedentities_playeranimationspeed_fix 1 |
| 47 | +// per-client game clock, reduces lag when one map runs a long time | |
| 46 | 48 | sv_rehlds_local_gametime 1 |
| 49 | +// do not send mapcycle.txt to clients (they never use it; this is the default) | |
| 47 | 50 | sv_rehlds_send_mapcycle 0 |
| 48 | 51 | |
| 49 | -// hardening | |
| 52 | +// send in-game downloads in full 1024-byte fragments, ignoring the client's cl_dlmax | |
| 50 | 53 | sv_rehlds_force_dlmax 1 |
| 54 | + | |
| 55 | +// hardening | |
| 51 | 56 | sv_filterban 1 |
| 52 | 57 | sv_rcon_maxfailures 5 |
| 53 | 58 | sv_rcon_minfailures 5 |
| @@ -67,7 +72,7 @@ sv_rcon_minfailuretime 30</pre> | ||
| 67 | 72 | |
| 68 | 73 | <h2>Common errors</h2> |
| 69 | 74 | <ul> |
| 70 | -<li><strong><code>Unknown command: rehlds_version</code></strong> — the engine was not replaced. You copied <code>engine_i486.so</code> to the wrong directory, or you are launching a different <code>hlds_linux</code> (check with <code>ps aux | grep hlds</code> and look at the path).</li> | |
| 75 | +<li><strong><code>version</code> shows no <code>ReHLDS version:</code> line</strong> — the engine was not replaced. You copied <code>engine_i486.so</code> to the wrong directory, or you are launching a different <code>hlds_linux</code> (check with <code>ps aux | grep hlds</code> and look at the path).</li> | |
| 71 | 76 | <li><strong><code>Segmentation fault</code> immediately at startup</strong> — mismatched binaries: a 64-bit build of something in the chain, or a Metamod version that predates the ReHLDS API. Confirm with <code>file engine_i486.so</code>; it must say <code>ELF 32-bit LSB shared object, Intel 80386</code>. If it says x86-64, you downloaded the wrong archive.</li> |
| 72 | 77 | <li><strong><code>Host_Error: Couldn't get DLL API from ./cstrike/dlls/cs.so</code></strong> — your ReGameDLL build is older or newer than the ReHLDS engine's expected interface. Update both to the current releases; see <a href="/tutorials/fix-regamedll-rehlds-incompatible">ReGameDLL/ReHLDS incompatibility</a>.</li> |
| 73 | 78 | <li><strong>Metamod plugins show <code>bad load</code></strong> after the switch — you are on classic Metamod with an old ABI. Move to Metamod-r, or read <a href="/tutorials/fix-metamod-bad-load">the bad load fix</a>.</li> |
| @@ -78,11 +83,11 @@ sv_rcon_minfailuretime 30</pre> | ||
| 78 | 83 | <pre>cd /home/steam/hlds |
| 79 | 84 | cp engine_i486.so.valve.bak engine_i486.so |
| 80 | 85 | cp hlds_linux.valve.bak hlds_linux</pre> |
| 81 | -<p>Restart, run <code>rehlds_version</code>, and confirm it is unknown again. Keep those <code>.bak</code> files — they are the only trivially available copy of the Valve engine once you have overwritten it, short of re-running <code>app_update 90 validate</code> (which, usefully, also restores them).</p> | |
| 86 | +<p>Restart, run <code>version</code>, and confirm the <code>ReHLDS version:</code> line is gone. Keep those <code>.bak</code> files — they are the only trivially available copy of the Valve engine once you have overwritten it, short of re-running <code>app_update 90 validate</code> (which, usefully, also restores them).</p> | |
| 82 | 87 | |
| 83 | 88 | <h2>Verification checklist</h2> |
| 84 | 89 | <ul> |
| 85 | -<li><code>rehlds_version</code> returns a version string.</li> | |
| 90 | +<li><code>version</code> prints a <code>ReHLDS version:</code> line.</li> | |
| 86 | 91 | <li>The server reaches a map and accepts a client connection.</li> |
| 87 | 92 | <li><code>meta list</code> (if Metamod is installed) shows every plugin as <code>RUN</code>.</li> |
| 88 | 93 | <li>The log has no repeating warnings on map change.</li> |
install-reunion/en.md
M
| @@ -10,9 +10,9 @@ read_time: "8 min read" | ||
| 10 | 10 | |
| 11 | 11 | <h2>1. Confirm the prerequisites</h2> |
| 12 | 12 | <p>You need ReHLDS running and Metamod (use <a href="/tutorials/install-metamod-r">Metamod-r</a>) already loading. Verify both before touching Reunion:</p> |
| 13 | -<pre>rehlds_version | |
| 13 | +<pre>version | |
| 14 | 14 | meta list</pre> |
| 15 | -<p>If <code>rehlds_version</code> is <code>Unknown command</code>, stop and install ReHLDS first — Reunion on plain HLDS is a dead end.</p> | |
| 15 | +<p>If <code>version</code> prints no <code>ReHLDS version:</code> line, stop and install ReHLDS first — Reunion on plain HLDS is a dead end.</p> | |
| 16 | 16 | |
| 17 | 17 | <h2>2. Place the Reunion files</h2> |
| 18 | 18 | <p>Download the current Reunion release archive from the project's GitHub releases page. It contains the Metamod plugin and a sample config. On Linux the layout is:</p> |
install-revoice/en.md
M
| @@ -6,18 +6,18 @@ tags: "revoice, voice" | ||
| 6 | 6 | image: "" |
| 7 | 7 | read_time: "8 min read" |
| 8 | 8 | --- |
| 9 | -<p>Voice chat in CS 1.6 is a codec problem. Steam clients speak <strong>SILK</strong> (introduced with the Steam voice update); older and non-Steam clients speak the legacy <strong>Speex</strong> codec, and some builds speak <strong>Opus</strong>. On a mixed server, half your players press their voice key and the other half hear nothing. <strong>ReVoice</strong> is a Metamod plugin that transcodes between these codecs on the server, so everyone hears everyone.</p> | |
| 9 | +<p>Voice chat in CS 1.6 is a codec problem. Steam clients send voice in Steam's own format: <strong>Opus</strong> on current builds, <strong>SILK</strong> on older Steam builds. Clients on older builds, including classic non-Steam builds, speak the legacy <strong>Speex</strong> codec. On a mixed server, half your players press their voice key and the other half hear nothing. <strong>ReVoice</strong> is a Metamod plugin that transcodes between these codecs on the server, so everyone hears everyone.</p> | |
| 10 | 10 | |
| 11 | 11 | <p>If your server is Steam-only, you do not need ReVoice. If you accept non-Steam players — which, if you run <a href="/tutorials/install-reunion">Reunion</a> or <a href="/tutorials/install-dproto">dproto</a>, you do — you almost certainly do.</p> |
| 12 | 12 | |
| 13 | 13 | <h2>1. Prerequisites</h2> |
| 14 | 14 | <ul> |
| 15 | -<li>ReHLDS (ReVoice is built for it; it is not guaranteed on stock HLDS).</li> | |
| 15 | +<li>ReHLDS. ReVoice will not load on stock HLDS: it stops with <code>[REVOICE]: Failed to locate REHLDS API</code>.</li> | |
| 16 | 16 | <li>Metamod loaded — <code>meta version</code> must answer. See <a href="/tutorials/install-metamod-r">Metamod-r</a>.</li> |
| 17 | +<li><a href="/tutorials/install-reunion">Reunion</a>, loaded above ReVoice. ReVoice asks for Reunion's API when it loads and refuses to start without it (<code>[REVOICE]: Failed to locate Reunion api</code>). It needs Reunion specifically, so it does not work with dproto.</li> | |
| 17 | 18 | <li>Voice enabled at all on the server. This is easy to forget: |
| 18 | -<pre>sv_voiceenable 1 | |
| 19 | -sv_voicecodec voice_speex | |
| 20 | -sv_voicequality 5</pre> | |
| 19 | +<pre>sv_voiceenable 1</pre> | |
| 20 | +Older guides also set <code>sv_voicecodec</code> and <code>sv_voicequality</code> here. ReHLDS does not have those cvars, so they do nothing; ReVoice sends each client its codec setup itself. | |
| 21 | 21 | </li> |
| 22 | 22 | </ul> |
| 23 | 23 | |
| @@ -28,31 +28,29 @@ cp revoice_mm_i386.so /home/steam/hlds/cstrike/addons/revoice/ | ||
| 28 | 28 | cp revoice.cfg /home/steam/hlds/cstrike/addons/revoice/ |
| 29 | 29 | chmod 644 /home/steam/hlds/cstrike/addons/revoice/*</pre> |
| 30 | 30 | <p>Add it to <code>cstrike/addons/metamod/plugins.ini</code>:</p> |
| 31 | -<pre>linux addons/revoice/revoice_mm_i386.so | |
| 31 | +<pre>linux addons/reunion/reunion_mm_i386.so | |
| 32 | +linux addons/revoice/revoice_mm_i386.so | |
| 32 | 33 | linux addons/amxmodx/dlls/amxmodx_mm_i386.so</pre> |
| 33 | -<p>Order in <code>plugins.ini</code> is load order. ReVoice is fine anywhere, but keeping the voice/protocol plugins above AMXX is the convention and it makes <code>meta list</code> easier to read.</p> | |
| 34 | +<p>Order in <code>plugins.ini</code> is load order, and here it matters: Reunion must be above ReVoice, because ReVoice looks up Reunion's API at the moment it loads and refuses to start if Reunion is not loaded yet. Keeping both above AMXX is the convention. On Windows the lines start with <code>win32</code> and point at <code>reunion_mm.dll</code> and <code>revoice_mm.dll</code>.</p> | |
| 34 | 35 | |
| 35 | 36 | <h2>3. Configure revoice.cfg</h2> |
| 36 | -<p>The config controls which codecs ReVoice will accept from clients and which it hands back. The important settings:</p> | |
| 37 | -<pre>// codec used to talk to legacy / non-Steam clients | |
| 38 | -revoice_default_codec "silk" | |
| 39 | - | |
| 40 | -// bitrate for the SILK stream; higher = clearer, more bandwidth | |
| 41 | -revoice_silk_bitrate 16000 | |
| 42 | - | |
| 43 | -// how to handle clients whose codec is unknown | |
| 44 | -revoice_speex_quality 5</pre> | |
| 45 | -<p>Read the <code>revoice.cfg</code> that ships with your build rather than copying a cvar list from a forum — the cvar names have changed between versions, and setting a cvar that does not exist is a silent no-op. Whatever you set, keep <code>sv_voicecodec</code> in <code>server.cfg</code> consistent with what ReVoice expects; a mismatch there is the classic "nobody can hear anybody" configuration.</p> | |
| 37 | +<p>The release ships a two-line <code>revoice.cfg</code>, and these are the only two settings ReVoice has:</p> | |
| 38 | +<pre>REV_HltvCodec opus // speex, opus | |
| 39 | +REV_DefaultCodec speex // speex, opus</pre> | |
| 40 | +<p><code>REV_DefaultCodec</code> is the codec ReVoice assumes for a client unless it identifies as a newer build: on connect, ReVoice asks a protocol 48 client for its <code>sv_version</code> and handles build numbers above 4554 as Opus. Everyone else gets this value, so leave it on <code>speex</code>; set to <code>opus</code>, ReVoice would decode the old builds' Speex packets as Opus. <code>REV_HltvCodec</code> is the codec used for HLTV. There is no bitrate or quality setting: ReVoice tells every client to use Speex at quality 5 by itself.</p> | |
| 41 | +<p>ReVoice executes this file from its own folder, <code>cstrike/addons/revoice/revoice.cfg</code>, at every map start, so a copy anywhere else is never read. Any other cvar name you find in a forum copy of this file (bitrates, quality levels) is not a ReVoice setting and does nothing.</p> | |
| 46 | 42 | |
| 47 | 43 | <h2>4. Restart and verify</h2> |
| 48 | 44 | <p>Metamod plugins load at server start.</p> |
| 49 | 45 | <pre>meta list</pre> |
| 50 | 46 | <pre>Currently loaded plugins: |
| 51 | 47 | description stat pend file vers src load unload |
| 52 | - [ 1] ReVoice RUN - revoice_mm_i386.so 0.1.x ini Start ANY | |
| 53 | - [ 2] AMX Mod X RUN - amxmodx_mm_i386.so 1.9.0 ini Start ANY | |
| 54 | -2 plugins, 2 running</pre> | |
| 48 | + [ 1] Reunion RUN - reunion_mm_i386.so 0.2.x ini Start Never | |
| 49 | + [ 2] Revoice RUN - revoice_mm_i386.so 0.1.x ini Start Never | |
| 50 | + [ 3] AMX Mod X RUN - amxmodx_mm_i386.so 1.9.0 ini Start ANY | |
| 51 | +3 plugins, 3 running</pre> | |
| 55 | 52 | <p>ReVoice must be <code>RUN</code>. <code>bad load</code> means the binary is the wrong architecture or built against an incompatible Metamod API — see <a href="/tutorials/fix-metamod-bad-load">bad load</a>.</p> |
| 53 | +<p><code>fail</code> means the file loaded but ReVoice refused to start. The startup output says why: <code>[REVOICE]: Failed to locate REHLDS API</code> (you are on stock HLDS) or <code>[REVOICE]: Failed to locate Reunion api</code> (Reunion is missing or listed below ReVoice).</p> | |
| 56 | 54 | |
| 57 | 55 | <h2>5. The real test</h2> |
| 58 | 56 | <p>Console output proves nothing about voice. You need two clients:</p> |
| @@ -73,16 +71,17 @@ voice_loopback 1 // temporarily: they hear themselves back</pre> | ||
| 73 | 71 | |
| 74 | 72 | <h2>Common errors</h2> |
| 75 | 73 | <ul> |
| 76 | -<li><strong>ReVoice is <code>RUN</code> but nobody hears anything</strong> — <code>sv_voiceenable</code> is 0, or <code>sv_voicecodec</code> is unset. Check in the console with <code>sv_voiceenable</code> (no argument prints the value).</li> | |
| 77 | -<li><strong>Only Steam players hear each other</strong> — ReVoice is not actually loaded (check <code>meta list</code>, not the file on disk), or its codec config does not cover the legacy codec.</li> | |
| 78 | -<li><strong>Voice is choppy or robotic</strong> — bitrate too high for your players' upstream, or the server is bandwidth-starved. Lower the SILK bitrate.</li> | |
| 74 | +<li><strong>ReVoice is <code>RUN</code> but nobody hears anything</strong> - <code>sv_voiceenable</code> is 0, and ReVoice discards every voice packet. Check in the console with <code>sv_voiceenable</code> (no argument prints the value).</li> | |
| 75 | +<li><strong>Only Steam players hear each other</strong> - ReVoice is not actually loaded (check <code>meta list</code>, not the file on disk), or <code>REV_DefaultCodec</code> is set to something other than <code>speex</code>.</li> | |
| 76 | +<li><strong>Voice is choppy or robotic</strong> - ReVoice has no bitrate to tune. Run <code>rev status</code> in the server console to see the codec ReVoice assigned each player (Steam clients should show <code>opus</code>, old non-Steam builds <code>speex</code>); a player on the wrong codec comes out as noise. Otherwise look at packet loss and the players' <code>rate</code>: voice travels in the unreliable part of each update and is dropped when there is no room.</li> | |
| 77 | +<li><strong><code>fail</code> in <code>meta list</code></strong> - ReHLDS or Reunion is missing, or Reunion is listed below ReVoice. The <code>[REVOICE]:</code> line in the startup output names which.</li> | |
| 79 | 78 | <li><strong><code>bad load</code></strong> — wrong architecture. <code>file revoice_mm_i386.so</code> must report <em>ELF 32-bit, Intel 80386</em>.</li> |
| 80 | 79 | <li><strong>Works on Steam clients, silent on non-Steam</strong> — the classic case; walk through <a href="/tutorials/fix-revoice-no-voice-nonsteam">non-Steam players have no voice</a>.</li> |
| 81 | 80 | </ul> |
| 82 | 81 | |
| 83 | 82 | <h2>Verification checklist</h2> |
| 84 | 83 | <ol> |
| 85 | -<li><code>meta list</code> — ReVoice <code>RUN</code>.</li> | |
| 84 | +<li><code>meta list</code> - Reunion and ReVoice both <code>RUN</code>, Reunion listed above ReVoice.</li> | |
| 86 | 85 | <li><code>sv_voiceenable</code> prints <code>1</code>.</li> |
| 87 | 86 | <li>A Steam client and a non-Steam client hear each other, in both directions.</li> |
| 88 | 87 | <li>No voice-related spam in the server log during a full map.</li> |
rehlds-performance-cvars/en.md
M
| @@ -6,20 +6,20 @@ tags: "rehlds, cvars" | ||
| 6 | 6 | image: "" |
| 7 | 7 | read_time: "8 min read" |
| 8 | 8 | --- |
| 9 | -<p>The biggest performance win from ReHLDS is the rewritten engine itself — more accurate frame timing and a faster network path than Valve's original. On top of that it exposes a set of <code>sv_rehlds_*</code> cvars that do not exist on stock HLDS. Most of them are correctness or hardening switches rather than raw speed knobs, but several directly affect how the server behaves under load and under attack, which is what "performance" means once real players show up. This guide covers the ones worth setting and, just as important, how to introduce them safely.</p><p>This assumes you already run ReHLDS. If not, do <a href="/tutorials/install-rehlds-on-linux">the install</a> first — none of these commands exist on the Valve engine, and setting them there is a silent no-op.</p><h2>1. Confirm you are actually on ReHLDS</h2><pre>rehlds_version</pre><p>Stock HLDS answers <code>Unknown command: rehlds_version</code>. ReHLDS prints a version string. If you get the "unknown command" reply, the engine was not replaced and nothing below applies.</p><h2>2. Timing and tick rate</h2><p>ReHLDS holds a high <code>sys_ticrate</code> far more reliably than stock HLDS, which is the whole reason people chase it for FPS. Set the target as usual on the launch line:</p><pre>./hlds_run -game cstrike -pingboost 1 +sys_ticrate 1000 \ | |
| 10 | - +map de_dust2 +maxplayers 20 +sv_lan 0</pre><p>Then measure under load with <code>stats</code> as described in <a href="/tutorials/stable-1000-fps-linux-server">the stable-FPS guide</a>. On ReHLDS a 1000 target is realistic where stock HLDS would jitter.</p><h2>3. Anti-flood cvars protect FPS under attack</h2><p>A server does not only slow down from too many honest players — it slows down, or dies, when someone floods it with movement or string commands. ReHLDS ships rate limiters for exactly this. Add them to <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a>:</p><pre>// limit per-client command flooding | |
| 11 | -sv_rehlds_stringcmdrate_max_avg 80 | |
| 12 | -sv_rehlds_stringcmdrate_max_burst 200 | |
| 9 | +<p>The biggest performance win from ReHLDS is the rewritten engine itself — more accurate frame timing and a faster network path than Valve's original. On top of that it exposes a set of <code>sv_rehlds_*</code> cvars that do not exist on stock HLDS. Most of them are correctness or hardening switches rather than raw speed knobs, but several directly affect how the server behaves under load and under attack, which is what "performance" means once real players show up. This guide covers the ones worth setting and, just as important, how to introduce them safely.</p><p>This assumes you already run ReHLDS. If not, do <a href="/tutorials/install-rehlds-on-linux">the install</a> first — none of these commands exist on the Valve engine, and setting them there is a silent no-op.</p><h2>1. Confirm you are actually on ReHLDS</h2><pre>version</pre><p>ReHLDS prints a line starting <code>ReHLDS version:</code> with its version number. Stock HLDS prints only the <code>Protocol version</code>, <code>Exe version</code> and <code>Exe build</code> lines. If there is no <code>ReHLDS version:</code> line, the engine was not replaced and nothing below applies.</p><h2>2. Timing and tick rate</h2><p>ReHLDS holds a high <code>sys_ticrate</code> far more reliably than stock HLDS, which is the whole reason people chase it for FPS. Set the target as usual on the launch line:</p><pre>./hlds_run -game cstrike -pingboost 1 +sys_ticrate 1000 \ | |
| 10 | + +map de_dust2 +maxplayers 20 +sv_lan 0</pre><p>Then measure under load with <code>stats</code> as described in <a href="/tutorials/stable-1000-fps-linux-server">the stable-FPS guide</a>. On ReHLDS a 1000 target is realistic where stock HLDS would jitter.</p><h2>3. Anti-flood cvars protect FPS under attack</h2><p>A server does not only slow down from too many honest players — it slows down, or dies, when someone floods it with movement or string commands. ReHLDS ships rate limiters for exactly this. Add them to <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a>:</p><pre>// limit per-client command flooding (the compiled defaults) | |
| 11 | +sv_rehlds_stringcmdrate_max_avg 250 | |
| 12 | +sv_rehlds_stringcmdrate_max_burst 500 | |
| 13 | 13 | |
| 14 | 14 | // limit connections from a single address |
| 15 | -sv_rehlds_maxclients_from_single_ip 5</pre><p>These keep one abusive client from consuming a disproportionate share of the single server thread. Treat the numbers as starting points and read your ReHLDS build's own cvar list — exact names and defaults change between releases, and inventing a cvar just gets you a silent no-op.</p><h2>4. Network and download behaviour</h2><pre>// force the max client download rate the engine allows | |
| 15 | +sv_rehlds_maxclients_from_single_ip 5</pre><p>These keep one abusive client from consuming a disproportionate share of the single server thread. 250 and 500 are the defaults compiled into current builds; the ReHLDS developers raised them several times in 2015 and 2016, and going lower again makes it more likely that real players get kicked or IP-banned, see <a href="/tutorials/fix-crash-rehlds-security-cvars">crash or kicks after enabling ReHLDS security cvars</a>. Read your ReHLDS build's own cvar list — exact names and defaults change between releases, and inventing a cvar just gets you a silent no-op.</p><h2>4. Network and download behaviour</h2><pre>// full 1024-byte download fragments for in-game clients, ignoring their cl_dlmax | |
| 16 | 16 | sv_rehlds_force_dlmax 1 |
| 17 | 17 | |
| 18 | 18 | // do not push the mapcycle to clients |
| 19 | 19 | sv_rehlds_send_mapcycle 0 |
| 20 | 20 | |
| 21 | -// use engine-local gametime (fixes some timing-sensitive bugs) | |
| 22 | -sv_rehlds_local_gametime 1</pre><p><code>sv_rehlds_force_dlmax 1</code> smooths out custom-content downloads on connect, which is where a lot of "stuck at connecting" reports come from; pair it with a proper <a href="/tutorials/fix-fastdl-not-working">FastDL setup</a>. <code>sv_rehlds_local_gametime 1</code> is a correctness fix worth having on.</p><h2>5. Introduce them one batch at a time</h2><p>This is the part people skip and regret. Some hardening cvars interact badly with old plugins that build raw network messages by hand. Turn on one small group, restart, and watch the log through a map change and a few connects:</p><pre>rcon sv_rehlds_local_gametime 1 | |
| 21 | +// per-client game clock (reduces lag when one map runs a long time) | |
| 22 | +sv_rehlds_local_gametime 1</pre><p><code>sv_rehlds_force_dlmax 1</code> sets the fragment size, not a download rate: data the server sends in pieces to a client that is already in the game (other players' sprays, for example) goes out in full 1024-byte fragments instead of the size the client's <code>cl_dlmax</code> asks for. Downloads while a player connects already use that maximum, so the cvar does not fix "stuck at connecting"; for slow map downloads use a proper <a href="/tutorials/fix-fastdl-not-working">FastDL setup</a>. <code>sv_rehlds_local_gametime 1</code> is a correctness fix worth having on.</p><h2>5. Introduce them one batch at a time</h2><p>This is the part people skip and regret. Some hardening cvars interact badly with old plugins that build raw network messages by hand. Turn on one small group, restart, and watch the log through a map change and a few connects:</p><pre>rcon sv_rehlds_local_gametime 1 | |
| 23 | 23 | // restart, play a map, watch the console |
| 24 | 24 | rcon sv_rehlds_force_dlmax 1 |
| 25 | -// restart, watch again</pre><p>If the server starts crashing right after you enable a batch, you have found the culprit without a bisect. A plugin that dies under a new security cvar usually needs updating, not the cvar disabling forever.</p><h2>6. What ReHLDS cvars will not do</h2><p>No <code>sv_rehlds_*</code> cvar turns a saturated core into a fast one. If <code>stats</code> shows the core at 100%, the answer is a faster CPU, fewer or lighter plugins, or a lower <code>sys_ticrate</code> — not another cvar. Likewise, the rate window that players actually experience is governed by <a href="/tutorials/sv-maxrate-maxupdaterate-values">sv_maxrate and sv_maxupdaterate</a>, which are engine-agnostic and matter regardless of ReHLDS.</p><h2>Common errors</h2><ul><li><strong><code>Unknown command: sv_rehlds_...</code></strong> — you are not on ReHLDS, or the cvar name is wrong/renamed in your build. Verify with <code>rehlds_version</code> and read the shipped cvar list.</li><li><strong>Server crashes right after enabling a hardening cvar</strong> — an old plugin sends malformed messages the cvar now rejects. Enable in small batches to find it, then update the plugin.</li><li><strong>Set a cvar, nothing changed</strong> — a misspelled cvar is a no-op with no error in older builds. Copy the exact name from the release notes.</li><li><strong>FPS unchanged after tuning</strong> — you were CPU-bound all along. Measure first; the fix is hardware or plugin load, per <a href="/tutorials/fix-hlds-100-cpu">the 100% CPU guide</a>.</li></ul><h2>Verification</h2><p>After each batch, confirm <code>rehlds_version</code> still answers, the server reaches a map, and <code>meta list</code> (if Metamod is loaded) still shows every plugin as <code>RUN</code>. Load the server and re-measure FPS with <code>stats</code> to prove the timing held. The goal is a server that is not just fast when empty but stays fast and stable when someone tries to abuse it.</p> | |
| 25 | +// restart, watch again</pre><p>If the server starts crashing right after you enable a batch, you have found the culprit without a bisect. A plugin that dies under a new security cvar usually needs updating, not the cvar disabling forever.</p><h2>6. What ReHLDS cvars will not do</h2><p>No <code>sv_rehlds_*</code> cvar turns a saturated core into a fast one. If <code>stats</code> shows the core at 100%, the answer is a faster CPU, fewer or lighter plugins, or a lower <code>sys_ticrate</code> — not another cvar. Likewise, the rate window that players actually experience is governed by <a href="/tutorials/sv-maxrate-maxupdaterate-values">sv_maxrate and sv_maxupdaterate</a>, which are engine-agnostic and matter regardless of ReHLDS.</p><h2>Common errors</h2><ul><li><strong><code>unknown command "sv_rehlds_..."</code></strong> (printed only when <code>sv_echo_unknown_cmd 1</code> is set) — the cvar name is wrong, or your build does not have it. Verify with <code>version</code> and read the shipped cvar list.</li><li><strong>Server crashes right after enabling a hardening cvar</strong> — usually it is not a crash: the flood limits are kicking or banning players (look for <code>Reason:</code> lines in the console), or a cvar such as <code>sv_rehlds_local_gametime</code> changed what clients receive and broke a plugin that builds its own messages. On 3.15.0.896, turning on speedhack punishment (<code>sv_rehlds_movecmdtime_max_warnings</code> 0 or higher) can really crash the server. Enable in small batches to find it, then see <a href="/tutorials/fix-crash-rehlds-security-cvars">crash after enabling ReHLDS security cvars</a>.</li><li><strong>Set a cvar, nothing changed</strong> — a misspelled cvar is a silent no-op unless <code>sv_echo_unknown_cmd 1</code> is set. Copy the exact name from the release notes.</li><li><strong>FPS unchanged after tuning</strong> — you were CPU-bound all along. Measure first; the fix is hardware or plugin load, per <a href="/tutorials/fix-hlds-100-cpu">the 100% CPU guide</a>.</li></ul><h2>Verification</h2><p>After each batch, confirm <code>version</code> still shows the <code>ReHLDS version:</code> line, the server reaches a map, and <code>meta list</code> (if Metamod is loaded) still shows every plugin as <code>RUN</code>. Load the server and re-measure FPS with <code>stats</code> to prove the timing held. The goal is a server that is not just fast when empty but stays fast and stable when someone tries to abuse it.</p> | |
| 26 | 26 |
