Prop physics
Entity Description
An entity which, when placed in a map and set with a model, creates a prop which is influenced by the engine physics, meaning they can fully interact with their world in terms of collision, gravity, constraints, and world effects. If you have played a Source game in any form you have definitely seen one in action. (These were the objects you could move or pick up, by hand or by using the grav gun, according to their weight.)
Additional settings in the entity include a multiplier for weight, name field for I/O interactions, damage type (sharp or blunt), etc. Entities can be flagged to start motion disabled (think saw-blades), allow or disallow gravity gun pickup, be configured to break when it takes enough damage, etc.
Alternative entities
If you are creating a multiplayer map, you should instead use a prop_physics_multiplayer for most objects instead of a prop_physics. Prop_physics is ideal for single-player maps, where accuracy of interactions has no network overhead to worry about. The detail going into the interaction between objects in multiplayer results in an undesirably large network overhead and thus requires the detail of the interactive aspects of the objects be simplified. To solve this, Valve created prop_physics_multiplayer, which uses a much simpler structure of the model to do physics interactions, resulting in much better network play. Extremely simple models (simple being anything "boxy" [computer cases, keyboards, small jars, etc.]) will not have prop_physics_multiplayer settings, but this is fine because those models are so simple that making them prop_physics will not have an adverse effect on network traffic. If you are having a problem in a multiplayer map with a small object that is behaving strangely as a prop_physics_multiplayer, try making it a prop_physics.
If you are mapping for Half-Life 2: Deathmatch and want your breakable objects to come back after a while, use a prop_physics_respawnable instead.
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. To enforce this, the game-related data of props is stored within the model itself. 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. 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.
Keyvalues
Flags
- Should force breakable models to have pieces break on the server?
Inputs
- Break
- Breaks the breakable completely. This will make the entity act like a normal func_breakable. If you wish to maintain the shattering behaviour/appearance, consider using the Shatter input below with a large radius value.
- SetHealth <integer>
- Sets a new value for the breakable's health. If the breakable's health reaches zero it will break.
- AddHealth <integer>
- Adds health to the breakable. If the breakable's health reaches zero it will break.
- RemoveHealth <integer>
- Removes health from the breakable. If the breakable's health reaches zero it will break.
- EnablePhyscannonPickup
- Makes the breakable able to picked up by the physcannon.
- DisablePhyscannonPickup
- Makes the breakable not able to picked up by the physcannon.
- Ignite
- Ignite the target entity.
Outputs
- OnBreak
- OnHealthChanged
- OnIgnite
- OnPhysCannonDetach
- Template:O basepropphysics
See also
- Prop Data
- Prop Types Overview - Description of the various model prop entities.
- Prop Footsteps - A tutorial that provides essential code for when players walk on entities like this, it's not ignored during footstep sound computation.