Most performance problems degrade gradually - a server gets a little choppier as load rises, and there’s time to react. A specific category of Garry’s Mod problem doesn’t work that way: a small set of hard, inherited-from-Source ceilings that don’t warn you as you approach them and fail outright, not gracefully, the moment you cross them. These matter most for prop-heavy Sandbox derivatives, DarkRP-style servers with large persistent prop counts, and any addon that spawns entities in bulk.
The entity/edict ceiling
Source’s engine supports up to 8,192 networked entities, but the practical networked-edict ceiling is a range, not a fixed number - Facepunch’s own wiki documents ents.Create starting to fail somewhere between 8,064 and 8,176, depending on what else is holding a reserved slot at that moment. This is not a soft warning threshold - ents.Create() returns NULL once you’re near it, and a real production crash log (tracked in a Facepunch GitHub issue) shows the exact failure message: "Not creating entity 'XYZ' - too many edicts! (8064 current, 8192 max)". That specific incident happened on a map with roughly 4,000 entities where game.CleanUpMap spawned new map entities before old ones had finished being removed - a timing issue, not a raw prop-count issue, which is part of why this ceiling catches server owners by surprise.
The critical detail for sizing and audit purposes: this budget is shared server-wide across every entity on the server - props, players, weapons, world brushes, and every custom Scripted Entity your addons spawn. A burst-spawning tool (a portal effect that spawns several decorative props at once, for example) should check remaining headroom and fail gracefully rather than spam failed ents.Create calls into an already-tight budget. One mitigation worth investigating for purely visual, non-interactive entities: ents.CreateClientProp/ClientsideModel creates non-networked, client-only fake props that don’t consume the 8,192 networked-edict budget at all.
Model precache: 8,192, and it’s a crash, not a warning
Separately from the entity ceiling, the engine supports precaching at most 8,192 unique models. Exceeding it crashes the game outright - again, not a graceful error a server operator can catch and work around at runtime. For servers running a large, accumulated addon library where each addon brings its own models, this is worth an explicit audit rather than an assumption that “it’ll just get slower.”
Networking budgets are separate from the entity ceiling - and easy to conflate
Garry’s Mod has three distinct entity-state networking systems, and each has its own budget:
- Legacy NWVars (
SetNWString/SetNWInt/etc.) are backed by a global stringtable of exactly 4,095 slots, shared server-wide across every entity. Each unique key name permanently consumes a slot for the life of the server - the mistake that exhausts this budget fastest is dynamically generating NWVar key names (for example, a per-entity-ID key), which burns through the shared table rather than staying within any single entity’s own allowance. - Modern DataTable/NetworkVar declarations (
self:NetworkVar(...)inSetupDataTables) are the wiki’s recommended default for entity state and auto-handle networking, saving, and prediction - but they carry a hard per-entity ceiling of 32 slots per type (bool/int/float/vector/angle/entity) and only 4 string slots (511/512 bytes each). A state-heavy custom entity - a complex vehicle or machine - can exhaust this faster than expected; packing booleans into a bitmask integer is the standard workaround before falling back to manualnetmessages. - The net library itself is manual, bidirectional, capped at 64KB per message, and has no automatic prediction or replication - appropriate for state that changes rarely or needs a large payload, not as a default channel for routine entity-owned state.
Conflating these three is a common source of confusing bugs: a NetworkVar-slot exhaustion error and an NWVar stringtable exhaustion error look similar in symptom (a value silently fails to network) but require entirely different fixes.
What this means for sizing and audits
- Before scaling a prop-heavy or DarkRP-style server up in player count, check total entity count against the shared ceiling - budget for failures starting as low as ~8,064, not the nominal 8,192, since headroom shrinks faster than intuition suggests once you include world entities and every player’s own props.
- Audit any addon that dynamically generates NWVar key names - this is the single most common way to exhaust the legacy stringtable without realizing it until the server has been running for a while.
- For bulk visual effects (particle-adjacent decorative props, portal-style linked-entity spawns), evaluate whether client-only fake props are a viable substitute before assuming every visual element needs a full networked entity.
- None of these ceilings are things “better hardware” fixes - they’re fixed engine constants, independent of CPU or RAM. This is worth knowing before a hardware upgrade is proposed as the answer to an entity-limit crash.
Related reading: Why Garry’s Mod Won’t Scale on Threads covers the hardware side of sizing decisions - tick rate and single-core bottlenecks - that these ceilings sit alongside.