Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent 1262470489
commit b87cffd83eb39d96458f0bbc057537bba7357800
2 changed files
with 69 additions and 0 deletions
cs16-on-linux-proton/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Playing CS 1.6 on Linux (Native and Proton)" | |
| 3 | +excerpt: "Two ways to run CS 1.6 on Linux: the native Steam client and the Windows build under Proton. How to switch, apply launch options, and fix the common launch failures." | |
| 4 | +category: "client" | |
| 5 | +tags: "linux, proton" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Counter-Strike 1.6 runs well on Linux, and you have two routes: the native Linux build that Steam ships, or the Windows build forced through Proton, Valve's compatibility layer. Each has trade-offs — native tends to have lower overhead, while Proton sometimes sidesteps quirks with certain drivers or mods. This shows how to run both, apply your settings, and get past the failures people hit on first launch.</p><h2>1. Try the native build first</h2><p>CS 1.6 has a native Linux client, and it is the default when you install the game on a Linux Steam client. Just install and launch — no compatibility layer involved. The native build integrates cleanly with the system OpenGL stack, so if your GPU drivers are set up correctly (Mesa for AMD/Intel, the proprietary or open NVIDIA driver), it should run immediately. Start here, because when it works it is the lightest option.</p><h2>2. Force Proton if native misbehaves</h2><p>If the native build crashes, has audio problems, or a mod expects Windows, force the Windows build through Proton. Right-click Counter-Strike > <strong>Properties</strong> > <strong>Compatibility</strong>, tick <strong>Force the use of a specific Steam Play compatibility tool</strong>, and select a Proton version (a recent stable Proton or Proton-GE). Steam then downloads and runs the Windows executable in a Proton prefix. This is the same mechanism used for any Windows-only game.</p><h2>3. Apply launch options the same way</h2><p>Launch options work identically on Linux, in <strong>Properties > Launch Options</strong>. The common performance and display flags all apply:</p><pre>-freq 144 -w 1920 -h 1080 -novid</pre><p>See the <a href="/tutorials/cs16-best-launch-options">launch options guide</a> for the full set. Under Proton you can prepend Proton-specific variables, for example forcing a gamescope or DXVK option, but plain OpenGL CS rarely needs them. If you use the native build, these options are passed straight to the Linux binary.</p><h2>4. Sort out drivers and 32-bit libraries</h2><p>CS 1.6 is a 32-bit game, so the native build needs 32-bit graphics libraries present. On a fresh Linux install the 64-bit driver may be there but the 32-bit OpenGL libraries missing, which causes an immediate launch failure or a black screen. Enable the 32-bit architecture and install the matching 32-bit driver package for your GPU (the i386/multilib Mesa or NVIDIA libraries). This is the same class of dependency problem servers hit; the server-side version is covered in <a href="/tutorials/install-32bit-libraries-cs16-linux">installing 32-bit libraries</a>, and the reasoning transfers to the client.</p><h2>5. Fix input and display quirks</h2><p>Two Linux-specific annoyances are common. First, mouse acceleration: the desktop environment may apply its own pointer acceleration on top of the game. Use raw input in the engine and disable the desktop's mouse acceleration for the session:</p><pre>m_rawinput 1</pre><p>Second, the game may launch on the wrong monitor or grab focus oddly under a compositor. Running true fullscreen and, on Proton, letting Steam manage the window usually resolves it; on native, disabling the compositor for the game window helps with stutter.</p><h2>Common errors</h2><ul><li><strong>Game will not start, no window appears</strong> — missing 32-bit OpenGL libraries. Enable multilib/i386 and install the 32-bit GPU driver package.</li><li><strong>Black screen then crash on the native build</strong> — driver or library mismatch. Force Proton as a fallback to confirm it is a native-library issue.</li><li><strong>No sound</strong> — the audio server (PipeWire/PulseAudio) routing; under Proton, try a different Proton version, on native check the default audio device.</li><li><strong>Mouse feels accelerated</strong> — the desktop is applying pointer acceleration. Enable <code>m_rawinput 1</code> and turn off DE acceleration.</li><li><strong>Launches on the wrong screen or won't go fullscreen</strong> — compositor interference. Run fullscreen and, on native, disable the compositor for the window.</li></ul><h2>Verification</h2><p>Launch the game and open the console to confirm the renderer came up cleanly, then check performance:</p><pre>net_graph 3</pre><p>You should see a stable high frame rate; if FPS is very low, the software renderer may have loaded instead of hardware OpenGL, which points back to the 32-bit driver libraries. Move the mouse and confirm input is 1:1 with no desktop acceleration. If native gives you trouble you cannot resolve, the Proton route is a reliable fallback — switching between them is a two-click change in the Compatibility tab, so it costs nothing to test both and keep whichever runs better on your hardware. As a rule of thumb: prefer native for the lowest overhead and simplest input path, and reach for Proton only when a specific mod, anti-cheat, or driver quirk makes the native build misbehave. Whichever you land on, the in-game tuning is identical to Windows, so your existing <a href="/tutorials/cs16-best-client-rates">rates</a> and config carry straight over.</p> |
debug-server-crash-no-error/en.md
A
| @@ -0,0 +1,60 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Debug a CS 1.6 Server That Crashes with No Error" | |
| 3 | +excerpt: "A methodical process for a HLDS/ReHLDS server that dies silently: enabling the debug log, reading a core dump, and bisecting Metamod and AMXX plugins." | |
| 4 | +category: "errors" | |
| 5 | +tags: "crash, debugging" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A server that crashes and simply disappears — no console error, no log line, the process gone — is the hardest kind to fix because there is nothing to paste into a search box. The trick is to stop guessing and generate real evidence: turn on the engine's debug crash log, then narrow the cause by bisecting your add-ons. This is the process that actually finds it.</p> | |
| 10 | + | |
| 11 | +<h2>1. Capture a backtrace with -debug (Linux)</h2> | |
| 12 | +<p>The Linux dedicated server launcher, <code>hlds_run</code>, has a built-in crash handler. Start it with <code>-debug</code> and, when the game binary crashes, it writes a gdb backtrace to <code>debug.log</code> in the server directory:</p> | |
| 13 | +<pre>./hlds_run -debug -game cstrike +map de_dust2 +maxplayers 20</pre> | |
| 14 | +<p>After a crash, open <code>debug.log</code>. The bottom of the file holds the crash time, the signal (usually <code>SIGSEGV</code>, a segmentation fault), and a stack trace. Even if the symbols are partial, the trace usually names the module at fault — the engine itself, <code>metamod</code>, or an AMXX module — which points you at the right area immediately.</p> | |
| 15 | + | |
| 16 | +<h2>2. Enable core dumps for a deeper look</h2> | |
| 17 | +<p>If <code>debug.log</code> is not enough, allow the OS to write a core file before launching:</p> | |
| 18 | +<pre>ulimit -c unlimited | |
| 19 | +./hlds_run -debug -game cstrike +map de_dust2</pre> | |
| 20 | +<p>A <code>core</code> file appears after the crash. Load it in gdb against the game binary to read the full stack:</p> | |
| 21 | +<pre>gdb ./hlds_linux core | |
| 22 | +(gdb) bt full</pre> | |
| 23 | +<p>You do not need to be a C++ programmer — you are looking for the first recognisable name in the trace (a module <code>.so</code>, a plugin) to know where to point the bisection.</p> | |
| 24 | + | |
| 25 | +<h2>3. Read the AMXX and Metamod logs</h2> | |
| 26 | +<p>Before bisecting, check the logs that <em>do</em> get written. AMXX logs run-time errors per map under <code>addons/amxmodx/logs/</code>, and Metamod issues show in the main server log. A plugin throwing a <code>Run time error</code> just before the crash is your prime suspect. Confirm what actually loaded:</p> | |
| 27 | +<pre>meta list | |
| 28 | +amxx plugins</pre> | |
| 29 | +<p>Anything marked <code>bad load</code> or a module that failed is a lead. See <a href="/tutorials/plugins-ini-load-order">plugins.ini load order</a> for reading that output.</p> | |
| 30 | + | |
| 31 | +<h2>4. Bisect the plugins</h2> | |
| 32 | +<p>Silent crashes are very often a single misbehaving AMXX plugin or Metamod module. Narrow it by halving:</p> | |
| 33 | +<ol> | |
| 34 | +<li>Comment out the bottom half of <code>plugins.ini</code> (prefix lines with <code>;</code>), change map, and see if it still crashes.</li> | |
| 35 | +<li>If it stops, the culprit was in the disabled half — re-enable half of that, repeat.</li> | |
| 36 | +<li>If it still crashes, the fault is in the enabled half (or in Metamod / a module, not a plugin). Move to disabling Metamod modules in <code>metamod</code>'s <code>plugins.ini</code>.</li> | |
| 37 | +</ol> | |
| 38 | +<p>A handful of map changes isolates one line. Run that suspect plugin in debug mode to get a precise trace:</p> | |
| 39 | +<pre>myplugin.amxx debug</pre> | |
| 40 | + | |
| 41 | +<h2>5. Rule out the obvious triggers</h2> | |
| 42 | +<p>If the crash correlates with an event, the cause is narrower than a random fault:</p> | |
| 43 | +<ul> | |
| 44 | +<li><strong>Crashes on a specific map</strong> — a corrupt or oversized <code>.bsp</code>, or a plugin that trips on that map's entities. Test the map alone.</li> | |
| 45 | +<li><strong>Crashes on map change only</strong> — a plugin's map-end handler, or a bad <a href="/tutorials/mapcycle-txt-setup">mapcycle</a> entry pointing at a missing map.</li> | |
| 46 | +<li><strong>Crashes under player load</strong> — a memory or rate issue; watch it fill up and note the count at which it dies.</li> | |
| 47 | +<li><strong>Crashes at a fixed time</strong> — a cron-like task or a scheduled plugin action.</li> | |
| 48 | +</ul> | |
| 49 | + | |
| 50 | +<h2>Troubleshooting</h2> | |
| 51 | +<ul> | |
| 52 | +<li><strong>No <code>debug.log</code> appears</strong> — you launched the binary directly instead of through <code>hlds_run -debug</code>. The crash handler lives in the launcher script.</li> | |
| 53 | +<li><strong>No <code>core</code> file</strong> — <code>ulimit -c</code> is 0 in that shell, or the working directory is not writable. Set <code>ulimit -c unlimited</code> in the same session that launches the server.</li> | |
| 54 | +<li><strong>Backtrace is all <code>??</code></strong> — stripped binaries; you still get the module boundaries, which is enough to bisect. Focus on which <code>.so</code> appears.</li> | |
| 55 | +<li><strong>Disabling all plugins stops the crash</strong> — it is an add-on, not the engine. Bisect back in.</li> | |
| 56 | +<li><strong>Crash persists with everything disabled</strong> — engine, mod DLL, or OS. Consider moving to <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a>, which is more stable and better instrumented than legacy HLDS.</li> | |
| 57 | +</ul> | |
| 58 | + | |
| 59 | +<h2>Verification</h2> | |
| 60 | +<p>Once you suspect a specific plugin or module, remove only that one, restart, and run the server through the exact conditions that killed it before — the same map, the same player load, the same map change. If it survives a full cycle that previously crashed it reliably, you have your culprit. Re-enable everything else to confirm the rest is innocent, then either update or replace the offending add-on. Keep <code>-debug</code> on until you have gone a full day without a crash.</p> | |
| 0 | 61 |
