Prop physics: Difference between revisions
mNo edit summary |
Robin Walker (talk | contribs) (Added propdata. Page should be updated with the entity template.) |
||
| Line 1: | Line 1: | ||
{{wrongtitle|title=prop_physics}} | {{wrongtitle|title=prop_physics}} | ||
==Entity Description== | ==Entity Description== | ||
A '''prop_physics''' is an entity which, when placed in a map and set with a model, creates a physics object. Physics objects can be picked up with the grav gun, according to their weight, and fully interact with their world in terms of collision, gravity, and world effects. If you have played a source game in any form you have definitely seen one in action. Additional settings in the entity include a multiplayer 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), and additionally flagged to allow or disallow gravity gun pickup, etc. | A '''prop_physics''' is an entity which, when placed in a map and set with a model, creates a physics object. Physics objects can be picked up with the grav gun, according to their weight, and fully interact with their world in terms of collision, gravity, and world effects. If you have played a source game in any form you have definitely seen one in action. Additional settings in the entity include a multiplayer 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), and additionally flagged to allow or disallow gravity gun pickup, etc. | ||
If you are creating a multiplayer map, you should 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 strongly as a [[prop_physics_multiplayer]], try making it a [[prop_physics]]. | If you are creating a multiplayer map, you should 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 strongly as a [[prop_physics_multiplayer]], try making it a [[prop_physics]]. | ||
If you are making a multiplayer map and want your breakable objects to come back after a while, use a [[prop_physics_respawnable]]. | If you are making a multiplayer map and want your breakable objects to come back after a while, use a [[prop_physics_respawnable]]. | ||
==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. | |||
---- | ---- | ||
===See Also=== | ===See Also=== | ||
[[Prop Data]] | |||
[[List of entities]] | [[List of entities]] | ||
[[Overview of Prop Types - Description of the various model prop entities.|Overview of Prop Types]] | [[Overview of Prop Types - Description of the various model prop entities.|Overview of Prop Types]] | ||
[[Category:Entities]] | |||
Revision as of 11:57, 14 July 2005
Entity Description
A prop_physics is an entity which, when placed in a map and set with a model, creates a physics object. Physics objects can be picked up with the grav gun, according to their weight, and fully interact with their world in terms of collision, gravity, and world effects. If you have played a source game in any form you have definitely seen one in action. Additional settings in the entity include a multiplayer 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), and additionally flagged to allow or disallow gravity gun pickup, etc.
If you are creating a multiplayer map, you should 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 strongly as a prop_physics_multiplayer, try making it a prop_physics.
If you are making a multiplayer map and want your breakable objects to come back after a while, use a prop_physics_respawnable.
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.