Ru/Prop data

prop_data могут быть использованы, чтобы создавать модели:

• Физические (по умолчанию, модели с prop_data не могут быть статикой)
• Разбиваемые (с гибсами)
• Поджигаемые
• Взрывающиеся

Их блок KeyValues встроен с помощью QC-команды $keyvalues.

Примечание:Свойства поверхности модели определяются $surfaceprop.

Примечание:Моделям, используемым как физика, будет необходим $staticprop.

Пример

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

Здесь мы получаем prop_data из стандартного base_type "Wooden.Small". Затем берём дополнительные ключевые значения, чтобы дать модели три специальные характеристики: она будет пуленепробиваемой, но когда взорвётся, нанесет ущерб до 100 сущностям в радиусе 50 единиц.

Советы

Вам не нужно что-либо переопределять

Просто установите base, и она будет работать как физический объект.

Не переопределяет уровни здоровья у ваших пропов

Вместо этого, пусть здоровье будет настроено по-умолчанию. Таким образом, один стул не получит вдвое больший урон, чем другой стул.

Всегда, когда это возможно, избегайте смешивания типов материалов внутри одного пропа

Не создавайте полуметаллические, полудеревянные пропы.

Избегайте скопления нескольких объектов в одном пропе

Особенно, если вы или Valve по отдельности смоделировали идентичные объекты в разных местах.

Избегайте движущихся частей или материалов, которые Source не моделирует

Не помещайте воду в физический аквариум.

Должна ли моя модель быть физической?

В Half-Life 2, Valve старается следовать этим общим правилам:

Если модель прикреплена к не-физической вещи или поддерживает её...

То должна быть статикой.

Если генерирует статичный свет...

То должна быть статикой.

Если она настолько велика, что игрок не может двигать её...

То должна быть статикой.

В остальном...

Она должна быть физикой.

Кроме того Valve рассматривает металл и пластик как неуязвимые, но всё же разбиваемые материалы.

Свойства

Тип основы

base <string>

Даёт модели предопределенный тип prop_data, обеспечивая одним движением все данные, необходимые движку, чтобы создать модель одновременно и физической и разбиваемой. Большинство других команд в блоке prop_data переопределяют значения, унаследованные отсюда.

Общие

health <int>

Количество повреждений, которые объект должен принять до момента разбивания. 0 означает, что не ломается.

allowstatic <bool>

Позволяет использовать модель как статику. Для обеспечения согласованности, избегайте по возможности.

physicsmode <choices>

Задает режим физики, используемый в prop_physics_multiplayer. Может быть переопределен сущностью в Orange Box.

• Твердый, отталкивает игрока.
• Не-твердый, но отталкивается игроком.
• Не-твердый, моделируется только на стороне клиента.

blockLOS <bool>

Определяет, блокирует ли он линию взгляда NPC. Если не указано, движок игры будет принимать решение на основе размеров модели.

AIWalkable <bool>

Должны ли боты ходить по этому объекту? Template:Todo:ru

Модификаторы урона

Use damage modifiers to reflect differences between the amount of damage that an object takes from different attacks. Don't use them to reflect overall damage strength. (e.g. Stone is resilient to everything. To reflect this, increase the health of all stone objects, don't set the damage modifiers lower.)

dmg.bullets <float>

Modifies damage done by bullets.

• Paper, Cloth and Glass = 0.5
• Wood = 0.75
• Flesh = 1.25.

dmg.club <float>

Modifies damage done by blunt impacts.

• Cloth = 0.75
• Paper and Pottery = 1.25
• Wood = 2.0

dmg.explosive <float>

Modifies damage done by explosions.

• Paper, Cloth, Pottery, Flesh and Wood = 1.5

damage_table <choices>

Impact Damage Tables are defined in C++ code (in physics_impact_damage.cpp), and contain very detailed information about what damage a prop should take from different directions and forces. Only Glass and Pottery base_types inherit one.

Совет:Use damage_table "" to ignore an inherited table.

glass

Extremely fragile, will break just by being dropped.

player

^{[Нужно сделать]}

player_vehicle

^{[Нужно сделать]}

npc

^{[Нужно сделать]}

Flammable props

fire_interactions is a subkey of prop_data that defines flammability. There are only three known parameters, each with only one known value:

$keyvalues
{
   prop_data
   {
      fire_interactions
      {
         ignite      halfhealth 	// Will ignite spontaneously on reaching 50% health.
         explosive_resist   yes 	// Clamp blast damage so that the prop ignites instead of breaking.
         flammable          yes 	// Can be ignited by fire and explosions.
      }
    }
}

• Примечание:fire_interactions may not function while within the prop_data section. Move it just below the prop_data section if you encounter problems
• Нужно сделать: confirm that fire_interactions are not used for flammable NPC models.
• Нужно сделать: confirm whether unbreakable (health 0) models can be flammable.

Exploding props

If these two fields are specified for a prop, and it is given health so that it can be damaged, then it will explode when it breaks.

explosive_damage <float>

The amount of explosive damage.

explosive_radius <float>

The radius of the explosion. Damage falls off as distance from the origin increases.

Gibs

The prop_data system handles generic gibs. Generic gibs are used for any breakable object that doesn't have custom gibs.

breakable_model <choices>

Defines the set of generic gibs (as defined in scripts\propdata.txt) this prop should break into. Props with a wooden base type gib in this manner already. See also creating custom gibs.

• WoodChunks
• GlassChunks
• ConcreteChunks
• MetalChunks

breakable_count <int>

The number of generic breakable gibs to break into. If this is not specified, the engine will generate a sensible number based on the gibs' and model's sizes.

breakable_skin <int>

Allows you to specify a skin to use on the gib models, which is useful for matching the original prop's skin.

Only props with Wooden base_types inherit a gib skin (skin 0).

multiplayer_break <choices>

Подтвердить:Determines where the gibs from a prop_physics_multiplayer are simulated.

• both
• server
• client (default)

• Нужно сделать: Confirm whether breakable_count, breakable_skin and multiplayer_break do not affect custom gibs.
• Нужно сделать: Confirm whether multiplayer_break is set for the breakable model rather than each individual gib itself.

Creating new base types

All base types are defined in scripts\propdata.txt. If you edit a base type in this file, you will affect the behaviour of all models using it (that do not have their own overrides).

The format of the file is:

PropData.txt
{
	<base type name>
	{
		<any number of the prop_data KVs listed above>
	}
}

Valve generally only use their base types to set health and damage modifiers.

Creating generic gibs

Generic gibsets are also defined in propdata.txt. Valve have only four, and only one (WoodChunks) is assigned to a base type - most models instead specify theirs directly, with breakable_model.

Defining a new gibset is easy as most of the work is done by the engine:

PropData.txt
{
	BreakableModels
	{
		WoodChunks
		{
			// Smallest to largest:
			models\Gibs\wood_gib01e.mdl	1
			models\Gibs\wood_gib01d.mdl	1
			models\Gibs\wood_gib01c.mdl	1
			models\Gibs\wood_gib01b.mdl	1
			models\Gibs\wood_gib01a.mdl	1
		}
	}
}

Prototyping models

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 "prop_data" entry in its $keyvalues .QC section). It will also allow the level designer to set its "health".

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).

See also func_physbox for brush-based physics objects.

See also

• prop_data base types
• prop_static, prop_dynamic, prop_physics - common prop entities.
• Prop Types Overview - an article describing various prop types.
• physgun interactions - another QC $keyvalues block that defines some special interactions between prop_physics models and the physcannon.