ED_Alloc: no free edicts in GMod: the Edict Limit Explained

An edict is a slot in the list of networked entities, meaning all objects the server can transmit to the clients. Garry's Mod has 8192 of these slots. Once all of them are taken, the engine cannot create another networked entity, and if it needs one anyway, the server ends with ED_Alloc: no free edicts. The only remedy is to create fewer entities: as a mapper with static instead of dynamic objects, as a server owner with limits, cleanups and a map that brings little of its own.

What an edict is and what uses one

The engine keeps two lists. One holds entities with an edict. Through the edict, an entity has the same number on the server and on every client and can be transmitted. The other holds entities that exist only on the server or only on a client. A networked entity keeps its edict occupied from creation until removal, even if it never moves.

The table follows the stock Source code (Source SDK 2013) and the Valve Developer Community, because GMod's own engine code is not public. The logic entities in the right-hand column are not free. They count towards the second list, which according to the Valve Developer Community also holds 8192 entries in GMod. Why static props never exist as entities in the first place is explained in the article on prop_static, prop_dynamic and prop_physics.

Where the limit sits in GMod

In the Source Engine code, the constant MAX_EDICT_BITS defines how many bits are used to transmit an entity number. In Source SDK 2013 it is 11 bits, which gives 2048 edicts. Garry's Mod has raised the limit. There are three limits you must not confuse:

The first two values come from the Valve Developer Community, and the Garry's Mod wiki confirms the first. The third is VBSP's MAX_MAP_ENTITIES, which the March 2024 update of Garry's Mod raised to 65k for the compile tools only. In a test, the current VBSP aborted with num_entities == MAX_MAP_ENTITIES as soon as the map file held 65536 entries including the world, and every prop_static counted. VBSP's limits are the subject of Source Engine map limits.

In practice the end comes earlier. According to the GMod wiki, ents.Create already fails somewhere between 8064 and 8176 used edicts, depending on the number of player slots and on other entities. Close to the limit, GMod deliberately stops creating new entities. In Sandbox the player then sees the message "Failed to create an entity. Server likely hit the entity limit." Addons that do not expect an invalid entity start throwing Lua errors from that point on. The crash looms when no slot is left despite this safeguard.

Counting entities and edicts on the server

Enter these commands in the server console:

lua_run print(ents.GetEdictCount(), ents.GetCount())
report_entities
sv_lowedict_threshold
sv_lowedict_action

• ents.GetEdictCount() returns the number of networked entities, ents.GetCount() the number of all entities.
• report_entities lists all entities by class with their count and ends with a totals line that also names the edicts.
• sv_lowedict_threshold and sv_lowedict_action are engine variables. Entered without a value, they show the current setting.

Measure twice: once right after the map starts without players and once at peak time. The first number is the base cost of the map. The difference is what players and addons create.

What the map brings along and how you save as a mapper

Everything stored as an entity in the BSP that does not remove itself on start keeps its slot permanently. This is how you keep the base cost low:

1. Make props static. Every prop_dynamic and prop_physics costs an edict, a prop_static costs none.
2. Combine brushes. Several brushes in one func_brush are one entity. If they need no function, turn them into func_detail and they disappear from the entity list entirely at compile time.
3. Leave lights unnamed. In the stock Source code (Source SDK 2013), a light or light_spot without a name removes itself when the map starts, because its light is already in the lightmaps. With a name, it stays as an entity.
4. Check sprites. Every env_sprite is a networked entity. GMod's FGD contains env_sprite_clientside. According to the Valve Developer Community, it is removed on the server after the start as long as it has neither a name nor a parent.
5. Watch out for bone followers. A prop whose model has a jointed collision model creates an additional phys_bone_follower entity for each piece. The Disable Bone Followers property on the prop_dynamic prevents this but costs you the collision.

You can check the result in the Map Scanner. For a BSP it shows the number of entities and the most frequent entity classes. More levers are covered in optimizing GMod map performance.

What players and addons add at runtime

• Players: Every player is an entity, and every weapon in their inventory is another one.
• Spawned props: Sandbox creates every prop as a prop_physics. The default for sbox_maxprops is 200 per player. With 40 players that would be up to 8000 props and therefore almost the entire budget.
• Other Sandbox limits: By default, Sandbox also allows 10 ragdolls, 4 vehicles, 10 NPCs and 100 entities (sbox_maxsents) per player.
• Wiremod: Every hologram from Expression 2 is a networked entity. Wiremod caps the number per player with wire_holograms_max.
• Composite objects: In practice, vehicle addons and large contraptions often consist of many individual entities. The exact number depends on the addon.

When a player leaves the server, the stock Source code removes their weapons along with them. In Sandbox their props stay until someone cleans up.

What you can do as a server owner

1. Do the maths. Multiply your sbox_max values by the usual number of players and add the base cost of the map. If the result is above roughly 8000, lower the limits.
2. Clean up. As an admin, gmod_admin_cleanup removes everything players have spawned and resets the map. With gmod_cleanup, each player clears their own objects. Prop protection addons often offer to remove the props of disconnected players after a delay.
3. Get an early warning. According to the help text of the two variables, the engine runs sv_lowedict_action when only as many edicts are free as sv_lowedict_threshold specifies: 0 nothing, 1 warning to the log, 2 restart the game, 3 restart the map, 4 next map in the map cycle.
4. Choose a suitable map. On bspmarket.de, a map's Technical data lists the approximate values Entities (map) and Static props. In the categories you can filter by entity count. What else belongs to the choice is covered in choosing a DarkRP map.

You will also find explanations of this and related messages in the error database.

FAQ

Can I raise the edict limit?

No. The value is compiled into the engine and, according to the Valve Developer Community, cannot be changed without breaking compatibility with the engine. All you can do is lower the number of entities.

Does the limit apply in other Source games too?

In most of them it is lower. According to the Valve Developer Community, most Source games allow 2048 edicts. A map that runs without problems in GMod can therefore fail at the limit in another game as soon as it loads.

Why does spawning already fail below 8192?

Because GMod keeps a reserve free. According to the GMod wiki, ents.Create fails between 8064 and 8176 used edicts. Where exactly depends, among other things, on the number of player slots.

Do invisible entities use an edict as well?

Yes, if they are networked entities. Whether an entity is visible or moves does not matter. The only thing that counts is whether it gets an edict. In the stock Source code, pure logic entities do not get one.