ED_Alloc: no free edicts en GMod: el límite de edicts explicado

Un edict es un hueco en la lista de entities en red, es decir, de todos los objetos que el servidor puede transmitir a los clientes. Garry's Mod tiene 8192 de estos huecos. Cuando todos están ocupados, el motor no puede crear otra entity en red, y si aun así necesita una, el servidor termina con ED_Alloc: no free edicts. El único remedio es crear menos entities: como mapper, con objetos estáticos en lugar de dinámicos; como propietario de servidor, con límites, limpiezas y un mapa que traiga poco de por sí.

Qué es un edict y qué ocupa uno

El motor mantiene dos listas. Una contiene las entities con edict. Gracias al edict, una entity tiene el mismo número en el servidor y en cada cliente y se puede transmitir. La otra contiene las entities que solo existen en el servidor o solo en un cliente. Una entity en red mantiene ocupado su edict desde que se crea hasta que se elimina, aunque nunca se mueva.

La tabla sigue el código estándar de Source Engine (Source SDK 2013) y Valve Developer Community, porque el código del motor propio de GMod no es público. Las entities de lógica de la columna derecha no salen gratis. Cuentan para la segunda lista, que según Valve Developer Community también tiene 8192 entradas en GMod. Por qué los props estáticos ni siquiera llegan a existir como entities se explica en el artículo sobre prop_static, prop_dynamic y prop_physics.

Dónde está el límite en GMod

En el código de Source Engine, la constante MAX_EDICT_BITS define cuántos bits se usan para transmitir un número de entity. En Source SDK 2013 son 11 bits, lo que da 2048 edicts. Garry's Mod ha subido el límite. Hay tres límites que no debes confundir:

Los dos primeros valores proceden de Valve Developer Community, y la wiki de Garry's Mod confirma el primero. El tercero es el MAX_MAP_ENTITIES de VBSP, que la actualización de marzo de 2024 de Garry's Mod subió a 65k solo para las herramientas de compilación. En una prueba, el VBSP actual abortó con num_entities == MAX_MAP_ENTITIES en cuanto el archivo del mapa tenía 65536 entradas incluido el mundo, y cada prop_static contaba. Los límites de VBSP son el tema de límites de los mapas de Source Engine.

En la práctica, el final llega antes. Según la wiki de GMod, ents.Create ya falla en algún punto entre 8064 y 8176 edicts usados, dependiendo del número de slots de jugadores y de otras entities. Cerca del límite, GMod deja de crear entities nuevas a propósito. En Sandbox, el jugador ve entonces el mensaje «Failed to create an entity. Server likely hit the entity limit.» Los addons que no cuentan con una entity no válida empiezan a lanzar errores de Lua a partir de ese momento. El crash amenaza cuando no queda ningún hueco a pesar de esta protección.

Contar entities y edicts en el servidor

Introduce estos comandos en la consola del servidor:

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

• ents.GetEdictCount() devuelve el número de entities en red, ents.GetCount() el número de todas las entities.
• report_entities lista todas las entities por clase con su cantidad y termina con una línea de totales que también indica los edicts.
• sv_lowedict_threshold y sv_lowedict_action son variables del motor. Introducidas sin valor, muestran el ajuste actual.

Mide dos veces: una justo después de arrancar el mapa, sin jugadores, y otra en hora punta. La primera cifra es el coste base del mapa. La diferencia es lo que crean los jugadores y los addons.

Qué trae el mapa y cómo ahorras como mapper

Todo lo que está guardado como entity en el BSP y no se elimina solo al arrancar conserva su hueco de forma permanente. Así mantienes bajo el coste base:

1. Haz estáticos los props. Cada prop_dynamic y cada prop_physics cuesta un edict, un prop_static no cuesta ninguno.
2. Agrupa brushes. Varios brushes en un func_brush son una sola entity. Si no necesitan ninguna función, conviértelos en func_detail y desaparecen por completo de la lista de entities al compilar.
3. Deja las luces sin nombre. En el código estándar de Source Engine (Source SDK 2013), un light o un light_spot sin nombre se elimina solo al arrancar el mapa, porque su luz ya está en los lightmaps. Con nombre, se queda como entity.
4. Revisa los sprites. Cada env_sprite es una entity en red. El FGD de GMod contiene env_sprite_clientside. Según Valve Developer Community, se elimina en el servidor tras el arranque siempre que no tenga ni nombre ni parent.
5. Cuidado con los bone followers. Un prop cuyo modelo tiene un modelo de colisión articulado crea una entity phys_bone_follower adicional por cada pieza. La propiedad Disable Bone Followers del prop_dynamic lo evita, pero te cuesta la colisión.

Puedes comprobar el resultado en el Map Scanner. Para un BSP muestra el número de entities y las clases de entity más frecuentes. Hay más palancas en optimizar el rendimiento de un mapa de GMod.

Qué añaden los jugadores y los addons en tiempo de ejecución

• Jugadores: Cada jugador es una entity, y cada arma de su inventario es otra.
• Props spawneados: Sandbox crea cada prop como prop_physics. El valor por defecto de sbox_maxprops es 200 por jugador. Con 40 jugadores serían hasta 8000 props y, por tanto, casi todo el presupuesto.
• Otros límites de Sandbox: Por defecto, Sandbox permite además 10 ragdolls, 4 vehículos, 10 NPC y 100 entities (sbox_maxsents) por jugador.
• Wiremod: Cada holograma de Expression 2 es una entity en red. Wiremod limita la cantidad por jugador con wire_holograms_max.
• Objetos compuestos: En la práctica, los addons de vehículos y las construcciones grandes suelen constar de muchas entities individuales. El número exacto depende del addon.

Cuando un jugador sale del servidor, el código estándar de Source Engine elimina sus armas junto con él. En Sandbox, sus props se quedan hasta que alguien limpia.

Qué puedes hacer como propietario de servidor

1. Haz cuentas. Multiplica tus valores sbox_max por el número habitual de jugadores y suma el coste base del mapa. Si el resultado supera aproximadamente 8000, baja los límites.
2. Limpia. Usado como admin, gmod_admin_cleanup elimina todo lo que han spawneado los jugadores y reinicia el mapa. Con gmod_cleanup, cada jugador borra sus propios objetos. Los addons de prop protection suelen ofrecer eliminar los props de los jugadores desconectados tras un plazo.
3. Recibe un aviso temprano. Según el texto de ayuda de las dos variables, el motor ejecuta sv_lowedict_action cuando solo quedan libres tantos edicts como indica sv_lowedict_threshold: 0 nada, 1 advertencia en el log, 2 reiniciar el juego, 3 reiniciar el mapa, 4 siguiente mapa del map cycle.
4. Elige un mapa adecuado. En bspmarket.de, los Datos técnicos de un mapa indican los valores aproximados Entities (mapa) y Props estáticos. En las categorías puedes filtrar por número de entities. Qué más entra en la elección se explica en cómo elegir un mapa de DarkRP.

También encontrarás explicaciones de este mensaje y de otros relacionados en la base de datos de errores.

Preguntas frecuentes

¿Puedo subir el límite de edicts?

No. El valor está compilado en el motor y, según Valve Developer Community, no se puede cambiar sin romper la compatibilidad con el motor. Lo único que puedes hacer es reducir el número de entities.

¿El límite también se aplica en otros juegos de Source?

En la mayoría es más bajo. Según Valve Developer Community, la mayoría de los juegos de Source permiten 2048 edicts. Por eso, un mapa que funciona sin problemas en GMod puede fallar por el límite en otro juego nada más cargar.

¿Por qué falla el spawn ya por debajo de 8192?

Porque GMod mantiene libre una reserva. Según la wiki de GMod, ents.Create falla entre 8064 y 8176 edicts usados. Dónde exactamente depende, entre otras cosas, del número de slots de jugadores.

¿Las entities invisibles también ocupan un edict?

Sí, si son entities en red. Da igual que una entity sea visible o que se mueva. Lo único que cuenta es si recibe un edict. En el código estándar de Source Engine, las entities de pura lógica no reciben ninguno.