Prop data: Difference between revisions

Revision as of 11:04, 21 March 2006

The purpose of the Prop Data system is to ensure that the interactive behavior of prop models stays consistent across all the levels in your game / mod. The three core prop entities (prop_static, prop_dynamic, and prop_physics) all use the prop data system to load game-related data from the model they're set to use. This article will explain the data stored inside the Prop Data section of models, and how you can edit it in your mod.

Setting Up a Prop Model

Once you've built your prop model, you need to setup the prop data that should be enforced. Prop data is embedded into the $keyvalues section of the model's .QC file. First, you need to decide how the prop should be simulated. In HL2, we tried to follow these general rules:

If it's going to attach to, or act as a support for a non moving thing, it should be static.
If it generates light, it should be static.
If it's really big and the player can't possibly move it, it should be static.
Otherwise, it should be physically simulated.

If you want your prop to be static, then you're done. Any model without a prop data section in its $keyvalues section will be forced to be static. If a mapmaker places it as a prop_physics entity, it will be removed and a warning will be displayed.

If you want your prop to be physically simulated, then you need to add the $keyvalues section to the model's .QC file. If there is no existing $keyvalues section in the .qc, add the whole chunk. Otherwise just add the "prop_data" section at the end of the existing $keyvalues section. An example $keyvalues entry would be something like this:

$keyvalues
{
   "prop_data"
   {
       "base"              "Wooden.Small"
       "dmg.bullets"       "0"
       "explosive_damage"  "100"
       "explosive_radius"  "100"
   }
}

This example prop data entry tells the prop to derive all of its data from the base "Wooden.Small" entry in the propdata.txt file. It then overrides several variables, which make the prop immune to bullet damage and creates an explosion when it breaks. To find the base prop class to derive from for your prop, open up the mod/scripts/propdata.txt file and find the entry that best matches the prop you've built. Make sure you choose a "<material>.<size>" entry, not the "<material>.Base" entry that simply sets damage modifiers for the material type.

When building props, you can help your game / mod to be consistent by following these tips:

Don't override health levels in all your props. Instead, use the base prop classes and let them set the health. This way you won't have one chair that takes twice as much health as every other chair.
Whenever possible, avoid mixing material types inside the same prop. i.e. don't make half metal, half wood props.
Follow the HL2 rules unless you have good reason to change them: metal & plastic are invulnerable. Everything else breaks.
Avoid collecting multiple objects into the same prop, especially if we invidividually simulate identical looking objects elsewhere.
Avoid moving parts & materials we don't simulate. i.e. don't hang coats from a coat rack.

Breakables

The prop data system also handles generic breakable gibs. Generic gibs are used for any breakable object that doesn't have custom gibs. In general, custom gibs are far superior to generic ones, but of course, there's a limit to how many custom gibs you can fit into memory. To build custom gibs for your prop, read Creating Custom Breakable Gibs. Otherwise, read on.

The "breakable_model" entry in a prop's prop data defines a set of generic gib models to use, and the number of gibs produced is based on the "breakable_count" entry. Most of the breakable prop data base classes already define the breakable models they use, and the derived <material>.<size> classes define the amount. Additionally, the "breakable_skin" entry allows you to specify a skin to use on the breakable models, which is useful for matching the original prop's material to the generic gib's.

Generic gib sets are defined at the bottom of the mod/scripts/propdata.txt file, using the following format:

"BreakableModels"
{
    "gib set name"
    {
        "gib model"              "1"
        "gib model"              "1"
        "gib model"              "1"
        ...
    }

    "gib set name"
    ...
}

The "gib model" entries are the models to use (i.e. "models\Gibs\wood_gib01e.mdl"). They are listed in order of smallest to largest. The prop data system will attempt to fit, as best it can, generic gib models within the volume of the breaking object, based upon their size.

Physics Interactions

In addition to enforcing prop consistency, the prop data system can be used to turn on several discreet physics interactions for a prop. These are done by embedding KeyValue sections in the prop data section. HL2 provides interactions with the physcannon, and interactions with fire.

Physcannon interactions are set by placing the following section into your prop data section, using the following format:

   "prop_data"
   {
       ...

       "physgun_interactions"
       {
           "key"           "value"
           ...
       }
   }

The keys & their appropriate values are as follows:

"onworldimpact" "stick"

This prop will embed itself into the world if it hits it after being launched by the physcannon.

onfirstimpact"

<string> The behavior of this prop when it's launched by the physcannon and collides with something for the first time. Should be one of the following:

"break"

This prop should always break on colliding with anything after being launched.

"paintsplat"

This prop should apply paint decals to the first thing it collides with after being launched.

"impale"

This prop should impale whatever it first collides with after being launched. Not used in HL2, and hence unsupported at this time.

"onlaunch"

<string> The behavior of this prop when it's launched by the physcannon. Should be one of the following:

"spin_none"

This prop shouldn't spin when launched by the physcannon. By default, the physcannon applies random angular velocity to objects it launches. Use this to prevent that.

"spin_zaxis"

This prop should spin around the Z axis when launched by the physcannon.

"onbreak" "explode_fire"

This prop should ignite nearby enemies when it explodes on breaking.

"damage" "none"

This prop shouldn't move in response to damage. It will still take damage if the other prop data entries specify so, but it won't move due to the damage impact.

Fire interactions are set by placing the following section into your prop data section, using the following format:

   "prop_data"
   {
       ...

       "fire_interactions"
       {
           "key"           "value"
           ...
       }
   }

The keys & their appropriate values are as follows:

"ignite" "halfhealth"

This prop will ignite itself when its health falls below half its starting health.

"explosive_resist" "yes"

This sets a special behavior on the prop that reduces blast damage it takes. If the prop is about to take blast damage that would kill it, it will reduce the damage enough to not die, and then ignite itself instead.

"flammable" "yes"

This prop can be ignited by ignition damage (such as nearby fires & props marked with the "explode_fire" physcannon interaction. This was unused in HL2, and hence unsupported as this time.

Prototyping

When working on prototypes, or when you don't have modellers handy, it's useful to be able to work around the prop data system's enforcement. To do this, use the prop_physics_override and prop_dynamic_override entities instead of prop_physics and prop_dynamic. A prop_physics_override entity will not remove itself if it is assigned a model that wants to be static (i.e. has no "propdata" entry in its $keyvalues .QC section). It will also let the level designer to set a "health" on it.

The override entities allow you to temporarily use models incorrectly while prototyping, or waiting for a modeller to finish up a new model that has the properties you desire. It is highly recommended that you use Hammer's Entity Report feature to check each of your maps to ensure you have no override entities left when you ship them. Otherwise you may be shipping physics inconsistencies, and players are extremely quick to notice them (the orange bucket won't move when I shoot it on this level, but it did on the previous one).

Prop data: Difference between revisions

Revision as of 11:04, 21 March 2006

Contents

Setting Up a Prop Model

Breakables

Physics Interactions

Prototyping

See Also

Navigation menu

Prop data: Difference between revisions

Revision as of 11:04, 21 March 2006

Setting Up a Prop Model

Breakables

Physics Interactions

Prototyping

See Also

Navigation menu

Search