---
title: "Fix: 'Msg overflowed' / Buffer Overflow in Message"
excerpt: "What SZ_GetSpace and reliable-channel overflows mean, why too many entities or a chatty plugin trigger them, and how to cut the message volume that crashes clients."
category: "errors"
tags: "netchan, overflow"
image: ""
read_time: "8 min read"
---
<p>Players get disconnected with a buffer or message overflow, or the server console spits out <code>SZ_GetSpace</code> errors during heavy fights. GoldSrc packs game state and events into fixed-size network buffers each frame. When the engine tries to write more into a buffer than it holds — too many entities in view, too many simultaneous messages, a plugin flooding HUD or chat — it overflows, and depending on which buffer, either a client drops or the server errors. The cure is to reduce what is being crammed into the buffer.</p><h2>1. Identify which overflow you have</h2><p>The two you will actually see are:</p><pre>SZ_GetSpace: overflow on netchan->message</pre><p>and</p><pre>Reliable channel overflowed for <player></pre><p>The reliable-channel overflow is per client: one player is being sent more reliable data than their channel can carry, and the engine drops them to protect the connection. The generic <code>SZ_GetSpace</code> overflow is the buffer running out of space while the engine or a plugin writes to it. Both come down to volume — the difference is whether it is one player's channel or a shared buffer.</p><h2>2. Suspect entity and effect density first</h2><p>The most common non-plugin cause is simply too much happening at once: a corner packed with players, grenades, smoke, decals, and temporary sprites. Each visible entity and effect costs bytes in the update. On a high-slot server a single choke point can push a client's update past the buffer. If overflows cluster around the busiest map areas and biggest fights, this is your cause — and it overlaps with the edict pressure covered in <a href="/tutorials/fix-max-edicts-too-many-entities">the MAX_EDICTS fix</a>.</p><h2>3. Find the chatty plugin</h2><p>A plugin that sends large or frequent messages is the other big cause. Watch for:</p><ul><li>HUD plugins redrawing a big status panel every frame instead of on change.</li><li>Advert or info plugins printing long colored messages to everyone at once.</li><li>Effect plugins firing many temporary-entity messages per kill or per shot.</li><li>Menu or scoreboard plugins rebuilding on every event.</li></ul><p>Disable suspects one at a time in <a href="/tutorials/plugins-ini-load-order">plugins.ini</a>, change map, and see whether the overflow stops. A plugin that blasts a per-frame HUD message to 32 players is a classic trigger.</p><h2>4. Reduce the volume</h2><p>Once you know the source, cut it down:</p><ul><li>Lower decal churn with a stricter <code>decalfrequency</code> so sprays and bullet marks do not pile bytes into every update.</li><li>Trim cosmetic effect plugins on high-population servers where the buffer headroom per client is smallest.</li><li>For a plugin you control or can configure, make HUD updates event-driven, not per-frame, and shorten message text.</li><li>Reduce slot count if you are running far more players than the map and plugin set can serialize per frame.</li></ul><p>Do not reach for exotic net cvars as a first move — the overflow is caused by content volume, and tuning rates around it just moves the crash. Cut the source.</p><h2>5. Distinguish a server crash from a client kick</h2><p>It matters who actually goes down. A <code>Reliable channel overflowed for <player></code> line usually drops only that one client — the server survives and everyone else plays on — because the engine protects the connection by disconnecting the overloaded channel. A generic <code>SZ_GetSpace</code> overflow on a shared buffer is worse: it can fault the whole server. If you are losing single players intermittently, hunt the per-client cause (a plugin targeting individuals, or one player sitting in the densest spot). If the entire server drops at once, look at a broadcast — a round-end effect, a bomb explosion, an advert fired to all — that wrote too much to a buffer shared by everyone. Reading which message immediately preceded the crash in the console narrows it fast.</p><h2>Troubleshooting</h2><ul><li><strong><code>Reliable channel overflowed for X</code> repeatedly</strong> — that specific client is being sent too much reliable data; a plugin is spamming them, or they sit in the densest area. Find the plugin or reduce effects.</li><li><strong>Overflows only during big fights</strong> — entity/effect density, not a plugin. Cut decals and cosmetic effects.</li><li><strong>Everyone drops at the same moment</strong> — a single broadcast message or effect fired to all players overflowed a shared buffer. Look at what event just happened (round end, a bomb effect, an advert).</li><li><strong>Started after adding one plugin</strong> — that plugin is the source; it sends too much. Reconfigure or replace it.</li><li><strong>Only on 32-slot, fine on 16</strong> — per-frame buffer pressure scales with player count. Reduce slots or the plugin/effect load.</li></ul><h2>Verification</h2><p>After cutting the suspected source, recreate the worst case: fill the busiest map area with as many players as you can, throw grenades, spray decals, and trigger the events that used to overflow. A clean console with no <code>SZ_GetSpace</code> or reliable-channel errors through a full heavy round means the volume now fits the buffers. If you isolated a plugin, re-enable it alone to confirm the overflow returns with it and disappears without it — that closes the loop on the cause rather than leaving you guessing.</p>
