prop_physics
 Class hierarchy
|
|---|
| CPhysicsProp |
| props.cpp
|
prop_physics is an e0 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
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.
parentnameortarget).
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 <float>
Ignitewith the given lifetime.Todo: Before the flames extinguish, or before health reaches zero?
- IgniteNumHitboxFires <integer>
Ignitewith the given number of hitbox fires.
- IgniteHitboxFireScale <float>
Ignitewith the given hitbox fire scale.
Note:Page left for viewable history, content moved to prop_physicsOutputs
Note:Page left for viewable history, content moved to prop_physics