Prop physics: Difference between revisions
m (Added lang and update formatting.) |
Kestrelguy (talk | contribs) (updated templates used.) |
||
| Line 5: | Line 5: | ||
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. | ||
Physics objects like prop_physics can be [[Parent|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. | Physics objects like <code>prop_physics</code> can be [[Parent|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 {{ent|prop_physics_multiplayer}} or {{ent|prop_physics_respawnable}}. To create a jointed physics object, use {{ent|prop_ragdoll}}.}} | {{tip|Multiplayer maps should use {{ent|prop_physics_multiplayer}} or {{ent|prop_physics_respawnable}}. To create a jointed physics object, use {{ent|prop_ragdoll}}.}} | ||
| Line 16: | Line 16: | ||
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 | 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. | ||
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. | ||
== Keyvalues == | == Keyvalues == | ||
{{KV BasePropPhysics}} | {{KV BasePropPhysics}} | ||
{{KV | {{KV BaseAnimating}} | ||
{{KV BaseEntity}} | |||
== Flags == | == Flags == | ||
| Line 43: | Line 34: | ||
{{IO|IgniteHitboxFireScale|<code>Ignite</code> with the given hitbox fire scale.|param=float}} | {{IO|IgniteHitboxFireScale|<code>Ignite</code> with the given hitbox fire scale.|param=float}} | ||
{{I BasePropPhysics}} | {{I BasePropPhysics}} | ||
{{I | {{I BaseAnimating}} | ||
{{I BaseEntity}} | |||
== Outputs == | == Outputs == | ||
{{O BasePropPhysics}} | {{O BasePropPhysics|portal2=1|l4d2=1}} | ||
{{O BaseEntity|l4d=1}} | |||
== See Also == | |||
* {{ent|prop_data}} | |||
* [[Prop Types Overview]] | |||
** {{ent|prop_physics_multiplayer}} | |||
** {{ent|prop_physics_respawnable}} | |||
** {{ent|prop_physics_override}} | |||
** {{ent|prop_dynamic}} | |||
** {{ent|prop_static}} | |||
** {{ent|prop_ragdoll}} | |||
[[Category:Physics]] | [[Category:Physics]] | ||
Revision as of 11:12, 4 May 2022
Template:Base point 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. 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