Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent e087e4c812
commit b8e13426ac0a647d409e9ca8761c0cd69d07d2fc
2 changed files
with 57 additions and 0 deletions
cs16-rawinput-mouse-accel/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "m_rawinput and Fixing Mouse Acceleration" | |
| 3 | +excerpt: "What m_rawinput does, how it bypasses Windows mouse acceleration, the legacy -noforce launch options, and how to confirm your aim is truly 1:1 with no smoothing." | |
| 4 | +category: "client" | |
| 5 | +tags: "mouse, rawinput" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Consistent aim depends on one thing above all: the same physical mouse movement must always produce the same in-game turn. Mouse acceleration breaks that — move faster and you turn further than the distance alone would suggest, so you can never build reliable muscle memory. CS 1.6 gives you <code>m_rawinput</code> to bypass acceleration entirely, plus a set of legacy launch options for the same purpose. This explains what each does and how they interact.</p><h2>1. What acceleration actually is</h2><p>Mouse acceleration means the cursor's on-screen movement depends on how <em>fast</em> you move the mouse, not just how far. Windows applies this through the "Enhance pointer precision" option, and older games applied their own on top. For desktop use it feels natural; for aiming it is poison, because the same 5 cm swipe turns a different amount depending on speed. The goal is a flat 1:1 relationship: distance in, distance out, every time.</p><h2>2. Enable raw input</h2><p>The cleanest fix is raw input, which reads the mouse hardware directly and ignores the entire Windows pointer pipeline including acceleration:</p><pre>m_rawinput 1</pre><p>With this on, "Enhance pointer precision" and the Windows pointer speed slider no longer affect the game at all — the engine takes the raw counts from the sensor. This is the single most important aim setting, and on modern systems it is the recommended approach over the legacy options below. Save it to your <a href="/tutorials/cs16-config-cfg-guide">config.cfg</a>.</p><h2>3. The legacy -noforce launch options</h2><p>Before raw input, players forced the engine to stop applying its own acceleration and to stop overriding Windows mouse parameters, using three launch options:</p><pre>-noforcemparms -noforcemaccel -noforcemspd</pre><ul><li><code>-noforcemparms</code> — do not force custom mouse parameters; use the Windows ones as-is.</li><li><code>-noforcemaccel</code> — do not force mouse acceleration.</li><li><code>-noforcemspd</code> — do not force mouse speed.</li></ul><p>Add them in <strong>Steam > Properties > Launch Options</strong>. With raw input on these are largely redundant, but they do no harm and are a sensible belt-and-braces measure. See the <a href="/tutorials/cs16-best-launch-options">launch options guide</a> for how they sit alongside your other flags.</p><h2>4. Turn off acceleration in Windows too</h2><p>Even with raw input protecting the game, disable Windows acceleration globally so every application and the desktop behave predictably. Open <strong>Settings > Bluetooth & devices > Mouse > Additional mouse settings > Pointer Options</strong> and uncheck <strong>Enhance pointer precision</strong>. Set the pointer speed slider to the exact middle (the 6th of 11 notches), which is the only 1:1 position — any other notch scales your counts up or down.</p><h2>5. Set sensitivity on a clean base</h2><p>Once the input path is flat, sensitivity is a pure multiplier you can trust. Set it in the console:</p><pre>sensitivity 2.0</pre><p>Do not use the in-engine <code>m_customaccel</code> acceleration natives — they reintroduce exactly what you just removed. Leave any custom acceleration off:</p><pre>m_customaccel 0</pre><p>With acceleration gone, your sensitivity and DPI together define a fixed cm/360 (centimeters of mouse movement for a full turn), and that number stays constant, which is the whole point.</p><h2>Common errors</h2><ul><li><strong>Aim still feels floaty with raw input on</strong> — the mouse's own driver software is applying acceleration or angle snapping. Turn those off in the vendor software.</li><li><strong>Sensitivity changed after enabling raw input</strong> — expected. Raw input removes Windows scaling, so your effective sensitivity shifts; re-tune it once and it stays put.</li><li><strong><code>m_rawinput</code> does nothing</strong> — it did not save. Add it to <code>config.cfg</code>; a console-only change reverts next launch.</li><li><strong>Cursor speed differs between desktop and game</strong> — that is normal and fine. Raw input deliberately decouples them; only the in-game feel matters.</li><li><strong>Turns are inconsistent at the same sensitivity</strong> — <code>m_customaccel</code> is on, or Windows Enhance pointer precision is still checked. Disable both.</li></ul><h2>Verification</h2><p>The definitive test is a repeatable swipe. Put a small mark on your mousepad, aim at a fixed point on a wall in-game, and swipe the mouse from the mark to the same end point at two very different speeds — slow and fast. With acceleration gone, both swipes must land the crosshair on the <em>same</em> spot. If the fast swipe overshoots, acceleration is still active somewhere: recheck <code>m_rawinput 1</code>, Enhance pointer precision, and your mouse software. Once slow and fast land identically, your aim is 1:1 and every hour of practice now compounds instead of fighting a moving target. It is worth doing this test again after any Windows update or mouse-driver reinstall, since those occasionally re-enable Enhance pointer precision behind your back. Pair this with the wider <a href="/tutorials/cs16-mouse-input-lag">input lag fixes</a> so the clean input path is not undone by a frame cap or v-sync sitting on top of it.</p> |
fix-a2s-info-no-response/en.md
A
| @@ -0,0 +1,48 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Server Doesn't Respond to A2S_INFO Queries" | |
| 3 | +excerpt: "Why a running CS 1.6 server returns no answer to A2S_INFO — firewall, binding, port and query-challenge causes — and how to confirm each one." | |
| 4 | +category: "errors" | |
| 5 | +tags: "a2s, query" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Your server is up, players who know the IP can join, but it shows no data in the browser, monitoring sites report it offline, and query tools time out. That is an A2S_INFO problem: the server is not answering the UDP query that clients and the master list use to read its name, map, and player count. The process is running fine; the query path is broken. Here is how to find where.</p> | |
| 10 | + | |
| 11 | +<h2>1. Know what A2S_INFO is</h2> | |
| 12 | +<p>A2S_INFO is a small UDP request sent to the server's game port (default <strong>27015</strong>). The server replies with its hostname, current map, player count, and max players — the data every browser row and monitoring service displays. It travels on the <em>same UDP port</em> as gameplay, so if players can connect but queries fail, the issue is specific to how the query is handled or filtered, not basic reachability.</p> | |
| 13 | + | |
| 14 | +<h2>2. Check the firewall first (the usual cause)</h2> | |
| 15 | +<p>The port must accept inbound UDP from anywhere, not just from IPs that have already connected. A firewall that allows established gameplay traffic but drops fresh query packets produces exactly this symptom. Confirm UDP 27015 (or your port) is open inbound:</p> | |
| 16 | +<pre># Linux, ufw | |
| 17 | +sudo ufw allow 27015/udp | |
| 18 | + | |
| 19 | +# Linux, iptables | |
| 20 | +sudo iptables -A INPUT -p udp --dport 27015 -j ACCEPT</pre> | |
| 21 | +<p>On a hosted VPS, also open the port in the provider's external firewall / security group — that is a separate layer from the OS firewall and is frequently the one still closed. See <a href="/tutorials/cs16-server-firewall-ports">which ports a CS 1.6 server needs open</a>.</p> | |
| 22 | + | |
| 23 | +<h2>3. Confirm the bind address and port</h2> | |
| 24 | +<p>If the server bound to the wrong interface or a non-default port, queries to the expected address go nowhere. Check what it is actually listening on:</p> | |
| 25 | +<pre>ss -lunp | grep hlds | |
| 26 | +# or | |
| 27 | +netstat -lunp | grep 27015</pre> | |
| 28 | +<p>You want it listening on the port you are querying, on <code>0.0.0.0</code> or the correct public interface. If you set <code>-ip</code> or a <code>+port</code> that differs from what monitors query, fix the mismatch. Note that <code>sv_lan</code> does not block queries by itself — but with <code>sv_lan 1</code> the server never heartbeats the master list, so it stays out of the internet browser regardless of query health. Set <code>sv_lan 0</code> for a public server.</p> | |
| 29 | + | |
| 30 | +<h2>4. The A2S query-challenge change</h2> | |
| 31 | +<p>To curb reflection/amplification attacks, GoldSrc servers were updated so that A2S_INFO queries must complete a challenge handshake — the server replies with a challenge number that the querier must echo back. Old query tools that send a bare A2S_INFO with no challenge get <strong>no reply</strong>, which looks exactly like the server being down. <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> implements this correctly and current monitoring services follow the challenge. If only an old homemade script fails while real browsers and monitors work, the script is the problem, not the server — update it to send the challenge.</p> | |
| 32 | + | |
| 33 | +<h2>5. Test the query directly</h2> | |
| 34 | +<p>Query from an <em>external</em> host (not the server itself — localhost can succeed while the public path is blocked). Any A2S tool works; the point is to test from outside your network. If an external query returns the server info, the query path is healthy and the original "offline" report was a stale monitor or a challenge-unaware tool. If it times out from outside but works locally, the firewall or provider security group is dropping the packet.</p> | |
| 35 | + | |
| 36 | +<h2>Troubleshooting</h2> | |
| 37 | +<ul> | |
| 38 | +<li><strong>Players can join but the browser shows no info</strong> — query packets are filtered while gameplay is allowed, or the query tool is challenge-unaware. Open UDP inbound broadly and test with a current tool.</li> | |
| 39 | +<li><strong>Works from the server, times out externally</strong> — provider firewall / security group, or an OS firewall rule scoped too narrowly. Open the port from all sources.</li> | |
| 40 | +<li><strong>Never appears in the internet list at all</strong> — <code>sv_lan 1</code>, so no heartbeat. Set <code>sv_lan 0</code>; see <a href="/tutorials/fix-server-not-in-master-list">server not in the master list</a>.</li> | |
| 41 | +<li><strong>Only one old monitoring script fails</strong> — it does not implement the A2S challenge. The server is fine; update the script.</li> | |
| 42 | +<li><strong>Wrong port everywhere</strong> — the server bound to a non-default port. Match your monitors to the real port from <code>ss -lunp</code>.</li> | |
| 43 | +</ul> | |
| 44 | + | |
| 45 | +<h2>Verification</h2> | |
| 46 | +<p>Confirm the listening socket on the box:</p> | |
| 47 | +<pre>ss -lunp | grep 27015</pre> | |
| 48 | +<p>Then run an A2S query from an outside host and confirm it returns the hostname, map, and player count. Finally, check the server row in the in-game internet browser (with <code>sv_lan 0</code>) populates with live data. When an external query answers correctly, the A2S path is healthy end to end. If clients also cannot even connect, that is a broader reachability problem, not a query-only one.</p> | |
| 0 | 49 |
