Prop physics

Class hierarchy
CPhysicsProp ↳CBreakableProp ↳CBaseProp ↳CBaseAnimating ↳CBaseEntity
props.cpp

prop_physics is a point entity available in all Source games. It is used to add rigid, VPhysics-simulated models to the world.

The only value required for prop_physics to work is a path to a model. As long as that model is physics-enabled, the correct data will be loaded from it when the map starts. It is possible to change any embedded physics data with the "Override Parameters" keyvalue.

Physics objects like prop_physics can be parented, though it is not in the default FGD and may not function correctly. It is recommended to instead use dynamic physics constraints. See Physics Entity Overview for more information.

Tip:Multiplayer maps should use prop_physics_multiplayer, which works better with the collision prediction code.
Do not use prop_physics_respawnable; it will crash the server if destroyed by a trigger_hurt.

Tip:To create a jointed physics object, use prop_ragdoll.

AltNames: This entity is also tied to physics_prop. The classname is always changed to prop_physics on spawn.

Consistency

Todo: Move this section to its own article.

Consistency becomes a large problem when dealing with the many prop models that the Source engine provides. From a player's perspective, object interactivity should remain consistent across all the levels of your game / mod, as players will often have a hard time solving puzzles or making quick decisions if the prop's behaviour is different in only one specific instance. To enforce this, the game-related data of props is stored within the model itself.

For example, imagine you have a crate that is immovable for the entirety of your game and the player has gotten used to that crate being static. However, in one specific instance, this crate is not moveable and required to be moved to proceed. This can cause lots of irritation and confusion, and therefore is why consistency is necessary. Oftentimes, developers will use different skins or models to convey differences in behaviour and keep consistency.

Models that are meant to be physically simulated (chairs, tables, wooden planks, etc) will remove themselves if they are placed as prop_static or prop_dynamic entities (You can still use these as static props using the entity prop_dynamic_override). Other game-related data, such as mass, "health", gib amount & models, and so on are all stored inside the prop model as well.

The method by which they are stored, and guidelines for how to set it up, can be found in the Prop Data section of the model's QC file.

Keyvalues

Name (targetname) <string>[ Edit ]

The name that other entities refer to this entity by, via Inputs/Outputs or other keyvalues (e.g. parentname or target).
Also displayed in Hammer's 2D views and Entity Report.

See also:  Generic Keyvalues, Inputs and Outputs available to all entities

Note:Page left for viewable history, content moved to prop_physics

Breakable by (BreakableType) <choices> (only in )

• 0: "Everyone"
• 1: "All Infected"
• 2: "Only Tanks"

Flags

Note:Page left for viewable history, content moved to prop_physics

Bug:In when breakable prop has Force server-side flag set then nav areas under it will be marked MOB_ONLY  [todo tested in ?]

Attempt to override gib with the character gib system : [4194304] (only in )

Inputs

Ignite

Ignite, burst into flames.

IgniteLifetime <floatRedirectInput/float>

Ignite with the given lifetime.

Todo: Before the flames extinguish, or before health reaches zero?

IgniteNumHitboxFires <integerRedirectInput/integer>

Ignite with the given number of hitbox fires.

IgniteHitboxFireScale <floatRedirectInput/float>

Ignite with the given hitbox fire scale.

Note:Page left for viewable history, content moved to prop_physics

Outputs

Note:Page left for viewable history, content moved to prop_physics

See also

• prop_data
• Prop Types Overview
  • prop_physics_multiplayer
  • prop_physics_respawnable
  • prop_physics_override
  • prop_sphere
  • prop_dynamic
  • prop_static
  • prop_ragdoll