--- 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" ---
Players get disconnected with a buffer or message overflow, or the server console spits out SZ_GetSpace 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.
The two you will actually see are:
SZ_GetSpace: overflow on netchan->message
and
Reliable channel overflowed for <player>
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 SZ_GetSpace 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.
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 the MAX_EDICTS fix.
A plugin that sends large or frequent messages is the other big cause. Watch for:
Disable suspects one at a time in plugins.ini, change map, and see whether the overflow stops. A plugin that blasts a per-frame HUD message to 32 players is a classic trigger.
Once you know the source, cut it down:
decalfrequency so sprays and bullet marks do not pile bytes into every update.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.
It matters who actually goes down. A Reliable channel overflowed for <player> 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 SZ_GetSpace 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.
Reliable channel overflowed for X repeatedly — 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.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 SZ_GetSpace 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.