Prop physics: Difference between revisions
SirYodaJedi (talk | contribs) (Don't recommend prop_physics_respawnable; it can crash the server) |
SirYodaJedi (talk | contribs) mNo edit summary |
||
Line 7: | Line 7: | ||
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. | 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}}. To create a jointed physics object, use {{ent|prop_ragdoll}}.}} | {{tip|Multiplayer maps should use {{ent|prop_physics_multiplayer}}, which works better with the collision prediction code.<br>Do not use {{ent|prop_physics_respawnable}}; it will crash the server if destroyed by a trigger_hurt.}} | ||
{{tip|To create a jointed physics object, use {{ent|prop_ragdoll}}.}} | |||
{{altnames|name1=physics_prop|misc=The classname is always changed to {{ent|prop_physics}} on spawn.}} | {{altnames|name1=physics_prop|misc=The classname is always changed to {{ent|prop_physics}} on spawn.}} |
Revision as of 14:24, 3 September 2023
![]() |
---|
CPhysicsProp |
![]() |
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.

Do not use prop_physics_respawnable; it will crash the server if destroyed by a trigger_hurt.


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


Flags

Inputs
- Ignite
- Ignite, burst into flames.
- IgniteLifetime <float >
Ignite
with the given lifetime.Todo: Before the flames extinguish, or before health reaches zero?
- IgniteNumHitboxFires <integer >
Ignite
with the given number of hitbox fires.
- IgniteHitboxFireScale <float >
Ignite
with the given hitbox fire scale.


Outputs
