Entity limit: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
mNo edit summary
(corrections)
Line 1: Line 1:
For reasons of memory allocation, there is a limit to the number of entities the engine can manage at once.
For reasons of memory allocation, there is a limit to the number of entities Source can manage at once.


== Engine limits ==
== Engine limits ==


There are two entity limits that apply when the engine is running:
There can be up to 4096 entities. This total is split into two groups of 2048:


# The maximum number of '''[[entity|entities]]''' that can exist at the same time is 4096.
# Non-networked entities, which exist only in <code>client.dll</code> or only in <code>server.dll</code> (e.g. death ragdolls, [[CLogicalEntity|logicals]]).
# The maximum number of '''[[edict]]s''' that can be assigned to entities at the same time is 2048.
# Networked entities with associated [[edict]]s, which can cross DLL boundaries.


If the game goes over the edict limit it will exit with an error message, whereas if it goes over the entity limit the new entity will fail to spawn and a warning will appear in the console. The logic is perhaps that an entity that is spawned dynamically but not added to the dictionary probably isn't too important.
If the game tries to assign a 2049th edict it will exit with an error message, but if it tries to create a 2049th non-networked entity it will merely refuse and print a warning to the console. The logic behind this may be that an entity spawned dynamically (i.e. not present in the map) but not assigned an edict probably isn't too important.


[[Temporary Entity|Temporary entities]] do not count toward either limit.
The two entity lists are created by <code>CBaseEntityList::CBaseEntityList()</code> using <code>NUM_ENT_ENTRIES</code> and <code>MAX_EDICTS</code>. Neither of those values can be changed without breaking compatibility with the engine.
 
{{tip|[[Temporary Entity|Temporary entities]] do not count toward either limit.}}


{{tip|If you're creating lots of individual objects all the time, consider rolling them all into a single manager entity. This is how [[Left 4 Dead]] handles huge numbers of infected: they are all "finger puppets" of the director.}}
{{tip|If you're creating lots of individual objects all the time, consider rolling them all into a single manager entity. This is how [[Left 4 Dead]] handles huge numbers of infected: they are all "finger puppets" of the director.}}
{{tip|The edict limit can't be changed in a mod because it must be in sync with the engine. It ''may'' be possible to increase the general entity limit, however.}}


== Hammer limits ==
== Hammer limits ==


[[VBSP]]'s entity limit is 8192, double the total accepted by the engine. {{confirm|This may be because it at first treats [[internal entity|internal entities]] (such as [[prop_static]] and [[env_cubemap]]) like normal entities, and/or possibly because it generates a lot of [[prop_detail|detail props]].}}
Hammer itself has no entity limit, but [[VBSP]]'s is 8192. This is double the combined total accepted by the engine, {{confirm|which may be because it at first treats [[internal entity|internal entities]] (such as [[prop_static]] and [[env_cubemap]]) like normal entities, and/or possibly because it generates a lot of [[prop_detail|detail props]].}}


''However'', it also places a size limit of 384KB on the whole <code>entdata</code> block. This prevents any map from actually coming anywhere near 8192 designer-placed entities.
VBSP places a size limit of 384KB on the <code>entdata</code> block however, which prevents any map from coming anywhere near 8192 designer-placed entities. Remember that more entities will exist in a map at runtime than were compiled into it by the level designer!


{{tip|Since VBSP's source is included in the SDK, it is perfectly possible to make your own build with the <code>entdata</code> limit increased or removed.}}
{{tip|Since VBSP's source is included in the SDK, it is perfectly possible to make your own build with the <code>entdata</code> limit increased or removed.}}

Revision as of 04:03, 16 September 2009

For reasons of memory allocation, there is a limit to the number of entities Source can manage at once.

Engine limits

There can be up to 4096 entities. This total is split into two groups of 2048:

  1. Non-networked entities, which exist only in client.dll or only in server.dll (e.g. death ragdolls, logicals).
  2. Networked entities with associated edicts, which can cross DLL boundaries.

If the game tries to assign a 2049th edict it will exit with an error message, but if it tries to create a 2049th non-networked entity it will merely refuse and print a warning to the console. The logic behind this may be that an entity spawned dynamically (i.e. not present in the map) but not assigned an edict probably isn't too important.

The two entity lists are created by CBaseEntityList::CBaseEntityList() using NUM_ENT_ENTRIES and MAX_EDICTS. Neither of those values can be changed without breaking compatibility with the engine.

Tip.pngTip:Temporary entities do not count toward either limit.
Tip.pngTip:If you're creating lots of individual objects all the time, consider rolling them all into a single manager entity. This is how Left 4 Dead handles huge numbers of infected: they are all "finger puppets" of the director.

Hammer limits

Hammer itself has no entity limit, but VBSP's is 8192. This is double the combined total accepted by the engine,

Confirm:which may be because it at first treats internal entities (such as prop_static and env_cubemap) like normal entities, and/or possibly because it generates a lot of detail props.

VBSP places a size limit of 384KB on the entdata block however, which prevents any map from coming anywhere near 8192 designer-placed entities. Remember that more entities will exist in a map at runtime than were compiled into it by the level designer!

Tip.pngTip:Since VBSP's source is included in the SDK, it is perfectly possible to make your own build with the entdata limit increased or removed.