Prop physics: Difference between revisions
| Kestrelguy (talk | contribs)  (updated templates used.) | mNo edit summary | ||
| Line 1: | Line 1: | ||
| {{toc-right}} | {{toc-right}} | ||
| {{ | {{point ent|prop_physics|type=e0}} It is used to add rigid, [[VPhysics]]-simulated [[model]]s to the world. | ||
| The only value required for prop_physics to work is a path to a model. As long as that model is [[prop_data|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. | The only value required for prop_physics to work is a path to a model. As long as that model is [[prop_data|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. | ||
Revision as of 05:22, 30 December 2022
Template:Point ent 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 or prop_physics_respawnable. To create a jointed physics object, use prop_ragdoll.
Tip:Multiplayer maps should use prop_physics_multiplayer or prop_physics_respawnable. To create a jointed physics object, use prop_ragdoll. AltNames: This entity is also tied to
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. (Why? Shouldn't the level designer have control over this, dependent on the context of the prop's use?) 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 of the model's QC file.
Keyvalues
 Note:Page left for viewable history, content moved to prop_physics
Note:Page left for viewable history, content moved to prop_physics Note:Content moved to Rendering and studio model related KIO/Keyvalues for continuation of page history
Note:Content moved to Rendering and studio model related KIO/Keyvalues for continuation of page history
Flags
 Note:Page left for viewable history, content moved to prop_physics
Note:Page left for viewable history, content moved to prop_physicsInputs
- 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_physics
Note:Page left for viewable history, content moved to prop_physics Note:Content moved to Rendering and studio model related KIO/Inputs for continuation of page history
Note:Content moved to Rendering and studio model related KIO/Inputs for continuation of page history
Outputs
 Note:Page left for viewable history, content moved to prop_physics
Note:Page left for viewable history, content moved to prop_physics