Entity limit: Difference between revisions
(Props and the phys_bone_follower entity regarding edict count) |
(Removed the completely wrong and useless tip) |
||
Line 22: | Line 22: | ||
{{tip|In-game, use console commands like <code>report_entities</code> and <code>cl_showents</code> to get an idea of how many entities are present at that current state.}} | {{tip|In-game, use console commands like <code>report_entities</code> and <code>cl_showents</code> to get an idea of how many entities are present at that current state.}} | ||
{{tip|Prop entities with a collision model (except prop_static and prop_detail), will generate a [[phys_bone_follower]] entity for every attachment it has, and if there isn't any, it automatically adds a default one. These can quickly eat up the edict count! They can however, be disabled by setting the "Disable Bone Followers" keyvalue to Yes, although this will break the collision model completely.}} | |||
{{tip|Prop entities with a collision model (except prop_static and prop_detail), will generate a [[phys_bone_follower]] entity for every attachment it has, and if there isn't any, it automatically adds a default one. These can quickly eat up the edict count! They can however, be disabled by setting the "Disable Bone Followers" keyvalue to Yes, although this will break the collision model completely | |||
:{{tip|If you want to further save edict count, you could modify a model to remove all attachments except the necessary ones you need.}} | :{{tip|If you want to further save edict count, you could modify a model to remove all attachments except the necessary ones you need.}} | ||
Revision as of 03:57, 17 July 2018
For reasons of memory allocation, there is a limit to the number of entities Source can manage at once.
The combined size (in bytes) of a map's entity data should also be considered, even if the number of entities is within safe limits. Large amounts of entdata can take a noticeably long time to transmit from server to client, and may lead to crashes.

Engine limits
There can be up to 4096 entities. This total is split into two groups of 2048:
- Non-networked entities, which exist only on the client or server (e.g. death ragdolls on client, logicals on server).
- Entities with associated edicts, which can cross the client/server divide.
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.



report_entities
and cl_showents
to get an idea of how many entities are present at that current state.
Tip:If you want to further save edict count, you could modify a model to remove all attachments except the necessary ones you need.
Hammer limits
Hammer itself has no entity limit, but VBSP's is 8192. This is double the combined total accepted by the engine, which may be because it at first treats internal entities (such as prop_static and env_cubemap) like normal entities, or perhaps because it generates a lot of detail props.
VBSP also recommends an entdata size limit of 384KB, but this is in no way enforced.