View source for Zh/Condition

{{npc tut:zh-cn}}
{{translate}}

'''条件'''是NPC用于记录一些关于地图的状态的{{L|flag|标签}}。条件主要是用于选择或插入修改{{L|NPC安排|schedule:zh-cn}}的，并且每次 <code>{{L|NPCThink()}}</code>都会提醒。
一些条件实例:

* ''"I can see an enemy"''//我可以看见一个敌人
* ''"I have taken some damage"''//我被打中了！
* ''"My weapon's clip is empty"''//我没子弹啦

The engine's set of shared conditions are usually supplemented by others specific to an NPC. For example, {{L|npc_antlion|antlions}} drown when in water, so they have a condition of their own that tells them ''"I am underwater"''.

{{tip|You can see a list of all conditions by searching in Visual Studio's 'Class View'.}}

{{note|By default there is a maximum of 256 conditions in any one game or mod. You can increase this number in <code>ai_condition.h</code>, but doing so will break older saved games and increase memory usage.}}

== Interrupt conditions ==

As well as being used when selecting a new {{L|schedule}}, conditions validate the current one by acting as "interrupts". Each schedule has an associated list of conditions that will cause it to exit if detected. When this happens, a new schedule is chosen.

For example, an NPC may be running a schedule to ''"Chase my enemy"''. This kind of schedule usually specifies the ''"I have chosen a new enemy"'' condition as an interrupt, because the NPC shouldn't keep chasing the old enemy if it has found a a newer, more important one.

== Adding new conditions ==

Conditions are normally enumerated inside the NPC class. For example, if our new NPC has a custom condition to reflect ''"I am hungry"'', our condition enum should look something like this:

<source lang=cpp>
enum 
{
	COND_MYNPC_HUNGRY = BaseClass::NEXT_CONDITION,
	NEXT_CONDITION
};
</source>

It's good practice to include the <code>NEXT_CONDITION</code> enum, so that NPCs derived from our NPC can use <code>BaseClass::NEXT_CONDITION</code> (as we do, on the first line) to declare their custom conditions without causing collisions with ours.

{{warning|If your condition enum ''isn't'' inside your class definition then you ''must'' choose a different, unique name for your "next condition" item.}}

Conditions must then be declared inside the NPC's <code>AI_BEGIN_CUSTOM_NPC</code> block. This is done through the <code>DECLARE_CONDITION</code> macro. For the above example, we'd use this line:

<source lang=cpp>
AI_BEGIN_CUSTOM_NPC( npc_custom, CNPC_Custom )
	DECLARE_CONDITION( COND_MYNPC_HUNGRY )
AI_END_CUSTOM_NPC()
</source>

== Condition functions ==

<code>{{L|CAI_BaseNPC}}</code> stores conditions as {{L|flag}}s in <code>m_Conditions</code>, but it should not be accessed directly. Instead, condition handling is done with these functions:

; <code>GatherConditions()</code>
: The primary entry point for condition generation, which is called every time the NPC thinks. {{note|Make sure you call <code>BaseClass::GatherConditions()</code> at the end!}}
;<code>SetCondition( {{L|int}} iCondition )</code>
;<code>ClearCondition( {{L|int}} iCondition )</code>
:Sets/clears a condition. Instead of passing an integer, you'll of course make use of your enum.
;<code>{{L|bool}} HasCondition( {{L|int}} iCondition )</code>
:True if the specified condition is currently set. Remember that conditions are thrown away and re-generated on every think.
;<code>BuildScheduleTestBits()</code>
:This function allows you to dynamically modify a schedule's interrupts at any time. It's useful for appending your custom NPC conditions to base NPC or shared schedules. See below for an example.

== Examples ==

===GatherConditions()===

Here's a slightly trimmed version of the {{L|npc_antlion|Antlion}}'s <code>GatherConditions()</code>. Antlions jump around a lot, and sometimes land on top of other NPCs. They need to know whether they've landed on an NPC when decision making, so they generate a condition when they have. Antlions also need to drown if they ever find themselves in water, so they set a condition when their water level reaches waist high.

<source lang=cpp>
void CNPC_Antlion::GatherConditions()
{
	BaseClass::GatherConditions();

	// See if I've landed on another NPC after jumping.
	CBaseEntity *pGroundEnt = GetGroundEntity();
	if ( pGroundEnt && pGroundEnt->GetSolidFlags() & FSOLID_NOT_STANDABLE && GetFlags() & FL_ONGROUND )
		SetCondition( COND_ANTLION_ON_NPC );
	else
		ClearCondition( COND_ANTLION_ON_NPC );

	// See if I've landed in water
	if( m_lifeState == LIFE_ALIVE && GetWaterLevel() > 1 )
		SetCondition( COND_ANTLION_IN_WATER );
}
</source>

The <code>else</code> statement uses <code>ClearCondition()</code> here because if the first <code>if</code> statement is true, then the boolean <code>COND_ANTLION_ON_NPC</code> is set to <code>True</code>. When this happens, another piece of code later on is fired, telling the antlion to get off the NPC's head, and hopefully, the antlion does not jump onto another NPC. Once it is no longer standing on an NPC, the condition goes back to being false, so it resumes normal activity.

<source lang=cpp>
//On another NPC's head?
if( HasCondition( COND_ANTLION_ON_NPC ) )
{
        // You're on an NPC's head. Get off.
        return SCHED_ANTLION_DISMOUNT_NPC;
}
</source>

===BuildScheduleTestBits()===

The {{L|Assaults|Assault behavior}} allows mappers to specify whether an NPC should divert from their path to fight new enemies or keep running. This kind of dynamic interrupt specification can't be done in the static schedule definitions, and is exactly what <code>BuildScheduleTestBits()</code> is designed for.

<source lang=cpp>
void CAI_AssaultBehavior::BuildScheduleTestBits()
{
	BaseClass::BuildScheduleTestBits();

	// If we're allowed to divert, add the appropriate interrupts to our movement schedules
	if ( m_hAssaultPoint && m_hAssaultPoint->m_bAllowDiversion )
	{
		if ( IsCurSchedule( SCHED_MOVE_TO_ASSAULT_POINT ) ||
			 IsCurSchedule( SCHED_MOVE_TO_RALLY_POINT ) || 
			 IsCurSchedule( SCHED_HOLD_RALLY_POINT ) )
		{
			GetOuter()->SetCustomInterruptCondition( COND_NEW_ENEMY );
			GetOuter()->SetCustomInterruptCondition( COND_SEE_ENEMY );
		}
	}
}
</source>

== See also ==

* {{L|Shared conditions}} - a list of conditions inherited by all NPCs
* {{L|State}} - records whether the NPC is idle, alert, in combat, etc.

{{navbar|Defining the NPC|Creating an NPC|Creating a schedule}}

[[Category:AI Programming]]