prop_data

prop_data is a QC keyvalue available in all Source games. It is used to specify specific data about a prop. It can be used to make a model:

• Physical (by default models with prop_data cannot be static)
• Breakable (with gibs)
• Flammable
• Explosive

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.

Example

$keyvalues
{
	prop_data
	{
		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.

Tips

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.

Otherwise...

It should be physical.

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

Options

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.

General

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. This is disabled by default to enforce consistency.
As this is only checked by the compilers and by not the engine, modified BSP compilers (ex: ) can be used to compile physics props as static regardless of this variable.

physicsmode <choices>

Sets the physics mode used by prop_physics_multiplayer. Can be overridden by the entity in the Orange Box.

Number	Name	Description
1	Solid, Server-side	Solid, pushes the player away.
2	Non-Solid, Server-side	Non-solid, but gets pushed away by the player.
3	Non-Solid, Client-side	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?

Todo: 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.

dmg.club <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.

glass

Extremely fragile, will break just by being dropped.

player

^[Todo]

player_vehicle

^[Todo]

npc

^[Todo]

Flammable props

See fire_interactions

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.

See the "explode_fire" prop interaction for explosions that only ignite entities

Interactions

Prop interactions are technically part of prop_data and can be used in base types and even within prop_data's $keyvalues section, but they are usually used separately and can be embedded in a model as independent blocks without the direct use of prop_data at all. They are used to serve specific functions like sticking to a wall when launched by the gravity gun or igniting when at half-health.

Read more about them here.

Gibs

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)

• Todo: Confirm whether breakable_count, breakable_skin and multiplayer_break do not affect custom gibs.
• Todo: 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:

PropData.txt
{
	<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:

PropData.txt
{
	BreakableModels
	{
		WoodChunks
		{
			// 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.

See also func_physbox for brush-based physics objects.

See also

• prop_data base types
• prop_static, prop_dynamic, prop_physics - common prop entities.
• Prop Types Overview - an article describing various prop types.
• Prop interactions - a group of QC $keyvalues blocks that handles some interactions with outside forces and defines other properties