From Valve Developer Community
(Redirected from Prop Data)
Jump to: navigation, search

prop_data can be used to make a model:

It is a KeyValues block embedded with the QC command $keyvalues.

Note:The properties of a model's surface are defined by $surfaceprop.
Note:Models for use with prop_physics will also need $staticprop.


		base			Wooden.Small 
		dmg.bullets		0 
		explosive_damage	100
		explosive_radius	50 

Here we derive prop_data from the generic base_type "Wooden.Small". Then we use additional keyvalues to give the model three special characteristics: it will be bulletproof, but when it breaks it will explode and cause up to 100 damage to entities within a 50 unit radius.


You don't need to override anything at all if you don't want to
Just set a base and you've got a working physics prop.
Don't override health levels in all your props
Instead, let the base types set the health. This way you won't have one chair that takes twice as much damage as every other chair.
Whenever possible, avoid mixing material types inside the same prop
Don't make half-metal, half-wood props.
Avoid collecting multiple objects into the same prop
Especially if you or Valve individually simulate identical-looking objects elsewhere.
Avoid moving parts and materials Source doesn't simulate
Don't put water in a physical fish tank.

Should my model be physical?

In Half-Life 2, Valve tried to follow these general rules:

If it's going to attach to or act as a support for a non-moving thing...
It should be static.
If it generates static light...
It should be static.
If it's really big and the player couldn't possibly move it...
It should be static.
It should be physical.

Additionally, Valve consider metal and plastic invulnerable but everything else breakable.


Base type

base <string>
Gives the model a predefined prop_data type, providing in one motion all the data the engine needs to make the model both physical and breakable. Most other commands in a prop_data block are overrides of values inherited from here.


health <int>
The amount of damage this prop should take before breaking. 0 means don't break.
allowstatic <bool>
Allows the model to be used with prop_static. To enforce consistency, avoid if possible.
physicsmode <choices>
Sets the physics mode used by prop_physics_multiplayer. Can be overridden by the entity in the Orange Box.
  • Solid, pushes the player away.
  • Non-solid, but gets pushed away by the player.
  • Non-solid, clientside simulated only.
blockLOS <bool>
Overrides whether the prop should block NPC line of sight. If unspecified, the game engine will decide based on the model's dimensions.
AIWalkable <bool>
Should NPCs try walking over this prop? To do: Does prop type matter?

Damage modifiers

Use damage modifiers to reflect differences between the amount of damage that an object takes from different attacks. Don't use them to reflect overall damage strength. (e.g. Stone is resilient to everything. To reflect this, increase the health of all stone objects, don't set the damage modifiers lower.)

dmg.bullets <float> 
Modifies damage done by bullets.
  • Paper, Cloth and Glass = 0.5
  • Wood = 0.75
  • Flesh = 1.25. <float> 
Modifies damage done by blunt impacts.
  • Cloth = 0.75
  • Paper and Pottery = 1.25
  • Wood = 2.0
dmg.explosive <float> 
Modifies damage done by explosions.
  • Paper, Cloth, Pottery, Flesh and Wood = 1.5
damage_table <choices>
Impact Damage Tables are defined in C++ code (in physics_impact_damage.cpp), and contain very detailed information about what damage a prop should take from different directions and forces. Only Glass and Pottery base_types inherit one.
Tip:Use damage_table "" to ignore an inherited table.
Extremely fragile, will break just by being dropped.
To do
To do
To do

Flammable props

fire_interactions is a subkey of prop_data that defines flammability. There are only three known parameters, each with only one known value:

         ignite      halfhealth 	// Will ignite spontaneously on reaching 50% health.
         explosive_resist   yes 	// Clamp blast damage so that the prop ignites instead of breaking.
         flammable          yes 	// Can be ignited by fire and explosions.
  • Note:fire_interactions may not function while within the prop_data section. Move it just below the prop_data section if you encounter problems
  • To do: confirm that fire_interactions are not used for flammable NPC models.
  • To do: confirm whether unbreakable (health 0) models can be flammable.

Exploding props

If these two fields are specified for a prop, and it is given health so that it can be damaged, then it will explode when it breaks.

explosive_damage <float>
The amount of explosive damage.
explosive_radius <float>
The radius of the explosion. Damage falls off as distance from the origin increases.


The prop_data system handles generic gibs. Generic gibs are used for any breakable object that doesn't have custom gibs.

breakable_model <choices>
Defines the set of generic gibs (as defined in scripts\propdata.txt) this prop should break into. Props with a wooden base type gib in this manner already. See also creating custom gibs.
  • WoodChunks
  • GlassChunks
  • ConcreteChunks
  • MetalChunks
breakable_count <int>
The number of generic breakable gibs to break into. If this is not specified, the engine will generate a sensible number based on the gibs' and model's sizes.
breakable_skin <int>
Allows you to specify a skin to use on the gib models, which is useful for matching the original prop's skin.
Only props with Wooden base_types inherit a gib skin (skin 0).
multiplayer_break <choices>
Confirm:Determines where the gibs from a prop_physics_multiplayer are simulated.
  • both
  • server
  • client (default)
  • To do: Confirm whether breakable_count, breakable_skin and multiplayer_break do not affect custom gibs.
  • To do: Confirm whether multiplayer_break is set for the breakable model rather than each individual gib itself.

Creating new base types

All base types are defined in scripts\propdata.txt. If you edit a base type in this file, you will affect the behaviour of all models using it (that do not have their own overrides).

The format of the file is:

	<base type name>
		<any number of the prop_data KVs listed above>

Valve generally only use their base types to set health and damage modifiers.

Creating generic gibs

Generic gibsets are also defined in propdata.txt. Valve have only four, and only one (WoodChunks) is assigned to a base type - most models instead specify theirs directly, with breakable_model.

Defining a new gibset is easy as most of the work is done by the engine:

			// Smallest to largest:
			models\Gibs\wood_gib01e.mdl	1
			models\Gibs\wood_gib01d.mdl	1
			models\Gibs\wood_gib01c.mdl	1
			models\Gibs\wood_gib01b.mdl	1
			models\Gibs\wood_gib01a.mdl	1

Prototyping models

When working on prototypes, or when you don't have modellers handy, it's useful to be able to work around the prop data system's enforcement. To do this, use the prop_physics_override and prop_dynamic_override entities instead of prop_physics and prop_dynamic. A prop_physics_override entity will not remove itself if it is assigned a model that wants to be static (i.e. has no "prop_data" entry in its $keyvalues .QC section). It will also allow the level designer to set its "health".

The override entities allow you to temporarily use models incorrectly while prototyping, or waiting for a modeller to finish up a new model that has the properties you desire. It is highly recommended that you use Hammer's Entity Report feature to check each of your maps to ensure you have no override entities left when you ship them. Otherwise you may be shipping physics inconsistencies, and players are extremely quick to notice them (the orange bucket won't move when I shoot it on this level, but it did on the previous one).

See also func_physbox for brush-based physics objects.

See also