--- 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.

1. Identify which overflow you have

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.

2. Suspect entity and effect density first

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.

3. Find the chatty plugin

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.

4. Reduce the volume

Once you know the source, cut it down:

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.

5. Distinguish a server crash from a client kick

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.

Troubleshooting

Verification

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.