Prop physics: Difference between revisions
No edit summary |
mNo edit summary |
||
| Line 15: | Line 15: | ||
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. | 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 {{ent|prop_static}} or {{ent|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. | Models that are meant to be physically simulated (chairs, tables, wooden planks, etc) will remove themselves if they are placed as {{ent|prop_static}} or {{ent|prop_dynamic}} entities (You can still use these as static props using the entity {{ent|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. | 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. | ||
Revision as of 09:57, 17 July 2023
Template:Entity 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.
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 (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
Note:Page left for viewable history, content moved to prop_physicsNote: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_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_physicsNote: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