Add 6 tutorials (6 files)
Browse Source
Daemon666 committed
parent 2d774b7c2e
commit db14176168123828399dabeffd7e98a121ff4615
6 changed files
with 210 additions and 0 deletions
A
change-cs16-server-port/en.md
+58 -0
A
fix-allocblock-full/en.md
+10 -0
A
install-cs16-server-hetzner-vps/en.md
+56 -0
A
install-hltv-linux/en.md
+56 -0
A
migrate-cs16-server-to-new-vps/en.md
+17 -0
A
vis-optimization-hint-brushes/en.md
+13 -0
change-cs16-server-port/en.md
A
| @@ -0,0 +1,58 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Change the Port of a CS 1.6 Server (27015 to Anything)" | |
| 3 | +excerpt: "How to move a CS 1.6 server off the default UDP 27015 with the -port launch parameter, why setting it in server.cfg fails, and how to run several servers on one box." | |
| 4 | +category: "installation" | |
| 5 | +tags: "ports, config" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Every CS 1.6 server listens on <strong>UDP 27015</strong> by default. You change that when you run more than one server on a single machine, when a host has already claimed 27015, or when you simply want a memorable port. The important thing to get right first: the port is bound at the moment the engine starts its network socket, which is <em>before</em> <code>server.cfg</code> is ever read, so the port cannot be set from a cvar in that file. It is a launch parameter.</p> | |
| 10 | + | |
| 11 | +<h2>1. Set the port with -port on the command line</h2> | |
| 12 | +<p>Pass <code>-port</code> to <code>hlds_run</code> (or <code>hlds.exe</code>) with the UDP port you want:</p> | |
| 13 | +<pre>./hlds_run -game cstrike -port 27016 +map de_dust2 +maxplayers 20 +sv_lan 0</pre> | |
| 14 | +<p>On Windows the same flag applies to the shortcut or batch file:</p> | |
| 15 | +<pre>hlds.exe -console -game cstrike -port 27016 +map de_dust2 +maxplayers 20</pre> | |
| 16 | +<p>That single flag moves both the game traffic and the RCON channel to the new port, because CS 1.6 RCON runs over the same UDP port as the game. There is no separate RCON port to configure. See the full list of <a href="/tutorials/hlds-command-line-parameters">HLDS command-line parameters</a> for the flags that pair with this one.</p> | |
| 17 | + | |
| 18 | +<h2>2. Why a cvar in server.cfg does not work</h2> | |
| 19 | +<p>People try to add a <code>port</code> line to <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> and are surprised when the server still answers on 27015. The socket is already open by the time <code>server.cfg</code> executes, so changing the value there does nothing for the current session. Use <code>-port</code> at launch, every time. If you run through a <a href="/tutorials/hlds-systemd-service">systemd service</a>, put <code>-port</code> in the <code>ExecStart</code> line, not in a config.</p> | |
| 20 | + | |
| 21 | +<h2>3. Open the new port in the firewall</h2> | |
| 22 | +<p>A moved port is useless if the firewall still only permits 27015. Allow the new UDP port both inbound and outbound:</p> | |
| 23 | +<pre>ufw allow 27016/udp</pre> | |
| 24 | +<p>Remember CS 1.6 is <strong>UDP, not TCP</strong> — a TCP rule lets nothing through. The <a href="/tutorials/cs16-server-firewall-ports">firewall ports guide</a> covers the exact rules and the master-server ports you also need open.</p> | |
| 25 | + | |
| 26 | +<h2>4. Bind the address too when the box has several IPs</h2> | |
| 27 | +<p>On a machine with multiple public addresses, pair <code>-port</code> with <code>-ip</code> so the server binds the right interface:</p> | |
| 28 | +<pre>./hlds_run -game cstrike -ip 203.0.113.10 -port 27016 +maxplayers 20 +map de_dust2</pre> | |
| 29 | +<p>Without <code>-ip</code> the engine binds all interfaces on that port, which is usually fine on a single-IP VPS but a source of "couldn't allocate" errors when two servers fight over the same address and port.</p> | |
| 30 | + | |
| 31 | +<h2>5. Running several servers on one machine</h2> | |
| 32 | +<p>Each server needs a unique port. The convention is to step by one or more from 27015:</p> | |
| 33 | +<pre># server A | |
| 34 | +./hlds_run -game cstrike -port 27015 +maxplayers 20 +map de_dust2 | |
| 35 | +# server B | |
| 36 | +./hlds_run -game cstrike -port 27016 +maxplayers 24 +map de_inferno | |
| 37 | +# server C | |
| 38 | +./hlds_run -game cstrike -port 27017 +maxplayers 32 +map cs_office</pre> | |
| 39 | +<p>Give each its own directory or at least its own logs so you can tell them apart. All of them still need <code>sv_lan 0</code> to reach the master list, and each registers separately once its port is reachable.</p> | |
| 40 | + | |
| 41 | +<h2>6. How players connect to the new port</h2> | |
| 42 | +<p>Clients must include the port when it is not 27015. In the client console:</p> | |
| 43 | +<pre>connect 203.0.113.10:27016</pre> | |
| 44 | +<p>The default 27015 is implied when no port is given, which is why a moved server that "does not show up" for a friend is often just a missing <code>:port</code> in their connect string.</p> | |
| 45 | + | |
| 46 | +<h2>Common errors</h2> | |
| 47 | +<ul> | |
| 48 | +<li><strong>"Couldn't allocate dedicated server IP port"</strong> — another process already holds that port, or two servers were told the same one. Pick a free port and check with <code>ss -lunp | grep 2701</code>. The dedicated fix is in <a href="/tutorials/fix-couldnt-allocate-server-ip-port">couldn't allocate server IP/port</a>.</li> | |
| 49 | +<li><strong>Server still on 27015</strong> — you set <code>port</code> in <code>server.cfg</code> instead of passing <code>-port</code> at launch. The cvar is read too late.</li> | |
| 50 | +<li><strong>Server runs but nobody can join</strong> — the new UDP port is not open in the firewall or not forwarded on the router.</li> | |
| 51 | +<li><strong>Not in the master list after the move</strong> — confirm <code>sv_lan 0</code> and that the new port is reachable from outside; see <a href="/tutorials/fix-server-not-in-master-list">server not in master list</a>.</li> | |
| 52 | +<li><strong>Two servers randomly conflict</strong> — both bound all interfaces on overlapping ports. Give each a distinct <code>-port</code> and, on multi-IP boxes, a distinct <code>-ip</code>.</li> | |
| 53 | +</ul> | |
| 54 | + | |
| 55 | +<h2>Verification</h2> | |
| 56 | +<p>Start the server, then from the host confirm it is listening on the port you chose:</p> | |
| 57 | +<pre>ss -lunp | grep 27016</pre> | |
| 58 | +<p>You should see the <code>hlds</code> process bound to <code>*:27016</code> (or your specific IP). Then connect from a client with <code>connect ip:27016</code> and run <code>status</code> — the <code>udp/ip</code> line should show your new port. Once external players can join and the server appears in the browser, the move is complete.</p> |
fix-allocblock-full/en.md
A
| @@ -0,0 +1,10 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'AllocBlock: Full' (Too Many Lightmaps)" | |
| 3 | +excerpt: "Why the GoldSrc engine throws AllocBlock: Full when a map has too many unique lightmaps, and how to fix it with texture scaling, fewer lights, and the -chart report." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "limits, lighting" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>You compile a map, it runs fine in the editor, but the moment a client loads it the engine drops to the console with:</p><pre>AllocBlock: Full</pre><p>This is not a compile error — <code>hlrad</code> finished happily. It is a <strong>runtime</strong> failure inside the GoldSrc engine. The renderer allocates lightmap surfaces into a fixed set of blocks, and your map has produced more unique lightmap data than those blocks can hold. The map is over the lightmap budget, and the fix is to reduce how many distinct lightmaps the compile generates — not to add more.</p><h2>1. Understand what a lightmap costs</h2><p>Every world face that receives light gets its own lightmap, and the lightmap resolution is driven by the face's <strong>texture scale</strong> and by <code>-texdata</code>/light detail. A large face at a small texture scale (say <code>0.25</code>) generates a huge, high-resolution lightmap; the same face at scale <code>1.0</code> or higher generates a much smaller one. Thousands of faces each carrying an oversized lightmap is exactly what exhausts AllocBlock. The engine has a hard ceiling on the total; you cannot raise it, so you must lower your usage.</p><h2>2. Run a compile with -chart to see the budget</h2><p>Add <code>-chart</code> to your <code>hlrad</code> (and <code>hlbsp</code>) parameters and read the report at the end of the compile:</p><pre>hlrad -chart mymap.bsp</pre><p>The chart lists engine limits and how close you are to each. Watch the lightmap / <code>texdata</code> lines and the face count. If they are near the limit, AllocBlock is your next crash. See <a href="/tutorials/zhlt-vhlt-compile-parameters">the compile parameters guide</a> for the full flag list.</p><h2>3. Raise the texture scale on big, unimportant faces</h2><p>This is the single most effective fix. Select the large faces that do not need fine lighting detail — ceilings, floors under crates, big outer walls — open the Face/Texture Application tool, and increase their texture scale:</p><pre>Texture scale X: 1.00 -> 2.00 | |
| 10 | +Texture scale Y: 1.00 -> 2.00</pre><p>Doubling the scale on a face roughly quarters its lightmap footprint. You lose lighting resolution on that surface (softer shadows), which is invisible on a 512-unit ceiling but very visible on a detailed wall — so only scale up the faces where nobody will notice.</p><h2>4. Cut unnecessary lights and lit surface area</h2><p>Fewer light sources touching fewer faces means fewer lightmaps. Delete decorative <code>light</code> entities that overlap, and cap the reach of the rest. Faces textured with tool textures that are not rendered — <code>NULL</code>, <code>SKY</code>, <code>AAATRIGGER</code>, <code>CLIP</code> — do not generate lightmaps at all, so apply <code>NULL</code> to every face the player can never see (backs of walls, tops of skyboxes, hidden brush sides). This is the same discipline that keeps <a href="/tutorials/goldsrc-map-optimization-checklist">the whole map inside its limits</a>.</p><h2>5. Convert detail brushwork to func_detail</h2><p>Small, numerous brushes each add faces and lightmaps. Turning non-structural geometry into <code>func_detail</code> (a ZHLT/VHLT entity) keeps it lit but removes it from BSP tree splitting, which reduces face fragmentation and therefore lightmap count. Rails, trim, pipes, and clutter are ideal candidates.</p><h2>6. Recompile and re-read the chart</h2><p>After scaling and culling, run the full chain again — <code>hlcsg → hlbsp → hlvis → hlrad</code> — with <code>-chart</code> and confirm the lightmap figure dropped. If you are using Vluzacn's VHLT v34, the chart is more detailed and easier to read than old ZHLT.</p><h2>Common errors</h2><ul><li><strong><code>AllocBlock: Full</code> on load, compile was clean</strong> — the classic symptom. Too many/too-detailed lightmaps. Scale up big faces and NULL hidden ones.</li><li><strong>It only crashes for some players</strong> — it will crash for everyone once you are over the limit; those who "work" simply have not reached the offending view yet. Fix the budget, do not ignore it.</li><li><strong>Scaling textures made the map ugly</strong> — you scaled the wrong faces. Only raise scale where the surface is large and lighting detail is unimportant; leave detailed walls at <code>1.0</code>.</li><li><strong>Chart shows lightmaps fine but it still crashes</strong> — check that you recompiled with <em>all four</em> tools; a stale <code>hlrad</code> pass against an old BSP reports old numbers.</li><li><strong>Adding more lights to "balance" it</strong> — that makes AllocBlock worse, not better. The problem is total lightmap data, and more lights add data.</li></ul><h2>Verification</h2><p>Load the recompiled map on a listen server and walk the whole level, especially the open areas you scaled. If it no longer drops to <code>AllocBlock: Full</code>, you are under budget. Confirm with the final <code>-chart</code> output that the lightmap line sits comfortably below the ceiling — leave headroom, because adding one more detailed room later can push you back over. If lighting looks too flat after scaling, reintroduce detail selectively on the faces players actually study, and re-check the chart each time.</p> |
install-cs16-server-hetzner-vps/en.md
A
| @@ -0,0 +1,56 @@ | ||
| 1 | +--- | |
| 2 | +title: "Deploying a CS 1.6 Server on a Hetzner Cloud VPS" | |
| 3 | +excerpt: "Pick the right Hetzner Cloud plan for a 32-bit game server, provision Ubuntu, lock down the Cloud Firewall, and stand up HLDS as an unprivileged user." | |
| 4 | +category: "installation" | |
| 5 | +tags: "hetzner, vps" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Hetzner Cloud is one of the cheapest reliable homes for a CS 1.6 server, but there is one decision that will make or break the deployment before you type a single command: the CPU architecture. HLDS is a 32-bit x86 binary, and Hetzner sells both x86 and ARM instances under confusingly similar names. Get that right and the rest is a standard Linux install.</p> | |
| 10 | +<h2>1. Choose an x86 plan, not the ARM one</h2> | |
| 11 | +<p>In the Hetzner Cloud Console at <a href="https://console.hetzner.cloud">console.hetzner.cloud</a>, create a project and add a server. The plan families matter:</p> | |
| 12 | +<ul> | |
| 13 | +<li><strong>CX (Intel) and CPX (AMD)</strong> are x86-64 shared vCPU plans. HLDS runs natively on these.</li> | |
| 14 | +<li><strong>CAX (Ampere)</strong> is 64-bit <strong>ARM</strong>. HLDS will not run on it without <code>box86</code>/<code>box64</code> emulation, which is fragile and costs you CPU. Avoid CAX for a game server.</li> | |
| 15 | +</ul> | |
| 16 | +<p>The smallest CX or CPX plan comfortably runs a full 32-slot server; CS 1.6 is not demanding. Pick a location close to your players — ping is everything for a shooter — and see <a href="/tutorials/choose-vps-for-cs16">choosing a VPS for CS 1.6</a> if you are weighing providers.</p> | |
| 17 | +<h2>2. Provision Ubuntu 24.04 with an SSH key</h2> | |
| 18 | +<p>Select the <strong>Ubuntu 24.04</strong> image and attach your SSH public key during creation rather than using a root password — Hetzner emails a root password otherwise, and password auth on a public IP is a magnet for brute-force bots. Once the server boots, connect:</p> | |
| 19 | +<pre>ssh root@YOUR_SERVER_IP</pre> | |
| 20 | +<h2>3. Configure the Hetzner Cloud Firewall</h2> | |
| 21 | +<p>Hetzner offers a stateful Cloud Firewall that runs <em>outside</em> the VM, so it protects the box even before the OS firewall is configured. In the Console, create a firewall and attach it to the server. CS 1.6 needs one inbound rule that most people get wrong — the query and game traffic is <strong>UDP</strong>, not TCP:</p> | |
| 22 | +<pre>Inbound UDP 27015 (game + A2S queries) | |
| 23 | +Inbound TCP 22 (SSH, ideally from your IP only)</pre> | |
| 24 | +<p>If you add RCON over a separate port or run HLTV, open those too. The full port list and the reasoning behind UDP is in <a href="/tutorials/cs16-server-firewall-ports">CS 1.6 firewall ports</a>.</p> | |
| 25 | +<h2>4. Create an unprivileged user</h2> | |
| 26 | +<p>Never run the game server as root. Create a dedicated user now:</p> | |
| 27 | +<pre>adduser --disabled-password --gecos "" csserver | |
| 28 | +su - csserver</pre> | |
| 29 | +<p>Everything from here happens as <code>csserver</code>. The full rationale and a systemd unit that enforces it live in <a href="/tutorials/install-hlds-without-root">installing HLDS without root</a>.</p> | |
| 30 | +<h2>5. Install the 32-bit libraries</h2> | |
| 31 | +<p>A fresh 64-bit Ubuntu cannot load a 32-bit binary until you add the i386 architecture and its libraries. As root:</p> | |
| 32 | +<pre>dpkg --add-architecture i386 | |
| 33 | +apt update | |
| 34 | +apt install -y lib32gcc-s1 lib32stdc++6</pre> | |
| 35 | +<p>Skipping this produces the classic <code>No such file or directory</code> on an executable that clearly exists — the loader is missing, not the file. See <a href="/tutorials/install-32bit-libraries-cs16-linux">32-bit libraries for CS 1.6</a> and <a href="/tutorials/fix-hlds-no-such-file-32bit">the No such file fix</a>.</p> | |
| 36 | +<h2>6. Install SteamCMD and HLDS</h2> | |
| 37 | +<p>Back as <code>csserver</code>, install SteamCMD and pull the dedicated server. This follows the same steps as any Linux box — nothing about Hetzner changes them:</p> | |
| 38 | +<pre>mkdir -p ~/steamcmd ~/hlds | |
| 39 | +cd ~/steamcmd | |
| 40 | +curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" | tar zxf - | |
| 41 | +./steamcmd.sh +force_install_dir ~/hlds +login anonymous +app_update 90 validate +quit</pre> | |
| 42 | +<p>App 90 is the Half-Life dedicated server; it will download the CS files. The complete walkthrough, including selecting Counter-Strike as the mod, is in <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the SteamCMD dedicated server guide</a> and the Ubuntu-specific <a href="/tutorials/install-cs16-server-ubuntu-24-04">24.04 guide</a>.</p> | |
| 43 | +<h2>7. Launch and keep it running</h2> | |
| 44 | +<p>Start it once by hand to confirm it binds:</p> | |
| 45 | +<pre>cd ~/hlds | |
| 46 | +./hlds_run -game cstrike +map de_dust2 +maxplayers 24 -port 27015</pre> | |
| 47 | +<p>The <code>-game cstrike</code> and <code>-port</code> flags plus the rest are covered in <a href="/tutorials/hlds-command-line-parameters">HLDS command-line parameters</a>. Once it works, wrap it in a <a href="/tutorials/hlds-systemd-service">systemd service</a> so it survives reboots and crashes.</p> | |
| 48 | +<h2>Troubleshooting</h2> | |
| 49 | +<ul> | |
| 50 | +<li><strong>Server not visible in the browser</strong> — the Cloud Firewall rule is TCP instead of UDP, or <code>sv_lan</code> is <code>1</code>. Set <code>sv_lan 0</code> in <a href="/tutorials/setup-server-cfg-cs16">server.cfg</a> and confirm the UDP rule.</li> | |
| 51 | +<li><strong><code>hlds_run: No such file or directory</code></strong> — the 32-bit loader is missing. Complete step 5.</li> | |
| 52 | +<li><strong>Chose a CAX server and nothing runs</strong> — that is ARM. Destroy it and recreate on CX or CPX; do not fight box86.</li> | |
| 53 | +<li><strong>SSH works but the game port is dead</strong> — the Hetzner Cloud Firewall and the OS firewall are two layers. Check both; Ubuntu's <code>ufw</code> may also be blocking.</li> | |
| 54 | +</ul> | |
| 55 | +<h2>Verification</h2> | |
| 56 | +<p>From your own PC, open the console in CS 1.6 and run <code>connect YOUR_SERVER_IP:27015</code>. If you join, the network path is correct. Then query it externally — the server should appear in the internet tab within a minute of <code>sv_lan 0</code> and a live master-list connection. If it connects directly but never lists, revisit the firewall and <code>sv_lan</code> before touching anything else.</p> |
install-hltv-linux/en.md
A
| @@ -0,0 +1,56 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Set Up HLTV on Linux for CS 1.6" | |
| 3 | +excerpt: "Set up Valve's HLTV spectator proxy on Linux to relay and record whole matches, with the right delay, rate, and port settings." | |
| 4 | +category: "installation" | |
| 5 | +tags: "hltv, linux" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>HLTV is Valve's spectator proxy — the <code>hltv</code> binary that ships alongside the dedicated server tools. It connects to your game server as a special spectator client, buffers the match with a configurable delay, relays it to viewers on its own proxy port, and records the whole thing to a demo. On Linux it runs as a separate process from HLDS, so you set it up much like a second server. This guide covers a headless Linux install.</p> | |
| 10 | +<h2>1. Locate the hltv binary</h2> | |
| 11 | +<p>HLTV is bundled with the HLDS install you already have. If you followed the <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">SteamCMD dedicated-server guide</a>, the binary sits in the root of the install next to <code>hlds_run</code>:</p> | |
| 12 | +<pre>cd ~/hlds | |
| 13 | +ls -l hltv hltv_run</pre> | |
| 14 | +<p><code>hltv</code> is the engine binary; <code>hltv_run</code> is the wrapper that restarts it if it crashes, mirroring how <code>hlds_run</code> wraps <code>hlds_linux</code>. If they are missing, re-run the SteamCMD <code>app_update 90</code> — HLTV is part of app 90, not a separate download.</p> | |
| 15 | +<h2>2. Understand the two ports</h2> | |
| 16 | +<p>HLTV uses two endpoints. It <em>connects out</em> to your game server on its normal port (27015), and it <em>listens</em> on its own proxy port — default UDP <code>27020</code> — where spectators connect to watch. Those spectators never touch the game server directly; they only ever see the delayed HLTV feed. Keep 27020 open in your firewall if you want external viewers.</p> | |
| 17 | +<h2>3. Launch HLTV and reach its console</h2> | |
| 18 | +<p>Start it with the wrapper. Because it is interactive, run it inside <code>screen</code> or <code>tmux</code> so you can detach:</p> | |
| 19 | +<pre>screen -S hltv | |
| 20 | +./hltv_run</pre> | |
| 21 | +<p>You are dropped into the HLTV console, a stripped-down server console. Everything below is typed here. Detach the screen with <code>Ctrl-A</code> then <code>D</code> and it keeps running.</p> | |
| 22 | +<h2>4. Connect to your server</h2> | |
| 23 | +<p>From the HLTV console, name the proxy and connect to the running game server:</p> | |
| 24 | +<pre>name "CSB TV" | |
| 25 | +connect 127.0.0.1:27015</pre> | |
| 26 | +<p>If the game server is on the same box use <code>127.0.0.1</code>; otherwise use its LAN or public address. Once connected, HLTV occupies one spectator slot on the game server and begins relaying. Type <code>status</code> to confirm it is receiving.</p> | |
| 27 | +<h2>5. Set delay, rate and slots</h2> | |
| 28 | +<p>The three cvars that matter are the broadcast delay, the bandwidth cap, and the viewer limit:</p> | |
| 29 | +<pre>delay 30 | |
| 30 | +maxrate 10000 | |
| 31 | +maxclients 32</pre> | |
| 32 | +<p><code>delay</code> is the number of seconds HLTV holds the feed before showing it — 30 to 90 is normal, and it is what stops spectators ghosting live positions to players. <code>maxrate</code> caps per-viewer bandwidth. <code>maxclients</code> is how many spectators the proxy accepts.</p> | |
| 33 | +<h2>6. Persist settings in hltv.cfg</h2> | |
| 34 | +<p>HLTV executes <code>hltv.cfg</code> from the install root at startup, exactly like <code>server.cfg</code> for the game server:</p> | |
| 35 | +<pre>// hltv.cfg | |
| 36 | +name "CSB TV" | |
| 37 | +delay 30 | |
| 38 | +maxrate 10000 | |
| 39 | +maxclients 32 | |
| 40 | +serverport 27020 | |
| 41 | +rcon_password "changeme"</pre> | |
| 42 | +<p>Reload it live with <code>exec hltv.cfg</code>, then connect by hand as in step 4.</p> | |
| 43 | +<h2>7. Record a demo</h2> | |
| 44 | +<p>Because HLTV sees every player, its demo is the closest thing CS 1.6 has to a whole-match server recording:</p> | |
| 45 | +<pre>record match_2026_07_15 | |
| 46 | +stop</pre> | |
| 47 | +<p>The <code>.dem</code> lands in the HLTV directory and plays back in a normal client with <code>viewdemo</code>. To automate this per map, the <a href="/plugins/csb-hltv-autorecord">CSB HLTV Autorecord</a> plugin starts and names a recording at the start of every map so you never forget to hit <code>record</code>.</p> | |
| 48 | +<h2>Troubleshooting</h2> | |
| 49 | +<ul> | |
| 50 | +<li><strong>"Couldn't get info from server" / connect times out</strong> — the game server has <code>sv_lan 1</code>, a password, or is unreachable. HLTV connects like any client and obeys the same rules; set <code>sv_lan 0</code> or give HLTV the password with <code>password xxx</code> before <code>connect</code>.</li> | |
| 51 | +<li><strong>Server rejects HLTV: no free slots</strong> — HLTV needs a spectator slot on the game server. Raise <code>maxplayers</code> there, or set <code>sv_proxies 1</code> so the server allows a proxy to attach.</li> | |
| 52 | +<li><strong>Viewers cannot connect to 27020</strong> — the proxy port is firewalled. Open UDP 27020, and confirm <code>serverport</code> in <code>hltv.cfg</code> matches what you told viewers.</li> | |
| 53 | +<li><strong>Spectators can call live positions</strong> — <code>delay</code> is 0 or too low. Raise it to 30 or more so the feed lags real time.</li> | |
| 54 | +</ul> | |
| 55 | +<h2>Verification</h2> | |
| 56 | +<p>With HLTV connected, run <code>status</code> in its console and confirm it lists the game server and a growing set of players. From a client, open the console and <code>connect <hltv-ip>:27020</code> — you should join as a spectator and see play lagged by your <code>delay</code>. Record a short demo, <code>stop</code>, and confirm the <code>.dem</code> exists in the HLTV folder and opens with <code>viewdemo</code>. Once that round-trip works, detach the <code>screen</code> and HLTV keeps relaying and recording unattended.</p> |
migrate-cs16-server-to-new-vps/en.md
A
| @@ -0,0 +1,17 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Migrate an Old CS 1.6 Server to a New VPS" | |
| 3 | +excerpt: "A step-by-step migration that keeps your configs, bans, stats and maps intact, installs a clean engine on the new box, and cuts over with only a single map change of downtime." | |
| 4 | +category: "installation" | |
| 5 | +tags: "migration, vps" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Moving a CS 1.6 server to a new VPS is routine, but every trap is in the detail: a ban file you forgot, a <code>csstats.dat</code> wiped on arrival, an IP that changes and empties your player list. The reliable approach is to install a clean engine on the new box and copy only your <em>state</em> across — not the old binaries. This walks it end to end with <code>rsync</code>, keeping downtime to a single reconnect.</p><h2>1. Inventory what actually has to move</h2><p>The whole server lives under the game install, but only a few paths hold state you cannot regenerate:</p><pre>cstrike/ // your mod folder | |
| 10 | +cstrike/*.cfg // server.cfg, listip.cfg, banned_user.cfg | |
| 11 | +cstrike/maps/ // custom maps and .res files | |
| 12 | +cstrike/addons/ // metamod, amxmodx, plugins | |
| 13 | +cstrike/addons/amxmodx/data/ // csstats.dat, vault.ini, sqlite dbs</pre><p>The engine itself — <code>hlds_run</code>, the <code>.so</code> libraries, the Steam runtime — you re-install fresh on the new box. Do <strong>not</strong> drag those across from an old distribution or you inherit its glibc quirks and library paths.</p><h2>2. Install a clean base on the new VPS</h2><p>Provision the target and install HLDS from scratch with SteamCMD, exactly as in <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the Linux install guide</a>. Get a stock server running <code>de_dust2</code> and joinable <em>before</em> you copy a single custom file. Migrating onto a base that already works isolates any later problem to your own content.</p><h2>3. Back up the old server first</h2><p>On the old box, quiet the server (announce it, or drop it to an empty map) and archive the mod folder. The full procedure, including which files matter, is in <a href="/tutorials/backup-configs-bans-stats">backing up configs, bans and stats</a> and the broader <a href="/tutorials/backup-restore-cs16-server">backup and restore guide</a>. A tarball gives you a rollback if the cutover goes wrong:</p><pre>cd ~/hlds | |
| 14 | +tar czf cs16-backup.tar.gz cstrike/</pre><h2>4. Sync the state across with rsync</h2><p>Copy directly between hosts rather than downloading and re-uploading. From the old server, push the directories that hold state:</p><pre>rsync -avz --progress \ | |
| 15 | + cstrike/addons cstrike/maps cstrike/*.cfg \ | |
| 16 | + user@NEW_VPS_IP:~/hlds/cstrike/</pre><p>The <code>-a</code> flag preserves timestamps and permissions; <code>-z</code> compresses over the wire. Run it again just before cutover to catch bans and stats that changed while you were setting up — rsync only transfers the differences the second time.</p><h2>5. Fix ownership and make the data writable</h2><p>Files land owned by the transfer user, which is rarely the account that runs HLDS. Correct it or the server cannot write stats or save bans:</p><pre>chown -R hlds:hlds ~/hlds/cstrike | |
| 17 | +chmod -R u+rw ~/hlds/cstrike/addons/amxmodx/data</pre><p>A read-only <code>data/</code> directory is the classic cause of "ranks reset on every restart" after a move — the engine simply cannot persist <code>csstats.dat</code>.</p><h2>6. Update the IP and open the ports</h2><p>The new VPS has a new public IP. Update <code>server.cfg</code>, any <code>sv_downloadurl</code> mirror, and anything that hard-codes the old address, then open <strong>UDP 27015</strong> (and TCP if you run RCON or HLTV) on the new firewall as in <a href="/tutorials/cs16-server-firewall-ports">the firewall ports guide</a>. If you advertised the old IP to players, follow <a href="/tutorials/change-server-ip-keep-players">changing the IP while keeping players</a> so they are redirected rather than lost.</p><h2>7. Cut over</h2><p>Start the new server, confirm it is healthy and shows in the master list, then stop the old one. Point your DNS or community listing at the new address last, once you have verified the new box is serving. Leave the old VPS untouched for a few days as a hot rollback.</p><h2>Common errors</h2><ul><li><strong>Ranks are all zero after the move</strong> — <code>csstats.dat</code> was not copied, or <code>addons/amxmodx/data/</code> is not writable by the HLDS user. Re-sync it and fix permissions.</li><li><strong>Server starts but no plugins load</strong> — you copied <code>cstrike/addons</code> but the new engine has a different Metamod path, or <code>metamod.dll</code>/<code>.so</code> line in <code>liblist.gam</code> was not migrated. Re-check the Metamod install on the new box.</li><li><strong>"Bad load" on every plugin</strong> — the modules were compiled for a different architecture. Reinstall AMX Mod X natively rather than copying binaries between mismatched distros.</li><li><strong>Bans came back or vanished</strong> — you copied <code>banned_user.cfg</code> but not <code>listip.cfg</code>, or vice versa. Engine SteamID and IP bans live in separate files.</li><li><strong>Players cannot connect at all</strong> — the new firewall or provider security group blocks UDP 27015. Verify with the firewall guide.</li></ul><h2>Verification</h2><p>From a client, connect to the new IP and play a round. Type <code>say /rank</code> (if you run stats) and confirm your old numbers survived. Check a banned test SteamID still cannot join. Restart the new server and confirm plugins load and stats persist — if a rank resets, the data directory is not writable. Only once the new box has passed a full map rotation should you decommission the old VPS.</p> |
vis-optimization-hint-brushes/en.md
A
| @@ -0,0 +1,13 @@ | ||
| 1 | +--- | |
| 2 | +title: "VIS Optimization with hint and skip Brushes" | |
| 3 | +excerpt: "How hlvis builds the PVS, why r_speeds spike in open maps, and how to place HINT/SKIP brushes to subdivide visleafs and cut what the engine has to draw." | |
| 4 | +category: "mapping" | |
| 5 | +tags: "vis, optimization" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>If your custom map runs fine in a corridor and chugs the moment two open areas can see each other, the problem is almost never your models — it is <strong>visibility</strong>. GoldSrc decides what to render using the <em>PVS</em> (potentially visible set) that <code>hlvis</code> computes at compile time, and a badly leafed map tells the engine that half the level is visible from the other half. Hint and skip brushes are the manual tool for fixing that. This is what they are and how to place them without making things worse.</p><h2>1. What hlvis actually computes</h2><p>The compile toolchain runs in order: <code>hlcsg</code> → <code>hlbsp</code> → <code>hlvis</code> → <code>hlrad</code>. <code>hlbsp</code> chops the world into convex <em>leafs</em>; <code>hlvis</code> then works out, for every leaf, which other leafs are potentially visible from it — the PVS. At runtime the engine only draws faces in the PVS of the leaf your eye is in. When you open the console with <code>developer 1</code> and type <code>r_speeds 1</code>, the <code>wpoly</code> counter is the number of world polygons being drawn this frame. Keep it under roughly 800–1000 <code>wpolys</code> on a busy scene; spikes into the thousands are what cause the stutter.</p><h2>2. Why leafs leak visibility</h2><p>A single large open room becomes a small number of big leafs, and every big leaf sees a lot. Two rooms joined by a doorway will often share one leaf that straddles the opening, so standing in room A the engine thinks all of room B is visible and draws it. That is the exact situation a hint brush fixes: it forces <code>hlbsp</code> to cut a new leaf boundary exactly where you want the visibility to stop.</p><h2>3. HINT and SKIP: which face does what</h2><p>A hint brush is a normal brush textured with two special tool textures from <code>zhlt.wad</code>:</p><ul><li><strong>HINT</strong> — the one cutting face. It creates a leaf split along that plane but is <em>not</em> drawn in-game.</li><li><strong>SKIP</strong> — every other face of the brush. SKIP faces are removed entirely by the compiler; they generate no split and no geometry.</li></ul><p>So a hint brush is a thin box where only the single face you want to cut along wears the HINT texture and all five other faces wear SKIP. Get this backwards — SKIP on the cutting face, HINT everywhere — and you generate five useless splits and miss the one you wanted.</p><pre>// A hint brush spanning a doorway: | |
| 10 | +// the vertical face across the opening = HINT | |
| 11 | +// the other 5 faces = SKIP</pre><h2>4. Where to place them</h2><p>Place hints along <strong>natural sight blockers</strong> — doorways, the top of a wall, the mouth of a tunnel, the lip of a ledge. The classic placement is a thin hint brush filling a doorway from floor to ceiling: now a player in room A is in a leaf that cannot see past the door plane, and room B is culled until they actually step through. A horizontal hint at the height of a wall stops the engine drawing a whole skybox-facing area you can never see from ground level.</p><h2>5. Do not carpet the map with hints</h2><p>Every hint you add is more work for <code>hlvis</code> and more leafs to track at runtime; overdoing it slows compiles dramatically and can make <code>r_speeds</code> <em>worse</em> by fragmenting leafs into thousands of tiny pieces. Add hints surgically: find the spot where <code>r_speeds</code> spikes, look at what is being drawn that you should not be able to see, and place one hint on the plane that should block it. Recompile with VIS on full and re-measure. A dozen well-placed hints beat two hundred sprinkled hopefully.</p><h2>Common misconceptions</h2><ul><li><strong>"Hint brushes are solid walls."</strong> No — they are non-solid, invisible, and do not clip the player. They only influence leaf cutting.</li><li><strong>"More hints = faster."</strong> The opposite past a point. Each hint adds leafs and compile time; place them only where a measured spike justifies one.</li><li><strong>"I compiled and nothing changed."</strong> You almost certainly ran <code>hlvis</code> in fast mode or skipped it. Fast VIS produces a loose PVS; you must run <strong>full</strong> VIS for hints to pay off.</li><li><strong>"func_detail needs VIS too."</strong> Detail brushes are excluded from the VIS/BSP split on purpose — use them for railings and clutter so those do not chop leafs, and reserve hints for real sight blockers.</li><li><strong>"SKIP and NULL are the same."</strong> They are not: NULL removes a face to save wpolys on normal brushes; SKIP is specifically the filler texture for the non-cutting faces of a hint brush.</li></ul><h2>How to check on your map</h2><p>Load the map on a listen server, open the console and run:</p><pre>developer 1 | |
| 12 | +r_speeds 1 | |
| 13 | +gl_wireframe 2</pre><p>Walk to the spot that stutters and read the <code>wpolys</code> number; <code>gl_wireframe 2</code> draws only what is actually being rendered, so you can literally see the far room being drawn through a wall before you add a hint. Note the worst-case number, add one hint on the blocking plane, recompile with full VIS, and compare the same spot. If <code>wpolys</code> dropped and the far geometry vanished from the wireframe, the hint worked. Pair this with keeping standard textures external as covered in <a href="/tutorials/wadinclude-vs-external-wads">embedding WADs vs -wadinclude</a> so the BSP stays lean while you iterate on VIS.</p> | |
| 0 | 14 |
