ED_Alloc: no free edicts in GMod: das Edict-Limit erklärt

Ein Edict ist ein Platz in der Liste der vernetzten Entities, also aller Objekte, die der Server an die Clients übertragen kann. Garry's Mod hat 8192 solcher Plätze. Sind alle belegt, kann die Engine kein weiteres vernetztes Entity anlegen, und braucht sie trotzdem eines, endet der Server mit ED_Alloc: no free edicts. Dagegen hilft nur, weniger Entities zu erzeugen: als Mapper mit statischen statt dynamischen Objekten, als Serverbetreiber mit Limits, Aufräumen und einer Map, die selbst wenig mitbringt.

Was ein Edict ist und was eines belegt

Die Engine verwaltet zwei Listen. In der einen stehen Entities mit Edict. Über das Edict hat ein Entity auf dem Server und auf jedem Client dieselbe Nummer und kann übertragen werden. In der anderen stehen Entities, die nur auf dem Server oder nur auf einem Client existieren. Ein vernetztes Entity hält sein Edict vom Erzeugen bis zum Entfernen besetzt, auch wenn es sich nie bewegt.

Die Tabelle folgt dem Standardcode der Source Engine (Source SDK 2013) und der Valve Developer Community, denn der Engine-Code von GMod selbst ist nicht öffentlich. Die Logik-Entities der rechten Spalte sind nicht kostenlos. Sie zählen zur zweiten Liste, die in GMod laut Valve Developer Community ebenfalls 8192 Einträge fasst. Warum statische Props gar nicht erst als Entity existieren, erklärt der Artikel zu prop_static, prop_dynamic und prop_physics.

Wo das Limit in GMod liegt

Im Code der Source Engine legt die Konstante MAX_EDICT_BITS fest, mit wie vielen Bits eine Entity-Nummer übertragen wird. Im Source SDK 2013 sind es 11 Bits, also 2048 Edicts. Garry's Mod hat die Grenze angehoben. Du darfst drei Limits nicht verwechseln:

Die ersten beiden Werte nennt die Valve Developer Community, den ersten bestätigt das Wiki von Garry's Mod. Der dritte ist MAX_MAP_ENTITIES von VBSP. Das Update vom März 2024 hat ihn in Garry's Mod auf 65k angehoben, und zwar nur für die Compile-Tools. Im Test brach das aktuelle VBSP mit num_entities == MAX_MAP_ENTITIES ab, sobald die Map-Datei samt Welt 65536 Einträge enthielt, und jedes prop_static zählte mit. Die Limits von VBSP sind Thema von Source Engine Map-Limits.

In der Praxis ist früher Schluss. Laut GMod-Wiki schlägt ents.Create bereits irgendwo zwischen 8064 und 8176 belegten Edicts fehl, abhängig von der Zahl der Spieler-Slots und anderen Entities. GMod erzeugt in der Nähe der Grenze absichtlich keine neuen Entities mehr. In Sandbox sieht der Spieler dann die Meldung „Failed to create an entity. Server likely hit the entity limit.“ Addons, die mit einem ungültigen Entity nicht rechnen, werfen ab diesem Punkt Lua-Fehler. Der Absturz droht, wenn trotz dieser Sperre kein Platz mehr frei ist.

Entities und Edicts auf dem Server zählen

Diese Befehle gibst du in der Serverkonsole ein:

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

• ents.GetEdictCount() liefert die Zahl der vernetzten Entities, ents.GetCount() die Zahl aller Entities.
• report_entities listet alle Entities nach Klasse mit Anzahl auf und endet mit einer Summenzeile, die auch die Edicts nennt.
• sv_lowedict_threshold und sv_lowedict_action sind Variablen der Engine. Ohne Wert eingegeben, zeigen sie die aktuelle Einstellung.

Miss zweimal: einmal direkt nach dem Start der Map ohne Spieler und einmal zur Hauptzeit. Die erste Zahl ist der Sockel, den die Map kostet. Die Differenz ist das, was Spieler und Addons erzeugen.

Was die Map mitbringt und wie du als Mapper sparst

Alles, was als Entity in der BSP steht und sich beim Start nicht selbst entfernt, belegt seinen Platz dauerhaft. So hältst du den Sockel klein:

1. Props statisch machen. Jedes prop_dynamic und prop_physics kostet ein Edict, ein prop_static keines.
2. Brushes zusammenfassen. Mehrere Brushes in einem func_brush sind ein Entity. Brauchen sie keine Funktion, werden sie func_detail und verschwinden beim Kompilieren ganz aus der Entity-Liste.
3. Lichter ohne Namen lassen. Im Standardcode der Source Engine (Source SDK 2013) entfernt sich ein light oder light_spot ohne Namen beim Start der Map selbst, weil sein Licht schon in den Lightmaps steckt. Mit Namen bleibt es als Entity bestehen.
4. Sprites prüfen. Jedes env_sprite ist ein vernetztes Entity. Die FGD von GMod enthält env_sprite_clientside. Laut Valve Developer Community wird es nach dem Start auf dem Server entfernt, solange es weder Namen noch Parent hat.
5. Auf Bone Follower achten. Ein Prop, dessen Model ein Kollisionsmodell mit Gelenken hat, erzeugt für jedes Teilstück ein zusätzliches Entity phys_bone_follower. Die Eigenschaft Disable Bone Followers am prop_dynamic verhindert das, kostet aber die Kollision.

Kontrollieren kannst du das Ergebnis im Map Scanner. Für eine BSP zeigt er die Zahl der Entities und die häufigsten Entity-Klassen. Weitere Stellschrauben stehen in GMod-Map optimieren.

Was Spieler und Addons zur Laufzeit hinzufügen

• Spieler: Jeder Spieler ist ein Entity, und jede Waffe in seinem Inventar ist ein weiteres.
• Gespawnte Props: Sandbox legt jedes Prop als prop_physics an. Die Vorgabe für sbox_maxprops ist 200 pro Spieler. Bei 40 Spielern wären das bis zu 8000 Props und damit fast das gesamte Budget.
• Weitere Sandbox-Limits: In der Vorgabe erlaubt Sandbox pro Spieler außerdem 10 Ragdolls, 4 Fahrzeuge, 10 NPCs und 100 Entities (sbox_maxsents).
• Wiremod: Jedes Hologramm aus Expression 2 ist ein vernetztes Entity. Wiremod begrenzt die Zahl pro Spieler mit wire_holograms_max.
• Zusammengesetzte Objekte: Fahrzeug-Addons und große Konstruktionen bestehen in der Praxis oft aus vielen einzelnen Entities. Die genaue Zahl hängt vom Addon ab.

Verlässt ein Spieler den Server, entfernt der Standardcode der Source Engine seine Waffen gleich mit. Seine Props bleiben in Sandbox stehen, bis jemand aufräumt.

Was du als Serverbetreiber tun kannst

1. Rechnen. Multipliziere deine sbox_max-Werte mit der üblichen Spielerzahl und addiere den Sockel der Map. Liegt das Ergebnis über etwa 8000, senke die Limits.
2. Aufräumen. gmod_admin_cleanup entfernt als Admin alles, was Spieler gespawnt haben, und setzt die Map zurück. Mit gmod_cleanup räumt jeder Spieler seine eigenen Objekte weg. Prop-Protection-Addons bieten oft an, die Props getrennter Spieler nach einer Frist zu entfernen.
3. Vorwarnen lassen. Laut dem Hilfetext der beiden Variablen führt die Engine sv_lowedict_action aus, sobald nur noch so viele Edicts frei sind, wie sv_lowedict_threshold angibt: 0 nichts, 1 Warnung ins Log, 2 Spiel neu starten, 3 Map neu starten, 4 nächste Map im Mapcycle.
4. Die Map passend wählen. Auf bspmarket.de stehen bei einer Map unter Technische Daten die Richtwerte Entities (Map) und Statische Props. In den Kategorien kannst du nach der Entity-Zahl filtern. Was sonst zur Auswahl gehört, steht in DarkRP-Map auswählen.

Erläuterungen zu dieser und verwandten Meldungen findest du auch in der Fehlerdatenbank.

Häufige Fragen

Kann ich das Edict-Limit erhöhen?

Nein. Der Wert ist fest in die Engine einkompiliert und lässt sich laut Valve Developer Community nicht ändern, ohne die Kompatibilität mit der Engine zu brechen. Dir bleibt nur, die Zahl der Entities zu senken.

Gilt das Limit auch in anderen Source-Spielen?

In den meisten ist es niedriger. Laut Valve Developer Community erlauben die meisten Source-Spiele 2048 Edicts. Eine Map, die in GMod problemlos läuft, kann deshalb in einem anderen Spiel schon beim Laden an der Grenze scheitern.

Warum scheitert das Spawnen schon unter 8192?

Weil GMod eine Reserve frei hält. Laut GMod-Wiki schlägt ents.Create zwischen 8064 und 8176 belegten Edicts fehl. Wo genau, hängt unter anderem von der Zahl der Spieler-Slots ab.

Belegen unsichtbare Entities auch ein Edict?

Ja, wenn sie zu den vernetzten Entities gehören. Ob ein Entity sichtbar ist oder sich bewegt, spielt keine Rolle. Entscheidend ist allein, ob es ein Edict bekommt. Reine Logik-Entities bekommen im Standardcode der Source Engine keines.