Difference between revisions of "Prop data"

From Valve Developer Community
Jump to: navigation, search
m (also a qc command)
m
 
(42 intermediate revisions by 10 users not shown)
Line 1: Line 1:
<div style="float:right;padding:0 1em;background:#FFF;">__TOC__</div>
+
{{otherlang2
 +
|title=prop_data
 +
| jp = Prop data:jp
 +
|ru=Prop data:ru
 +
}}
  
Every model that is to be used by [[prop_physic]]s (and some that are to be used by [[prop_dynamic]]) must have a '''<code>prop_data</code>''' block. The block is embedded with the QC command <code>[[$keyvalues]]</code>.
+
{{toc-right}}
  
<code>prop_data</code> co-exists with, but is distinct from, <code>[[$surfaceprop]]</code>.
+
'''<code>prop_data</code>''' can be used to make a model:
  
{{note|By default, models with <code>prop_data</code> '''cannot be [[prop_static]]'''.}}
+
* [[#Options|Physical]] (by default models with <code>prop_data</code> cannot be [[prop_static|static]])
 +
* [[#Damage modifiers|Breakable]] (with [[#Gibs|gibs]])
 +
* [[#Flammable props|Flammable]]
 +
* [[#Exploding props|Explosive]]
  
== Should my model be physical? ==
+
It is a [[KeyValues]] block embedded with the QC command <code>[[$keyvalues]]</code>.
  
In Half-Life 2, Valve tried to follow these general rules:
+
{{note|The properties of a model's ''surface'' are defined by <code>[[$surfaceprop]]</code>.}}
 +
{{note|Models for use with [[prop_physics]] will also need <code>[[$staticprop]]</code>.}}
  
;If it's going to attach to or act as a support for a non-moving thing...
+
== Example ==
:It should be static.
 
;If it generates 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.
 
 
 
== Simple example ==
 
  
 
  [[$keyvalues]]
 
  [[$keyvalues]]
Line 26: Line 25:
 
  prop_data
 
  prop_data
 
  {
 
  {
  base Wooden.Small ''// Inherit properties from this [[propdata.txt]] template''
+
  base Wooden.Small  
+
  dmg.bullets 0  
''// We now override some of Wooden.Small's KVs:''
+
  explosive_damage 100
  dmg.bullets 0 ''// Take no damage from bullets''
+
  explosive_radius 50  
  explosive_damage 100 ''// Explode on break; deal 100 damage''
 
  explosive_radius 50 ''// Explode on break; explosion radius is 50 units''
 
 
  }
 
  }
 
  }
 
  }
+
 
 +
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==
 
==Tips==
  
Line 40: Line 39:
 
:Just set a <code>base</code> and you've got a working physics prop.
 
:Just set a <code>base</code> and you've got a working physics prop.
 
;Don't override health levels in all your props
 
;Don't override health levels in all your props
:Instead, use the base prop classes and let them set the health. This way you won't have one chair that takes twice as much damage as every other chair.
+
: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
 
;Whenever possible, avoid mixing material types inside the same prop
 
:Don't make half-metal, half-wood props.
 
:Don't make half-metal, half-wood props.
;Follow Valve's rules above unless you have good reason to change them
 
:In addition: Valve consider metal and plastic invulnerable, but everything else breakable.
 
 
;Avoid collecting multiple objects into the same prop
 
;Avoid collecting multiple objects into the same prop
 
:Especially if you or Valve individually simulate identical-looking objects elsewhere.
 
:Especially if you or Valve individually simulate identical-looking objects elsewhere.
 
;Avoid moving parts and materials Source doesn't simulate
 
;Avoid moving parts and materials Source doesn't simulate
:Don't hang coats from a coat rack or put water in a physical fish tank.
+
: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 ==
 
== Options ==
 +
 +
=== Base type ===
 +
 +
; <code>base <[[string]]></code>
 +
: Gives the model a [[prop_data base types|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===
 
===General===
  
; <code>base</code> <[[prop_data_base_material_guidelines|choices]]> : Defines the physical properties of the prop, according to the material from which it is made. '''''All other keyvalues override those inherited from this!'''''
+
; <code>health <[[int]]></code>
:See [[prop_data base material guidelines]] for a list of Valve's stock prop_data types.
+
: The amount of damage this prop should take before breaking. 0 means don't break.
; <code>health</code> <integer> : The amount of damage this prop should take before breaking. If 0 or null, it cannot be destroyed.
+
; <code>allowstatic <[[bool]]></code>
; <code>allowstatic</code> <[[boolean]]> : Allow this model to be [[prop_static]] as well as [[prop_physics]]. For consistency, avoid using this.
+
: Allows the model to be used with [[prop_static]]. To enforce consistency, avoid if possible.
; <code>physicsmode</code> <[[physicsmode choices|choices]]> : Sets the physics mode used by [[prop_physics_multiplayer]].  
+
; <code>physicsmode <choices></code>
{{physicsmode choices}}
+
: Sets the physics mode used by [[prop_physics_multiplayer]]. Can be overridden by the entity in the Orange Box.
: {{ep2 add|The model's physicsmode may be overriden the [[prop_physics_multiplayer]] entity properties.}}
+
{{physicsmode choices}}
; <code>blockLOS</code> <[[boolean]]> : Overrides whether the prop should block NPC [[LOS|Line of Sight]]. If unspecified, the game engine will decide based on the model's dimensions.  
+
; <code>blockLOS <bool></code>
; <code>AIWalkable</code> <[[boolean]]> : Set whether AI should try walking over this prop. {{todo|Does the prop type matter?}}
+
: Overrides whether the prop should block NPC [[line of sight]]. If unspecified, the game engine will decide based on the model's dimensions.  
 +
; <code>AIWalkable <bool></code>
 +
: Should NPCs try walking over this prop? {{todo|Does prop type matter?}}
  
 
=== Damage modifiers ===
 
=== 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.)''
+
''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.)''
  
; <code>dmg.bullets</code> <float> : Modifies damage done by bullets. Default is 1.0
+
; <code>dmg.bullets</code> <float> : Modifies damage done by bullets.
:*Paper, Cloth and Glass Window = 0.5
+
:* Paper, Cloth and Glass = 0.5
:*Wood = 0.75
+
:* Wood = 0.75
:*Flesh = 1.25.
+
:* Flesh = 1.25.
; <code>dmg.club</code> <float> : Modifies damage done by blunt impacts. Default is 1.0
+
; <code>dmg.club</code> <float> : Modifies damage done by blunt impacts.
:*Cloth = 0.75
+
:* Cloth = 0.75
:*Paper and Pottery = 1.25
+
:* Paper and Pottery = 1.25
:*Wood = 2.0
+
:* Wood = 2.0
; <code>dmg.explosive</code> <float> : Modifies damage done by explosions. Default is 1.0
+
; <code>dmg.explosive</code> <float> : Modifies damage done by explosions.
:*Paper, Cloth, Pottery, Flesh and Wood = 1.5
+
:* Paper, Cloth, Pottery, Flesh and Wood = 1.5
; <code>damage_table</code> <[[damage_table choices|choices]]> : A [[damage_table choices|Damage Table]] is defined by a programmer (in physics_impact_damage.cpp), and contains very detailed information about what damage a prop should take from different directions and forces. Only Glass and Pottery props inherit one; the others are used per-entity in C++ code.
+
; <code>damage_table</code> <choices>
:{{tip|Use <code> damage_table "" </code> to ignore an inherited table.}}
+
: [[Impact Damage Table]]s 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 <code> damage_table "" </code> to ignore an inherited table.}}
{{damage_table choices}}  
+
:; <code>glass</code>
 +
:: Extremely fragile, will break just by being dropped.
 +
:; <code>player</code>
 +
:: {{todo}}
 +
:; <code>player_vehicle</code>
 +
:: {{todo}}
 +
:; <code>npc</code>
 +
:: {{todo}}
  
 
=== Flammable props ===
 
=== Flammable props ===
  
'''fire_interactions''' is a sub-set of the prop_data $keyvalues that defines flammability. There are only three known parameters, each with only one known value:
+
See [[Prop interactions#Fire interactions|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.''
 +
 
 +
; <code>explosive_damage <float></code>
 +
: The amount of explosive damage.
 +
; <code>explosive_radius <float></code>
 +
: The radius of the explosion. Damage falls off as distance from the origin increases.
  
[[$keyvalues]]
+
''See the "explode_fire" [[Prop interactions|prop interaction]] for explosions that only ignite entities''
{
 
prop_data
 
{
 
fire_interactions
 
{
 
'''ignite''' halfhealth ''// Will ignite 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''
 
}
 
}
 
}
 
  
=== Exploding props ===
+
=== Interactions ===
  
If these two fields are specified for a prop, then the prop will create an explosion with the specified values when it breaks.
+
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.
  
[[$keyvalues]]
+
Read more about them [[Prop interactions|here]].
{
 
prop_data
 
{
 
health 1 // health must be >0 for the prop to be breakable.  
 
'''explosive_damage <float>''' // The amount of explosive damage done by this prop when it breaks.
 
'''explosive_radius <float>''' // The radius of the explosion caused by this prop when it breaks.
 
}
 
}
 
  
 
=== Gibs ===
 
=== Gibs ===
  
The prop_data system handles generic [[Wikipedia:Gibs|gibs]]. Generic gibs are used for any breakable object that doesn't have [[Creating Custom Breakable Gibs|custom gibs]]. Custom gibs are assigned to a model using the [[$collisiontext]] QC command.
+
''The prop_data system handles generic [[Wikipedia:Gibs|gibs]]. Generic gibs are used for any breakable object that doesn't have [[Creating Custom Breakable Gibs|custom gibs]].''
  
; breakable_model <[[breakable_model choices|choices]]> : Defines the set of generic gibs this prop should break into.  
+
; <code>breakable_model <choices></code>
:{{breakable_model choices}}
+
: Defines the set of generic gibs (as defined in <code>scripts\propdata.txt</code>) this prop should break into. Props with a wooden base type gib in this manner already. See also [[Creating Custom Breakable Gibs|creating custom gibs]].
: Only props with the Wood "base class" inherit a gibset (WoodChunks).
+
:* <code>WoodChunks</code>
: This is only necessary if the prop doesn't have [[Creating Custom Breakable Gibs|custom gibs]]. In general custom gibs are far superior to generic ones, but of course, there's a limit to how many custom gibs you can fit into memory.
+
:* <code>GlassChunks</code>
: Generic Gibsets are defined at the bottom of <code>mod/scripts/propdata.txt</code>.
+
:* <code>ConcreteChunks</code>
; breakable_count <integer> : The number of generic breakable gibs to break into. Required for gibs to appear.
+
:* <code>MetalChunks</code>
: This allows you to hard-code the number gibs yourself. By default the game engine will attempt to attribute a sensible number of generic gib models within the volume of the breaking object, based upon their (and its) size.
+
; <code>breakable_count <int></code>
: Only props with the Wood "base class" inherit a gib count - ranging from Wood.Tiny = 0 through to Wood.Huge =10.
+
: 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 <integer> : The skin to use on the generic breakable models.
+
; <code>breakable_skin <int></code>
: Allows you to specify a skin to use on the gib models, which is useful for matching the original prop's material.
+
: 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 the Wood "base class" inherit a gib skin (skin 0).
+
: Only props with Wooden base_types inherit a gib skin (skin 0).
; multiplayer_break <[[multiplayer_break choices|choices]]> : Determines whether the gibs from a [[prop_physics_multiplayer]] are simulated on the Client or Server or both.  
+
; <code>multiplayer_break <choices></code>
: {{multiplayer_break choices}}
+
: {{confirm|Determines where the gibs from a [[prop_physics_multiplayer]] are simulated.}}
: Usually small gibs have no significant collision effect that might influence in-game events, so these are handled clientside rather than using up client-server connection bandwidth.
+
:* <code>both</code>
: {{todo|confirm that multiplayer_break is set for the breakable model rather than each individual gib itself.}}
+
:* <code>server</code>
 +
:* <code>client</code> (default)
  
== Prototyping models ==
+
* {{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 <code>scripts\propdata.txt</code>. 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:
 +
 
 +
<source lang=cpp>
 +
PropData.txt
 +
{
 +
<base type name>
 +
{
 +
<any number of the prop_data KVs listed above>
 +
}
 +
}
 +
</source>
 +
 
 +
Valve generally only use their base types to set health and damage modifiers.
 +
 
 +
=== Creating generic gibs ===
  
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 <code>$keyvalues</code> .[[qc|QC]] section). It will also allow the level designer to set its "health".
+
Generic gibsets are also defined in propdata.txt. Valve have only four, and only one (<code>WoodChunks</code>) is assigned to a base type - most models instead specify theirs directly, with <code>breakable_model</code>.
  
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 [[Hammer Entity Report Dialog|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).
+
Defining a new gibset is easy as most of the work is done by the engine:
  
== propdata.txt ==
+
<source lang=cpp>
 +
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
 +
}
 +
}
 +
}
 +
</source>
  
The purpose of the '''Prop Data''' system is to ensure that the interactive behavior of prop models stays consistent across all the levels in your game / mod. The three core prop entities ([[prop_static]], [[prop_dynamic]], and [[prop_physics]]) all use the prop data system to load game-related data from the model they're set to use. This section will explain how you can edit it in your mod.
+
== Prototyping models ==
  
The Prop Data system stores data hierarchically. The prop_data base classes are defined inside the <code>mod\scripts\propdata.txt</code> file. Wherever possible, models use one of these classes instead of defining their own class. This ensures a reasonable level of consistency in physics with models, and makes it easier to apply tweaks to the entire set of prop models without having to recompile each mdl. For example, in response to Half-Life 2 playtests, Valve tweaked the overall amount of health for all wooden objects in the game several times.
+
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 <code>$keyvalues</code> .[[qc|QC]] section). It will also allow the level designer to set its "health".
  
The <code>propdata.txt</code> format is a KeyValue formatted data file, where each entry matches the following format:
+
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 [[Hammer Entity Report Dialog|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).
  
<material_type>.<size_description> // Suggested format; you can actually call it anything you like (but avoid spaces)
+
See also [[func_physbox]] for brush-based physics objects.
{
 
key "value x or y" // If there is a space or tab character within a key or value, you need quote marks around it
 
(...)
 
}
 
  
 
== See also ==
 
== See also ==
 +
 +
* [[prop_data base types]]
 
* [[prop_static]], [[prop_dynamic]], [[prop_physics]] - common prop entities.
 
* [[prop_static]], [[prop_dynamic]], [[prop_physics]] - common prop entities.
 
* [[Prop Types Overview]] - an article describing various prop types.
 
* [[Prop Types Overview]] - an article describing various prop types.
* [[physgun interactions]] - another QC $keyvalues block that defines some special interactions between [[prop_physics]] models and the [[physcannon]].
+
* [[Prop interactions]] - a group of QC $keyvalues blocks that handles some interactions with outside forces and defines other properties
 
 
{{otherlang:en}}
 
{{otherlang:en:jp|Prop data:jp}}
 
  
[[Category:Level Design]]
 
 
[[Category:Modeling]]
 
[[Category:Modeling]]
 
[[Category:QC Keyvalues]]
 
[[Category:QC Keyvalues]]

Latest revision as of 22:23, 22 February 2018

Русский 日本語

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.

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. 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.
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? 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.
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
To do
player_vehicle
To do
npc
To do

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)
  • 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:

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 (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