prop_static, prop_dynamic, prop_physics: Unterschied und Fehler

Ein prop_static wird beim Kompilieren fest in die BSP geschrieben und ist im Spiel kein Entity mehr: Es bewegt sich nie, nimmt keine Inputs an und belegt keinen Platz im Entity-Budget. Ein prop_dynamic ist ein echtes Entity, das Animationen abspielt, an andere Entities gebunden und per Input geschaltet werden kann. Ein prop_physics ist ein Entity, das die Physik simuliert, also fällt, rollt und sich schieben lässt. Welche Typen ein Model unterstützt, wird beim Kompilieren des Models festgelegt, und genau das prüft VBSP, wenn es ein prop_static aus deiner Map löscht.

Die drei Typen im Vergleich

VBSP schreibt statische Props in einen eigenen Datenbereich der BSP und streicht sie aus der Entity-Liste. In einem Test mit dem VBSP von Garry's Mod stand nach dem Kompilieren kein einziges prop_static mehr im Entity-Lump, jedes prop_dynamic und prop_physics dagegen schon. Wie die Bereiche einer BSP aufgebaut sind, zeigt Was ist eine BSP-Datei.

Für den Server zählt vor allem die letzte Zeile. Jedes dynamische oder physikalische Prop belegt im Spiel einen der begrenzten Plätze für vernetzte Entities. Was passiert, wenn sie ausgehen, steht im Artikel zum Edict-Limit.

Licht, Kollision und Performance

Von den drei Typen rechnet VRAD nur prop_static in die Beleuchtung ein. Es wirft Schatten in die Lightmaps, und mit der VRAD-Option -StaticPropLighting wird sein Licht pro Eckpunkt berechnet. Dynamische und physikalische Props beeinflussen die Lightmaps nicht. Sie werden im Spiel an einem einzigen Punkt beleuchtet und werfen nur dynamische Schatten. Ein Haus als prop_dynamic steht deshalb ohne gebackenen Schatten auf dem Boden, und liegt sein Messpunkt im Dunkeln, wirkt das ganze Model zu dunkel. Die Optionen erklärt der Artikel zur Beleuchtung in der Source Engine.

Bei der Kollision nutzt die Einstellung Use VPhysics das Kollisionsmodell des Models. Hat es keines, warnt die Engine laut Valve Developer Community beim Laden und das Prop wird durchlässig. Ein prop_physics ohne Kollisionsmodell bekommt kein Physik-Objekt. Im Standardcode der Source Engine (Source SDK 2013) meldet das Spiel dann ERROR!: Can't create physics object for [model] und lässt das Prop reglos und durchlässig. Dieselbe Meldung steckt in der server.dll von Garry's Mod.

Als Größenordnung nennt die Valve Developer Community Tausende statische Props pro Map, Hunderte dynamische und je nach Komplexität Dutzende bis Hunderte physikalische. Ein statisches Prop hat keinen Netzwerkaufwand, ein Physik-Prop muss simuliert und an alle Spieler übertragen werden.

Was das Model vorgibt und wie du es in Hammer siehst

Zwei Angaben im Model entscheiden über die erlaubten Typen. Der QC-Befehl $staticprop entfernt Skelett und Animationen und ist Voraussetzung für prop_static. Ein Block prop_data enthält die Physik- und Schadenswerte und kennzeichnet das Model als Physik-Prop. Begründet wird die Trennung mit Konsistenz: Ein Fass, das auf einer Map rollt, soll auf der nächsten nicht festgeschraubt sein.

So prüfst du ein Model:

1. Öffne in den Eigenschaften des Props den Model Browser über den Eintrag World model.
2. Wähle das Model aus und wechsle auf den Reiter Info.
3. Lies die drei Häkchen physics, dynamic und static ab. Darunter steht die Masse.

Die Varianten in einem Satz

• prop_dynamic_override: wie prop_dynamic, akzeptiert aber Models, die als Physik-Prop gedacht sind. Die FGD nennt es ein reines Prototyping-Entity.
• prop_physics_override: wie prop_physics, setzt sich aber über die Angaben im Model hinweg und erlaubt einen eigenen Wert für Health. Das Model braucht trotzdem ein Kollisionsmodell.
• prop_physics_multiplayer: wie prop_physics, mit vereinfachter Kollision gegen Vorhersagefehler im Netzwerk und der zusätzlichen Eigenschaft Physics Mode.
• prop_detail: ein Detail-Prop ohne Kollision, das wie prop_static in der BSP landet. Von Hand platziert man es selten, meist erzeugt VBSP Detail-Props über das Material.
• prop_ragdoll: ein Physik-Prop mit Gelenken. Es ist teuer in der Simulation und erzeugt viel Netzwerkverkehr.

Typische Meldungen und was du dann tust

Diese Zeilen stammen aus einem Testlauf mit dem VBSP von Garry's Mod:

Error! prop_static using model "models/props_c17/oildrum001.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted.
Error! To use model "models/props_c17/door01_left.mdl" with prop_static, it must be compiled with $staticprop!
Error loading studio model STATIC "models/props_does_not/exist.mdl"!
Static prop models/props_c17/fence01a.mdl outside the map (2000.00, 2000.00, 0.00)

• must be used on a dynamic entity: Das Model hat prop_data ohne allowstatic. Nimm prop_physics, oder prop_dynamic_override, wenn es stillstehen soll. Bei einem eigenen Model ergänzt du allowstatic oder lässt prop_data weg. Das VBSP von GMod kennt außerdem die Option -allowdynamicpropsasstatic, die diese Prüfung abschaltet.
• must be compiled with $staticprop: Das Model wurde ohne $staticprop kompiliert, meist weil es Knochen oder Animationen hat. Nimm prop_dynamic oder kompiliere ein eigenes Model mit $staticprop neu.
• Error loading studio model allein: Steht die Zeile ohne eine der beiden anderen im Log, hat VBSP die Model-Datei nicht gefunden. Die Ursachen beschreibt Fehlende Texturen und ERROR-Models beheben.
• outside the map: Das Prop steht außerhalb des abgedichteten Bereichs oder steckt vollständig in einem Brush. Verschiebe es. Im Test löste das Prop außerhalb des abgedichteten Bereichs zusätzlich ein Leak aus (**** leaked ****), weil VBSP es dort wie jedes andere Entity behandelt. Ein Prop, das vollständig in einem Brush steckte, erzeugte nur diese eine Zeile.

VBSP kompiliert in allen vier Fällen weiter. Das Prop fehlt dann einfach im Spiel, und nur das Log verrät den Grund. Füge es im Map Scanner ein oder schlage die Meldung in der Fehlerdatenbank nach. Wie du die übrigen Zeilen deutest, steht in Compile-Log lesen.

Bei prop_dynamic und prop_physics prüft VBSP nichts. Im Standardcode der Source Engine (Source SDK 2013) prüft das Spiel, sobald es das Prop erzeugt: Es löscht ein unpassendes Prop und schreibt bei aktiviertem developer 1 in die Konsole: prop_physics at [x] [y] [z] uses model [model], which has no propdata which means it must be used on a prop_static. DELETED. Die server.dll von Garry's Mod enthält weder diesen Text noch sein Gegenstück für prop_dynamic. Nur die Meldung für einen ungültigen prop_data-Typ ist noch vorhanden. Das spricht dafür, dass GMod die Prüfung nicht anwendet, und es würde dazu passen, dass Sandbox jedes gespawnte Prop unabhängig vom Model als prop_physics anlegt. Im laufenden Spiel getestet ist das nicht. Verlass dich als Mapper deshalb nicht darauf: Richtest du dich nach dem Reiter Info, verhält sich die Map in jedem Source-Spiel gleich.

Entscheidungstabelle

Häufige Fragen

Können Spieler meine Map-Props mit der Physics Gun bewegen?

Ein prop_static nie, denn es ist kein Entity. In Sandbox lassen sich prop_dynamic und prop_physics aus der Map standardmäßig greifen. Mit der Eigenschaft Allow Physics Gun (gmod_allowphysgun) auf No sperrst du ein einzelnes Prop. Andere Spielmodi und Prop-Protection-Addons haben eigene Regeln.

Kann ich ein prop_static im Spiel ausblenden oder zerstören?

Nein. Es hat keinen Namen und nimmt keine Inputs an. Nimm dafür ein prop_dynamic, das die Inputs TurnOff und TurnOn kennt. Wie du sie verdrahtest, zeigt Inputs und Outputs in Hammer.

Zählt ein prop_static zu irgendeinem Limit?

Zur Laufzeit nicht, weder als Entity noch als Edict. Beim Kompilieren zählt VBSP es aber zu seiner eigenen Obergrenze für Einträge in der Map-Datei. Die Grenzen im Überblick findest du in Source Engine Map-Limits.