prop_static vs prop_dynamic vs prop_physics: Differences and Errors

A prop_static is written into the BSP at compile time and is no longer an entity in game: it never moves, accepts no inputs and takes no slot in the entity budget. A prop_dynamic is a real entity that plays animations, can be parented to other entities and can be controlled through inputs. A prop_physics is an entity simulated by the physics system, so it falls, rolls and can be pushed. Which types a model supports is decided when the model is compiled, and that is exactly what VBSP checks when it deletes a prop_static from your map.

The three types compared

VBSP writes static props into their own section of the BSP and removes them from the entity list. In a test with GMod's VBSP, no prop_static was left in the entity lump after compiling, while every prop_dynamic and prop_physics was. The sections of a BSP are described in What is a BSP file.

For a server, the last row matters most. Every dynamic or physics prop occupies one of the limited slots for networked entities. What happens when they run out is explained under edict limit.

Lighting, collision and performance

Of the three types, VRAD only includes prop_static in the lighting. It casts shadows onto the lightmaps, and with the VRAD option -StaticPropLighting its light is calculated per vertex. Dynamic and physics props do not affect the lightmaps. They are lit at a single point and only cast dynamic shadows. A house placed as a prop_dynamic therefore has no baked shadow, and if its sampling point is in the dark, the whole model looks too dark. The options are explained in lighting in the Source Engine.

For collision, the Use VPhysics setting uses the model's collision model. If the model has none, the engine prints a warning on load and the prop becomes non-solid, according to the Valve Developer Community. A prop_physics without a collision model gets no physics object. In the stock Source code (Source SDK 2013), the game then reports ERROR!: Can't create physics object for [model] and leaves the prop motionless and non-solid. Garry's Mod's server.dll contains the same message.

As an order of magnitude, the Valve Developer Community names thousands of static props per map, hundreds of dynamic ones and, depending on complexity, tens to hundreds of physics props. A static prop has no network overhead, while a physics prop has to be simulated and transmitted to every player.

What the model dictates and how to see it in Hammer

Two pieces of data in the model decide which types are allowed. The QC command $staticprop strips the skeleton and animations and is required for prop_static. A prop_data block holds the physics and damage values and marks the model as a physics prop. The stated reason for the separation is consistency: a barrel that rolls on one map should not be bolted down on the next.

This is how you check a model:

1. In the prop's properties, open the model browser from the World model entry.
2. Select the model and switch to the Info tab.
3. Read the three check marks physics, dynamic and static. The mass is shown below them.

The variants in one sentence each

• prop_dynamic_override: like prop_dynamic, but accepts models intended as physics props. The FGD calls it a prototyping entity only.
• prop_physics_override: like prop_physics, but overrides the data stored in the model and allows a custom Health value. The model still needs a collision model.
• prop_physics_multiplayer: like prop_physics, with simplified collisions that avoid prediction errors over the network and the additional Physics Mode property.
• prop_detail: a detail prop without collision that ends up in the BSP like prop_static. It is rarely placed by hand; usually VBSP generates detail props from the material.
• prop_ragdoll: a physics prop with joints. It is expensive to simulate and produces a lot of network traffic.

Typical messages and what to do about them

These lines come from a test with GMod's VBSP:

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: The model has prop_data without allowstatic. Use prop_physics, or prop_dynamic_override if it should stand still. For a model of your own, add allowstatic or leave out prop_data. GMod's VBSP also has the option -allowdynamicpropsasstatic, which switches this check off.
• must be compiled with $staticprop: The model was compiled without $staticprop, usually because it has bones or animations. Use prop_dynamic or recompile your own model with $staticprop.
• Error loading studio model on its own: If the line appears in the log without one of the other two, VBSP did not find the model file. The causes are described in Fix missing textures and ERROR models.
• outside the map: The prop sits outside the sealed area or is completely inside a brush. Move it. In the test, the prop outside the sealed area also caused a leak (**** leaked ****), because VBSP treats it there like any other entity. A prop buried completely in a brush only produced this one line.

VBSP keeps compiling in all four cases. The prop is simply missing in game, and only the log reveals why. Paste it into the Map Scanner or look the message up in the error database. The remaining lines are covered in reading a compile log.

For prop_dynamic and prop_physics, VBSP checks nothing. In the stock Source code (Source SDK 2013), the game does the check when it creates the prop: it deletes a mismatched prop and, with developer 1 enabled, writes to the console: prop_physics at [x] [y] [z] uses model [model], which has no propdata which means it must be used on a prop_static. DELETED. Garry's Mod's server.dll contains neither this text nor its counterpart for prop_dynamic. Only the message for an invalid prop_data type is still there. This suggests that GMod does not apply the check, and it would fit with Sandbox creating every spawned prop as a prop_physics, whatever the model. It has not been tested in the running game, so do not rely on it as a mapper: if you follow the Info tab, the map behaves the same in every Source game.

Decision table

FAQ

Can players move my map props with the Physics Gun?

A prop_static never, because it is not an entity. In Sandbox, a prop_dynamic or prop_physics from the map can be grabbed by default. Setting the Allow Physics Gun property (gmod_allowphysgun) to No locks an individual prop. Other gamemodes and prop protection addons apply their own rules.

Can I hide or destroy a prop_static in game?

No. It has no name and accepts no inputs. Use a prop_dynamic for that, which has the inputs TurnOff and TurnOn. Wiring them up is covered in inputs and outputs in Hammer.

Does a prop_static count towards any limit?

Not at runtime, neither as an entity nor as an edict. When compiling, however, VBSP counts it towards its own cap on entries in the map file. For an overview see Source Engine map limits.