Condition: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
m (recategorize)
m (clean up)
Line 1: Line 1:
[[Category:AI Programming]]
[[Category:AI Programming]]
Multiple conditions can be set on an NPC which help the NPC determine what schedule should be run (handled in <code>SelectSchedule()</code> or variants).
Multiple conditions can be set on an NPC which help the NPC determine what schedule should be run (handled in <code>SelectSchedule()</code> or variants).


An example of a condition is <code>COND_LIGHT_DAMAGE</code> which may cause the NPC to go to an alert state and select a schedule appropriate to this condition.
An example of a condition is <code>COND_LIGHT_DAMAGE</code> which may cause the NPC to go to an alert state and select a schedule appropriate to this condition.


NPC's can implement their own custom conditions to deal with things unique to that NPC, for instance, you could use a <code>COND_ON_FIRE</code> to determine if the NPC is on fire and select specific schedules on this condition such as <code>SCHED_JUMP_IN_WATER</code>.
NPC's can implement their own custom conditions to deal with things unique to that NPC, for instance, you could use a <code>COND_ON_FIRE</code> to determine if the NPC is on fire and select specific schedules on this condition such as <code>SCHED_JUMP_IN_WATER</code>.


 
==GatherConditions==
An interesting method is the <code>GatherConditions()</code> , it can be overridden in child classes to implement the selection of custom conditions, the method sets the NPC's conditions appropriate at the time based on game state.  
<code>GatherConditions</code> can be overridden in child classes to implement the selection of custom conditions; the function sets the NPC's conditions appropriate at the time based on game state.  
 


The following condition has been taken from the headcrabs <code>GatherConditions()</code> method.  
The following condition has been taken from the headcrabs <code>GatherConditions()</code> method.  


<pre>
<pre>
Line 22: Line 18:
}  
}  
</pre>
</pre>


This if block checks to see if the headcrab is alive but submerged in water, if so a condition <code>COND_HEADCRAB_IN_WATER</code> is set.
This if block checks to see if the headcrab is alive but submerged in water, if so a condition <code>COND_HEADCRAB_IN_WATER</code> is set.


 
==BuildScheduleTestBits==
Also another interesting method is the <code>BuildScheduleTestBits()</code>, it can be overridden to set custom condition to interrupt schedules. This is useful because you want to see your NPC react to the fire(<code>COND_ON_FIRE</code> example), start drowing (headcrab example) right now, not wait until the current schedule ends.
<code>BuildScheduleTestBits</code> can be overridden to set custom condition to interrupt schedules. If you want to see your NPC react to conditions, this needs to be overriden so the NPC reacts to fire (COND_ON_FIRE) or start drowing (COND_HEADCRAB_IN_WATER) right away, not after the current schedule ends.
 


Here is code from the headcrabs <code>BuildScheduleTestBits()</code>
Here is code from the headcrabs <code>BuildScheduleTestBits()</code>
Line 47: Line 41:
If the condition <code>COND_HEADCRAB_IN_WATER</code> is set, it interrupts the current schedule unless it is already drowning. Then this is handled in <code>SelectSchedule()</code> to choose the appropriate schedule (<code>SCHED_HEADCRAB_DROWN</code>) that will end up drowning the headcrab.
If the condition <code>COND_HEADCRAB_IN_WATER</code> is set, it interrupts the current schedule unless it is already drowning. Then this is handled in <code>SelectSchedule()</code> to choose the appropriate schedule (<code>SCHED_HEADCRAB_DROWN</code>) that will end up drowning the headcrab.


 
==See Also==
==Default Condition List==
* [[Shared conditions]] - a list of conditions inherited by all NPCs
COND_NONE: A way for a function to return no condition to get
 
COND_IN_PVS
 
COND_IDLE_INTERRUPT: The schedule in question is a low priority idle and therefore a candidate for translation into something else
 
COND_LOW_PRIMARY_AMMO
 
COND_NO_PRIMARY_AMMO
 
COND_NO_SECONDARY_AMMO
 
COND_NO_WEAPON
 
COND_SEE_HATE
 
COND_SEE_FEAR
 
COND_SEE_DISLIKE
 
COND_SEE_ENEMY
 
COND_LOST_ENEMY
 
COND_ENEMY_OCCLUDED: Can't see m_hEnemy
 
COND_TARGET_OCCLUDED: Can't see m_hTargetEnt
 
COND_HAVE_ENEMY_LOS
 
COND_HAVE_TARGET_LOS
 
COND_LIGHT_DAMAGE
 
COND_HEAVY_DAMAGE
 
COND_PHYSICS_DAMAGE
 
COND_REPEATED_DAMAGE: Damaged several times in a row
 
COND_CAN_RANGE_ATTACK1: Hitscan weapon only
 
COND_CAN_RANGE_ATTACK2: Grenade weapon only
 
COND_CAN_MELEE_ATTACK1
 
COND_CAN_MELEE_ATTACK2
 
 
COND_PROVOKED
 
COND_NEW_ENEMY
 
 
COND_ENEMY_TOO_FAR
 
COND_ENEMY_FACING_ME
 
COND_BEHIND_ENEMY
 
COND_ENEMY_DEAD
 
COND_ENEMY_UNREACHABLE: Not connected to me via node graph
 
 
COND_SEE_PLAYER
 
COND_SEE_NEMESIS
 
COND_TASK_FAILED
 
COND_SCHEDULE_DONE
 
COND_SMELL
 
COND_TOO_CLOSE_TO_ATTACK
 
COND_TOO_FAR_TO_ATTACK
 
COND_NOT_FACING_ATTACK
 
COND_WEAPON_HAS_LOS
 
COND_WEAPON_BLOCKED_BY_FRIEND: Friend between weapon and target
 
COND_WEAPON_PLAYER_IN_SPREAD: Player in shooting direction
 
COND_WEAPON_PLAYER_NEAR_TARGET: Player near shooting position
 
COND_WEAPON_SIGHT_OCCLUDED
 
COND_BETTER_WEAPON_AVAILABLE
 
COND_HEALTH_ITEM_AVAILABLE: There's a healthkit available.
 
COND_GIVE_WAY: Another npc requested that I give way
 
COND_WAY_CLEAR: I no longer have to give way
 
COND_HEAR_DANGER
 
COND_HEAR_THUMPER
 
COND_HEAR_BUGBAIT
 
COND_HEAR_COMBAT
 
COND_HEAR_WORLD
 
COND_HEAR_PLAYER
 
COND_HEAR_BULLET_IMPACT
 
COND_HEAR_PHYSICS_DANGER
 
COND_HEAR_MOVE_AWAY
 
 
COND_NO_HEAR_DANGER: Since we can't use CONDITION. Mutually exclusive with COND_HEAR_DANGER
 
COND_FLOATING_OFF_GROUND
 
 
COND_RECEIVED_ORDERS
 
COND_PLAYER_ADDED_TO_SQUAD
 
COND_PLAYER_REMOVED_FROM_SQUAD
 
 
COND_PLAYER_PUSHING
 
COND_NPC_FREEZE: We received an npc_freeze command while we were unfrozen
 
COND_NPC_UNFREEZE: We received an npc_freeze command while we were frozen
 
 
COND_TALKER_RESPOND_TO_QUESTION

Revision as of 18:24, 10 June 2006

Multiple conditions can be set on an NPC which help the NPC determine what schedule should be run (handled in SelectSchedule() or variants).

An example of a condition is COND_LIGHT_DAMAGE which may cause the NPC to go to an alert state and select a schedule appropriate to this condition.

NPC's can implement their own custom conditions to deal with things unique to that NPC, for instance, you could use a COND_ON_FIRE to determine if the NPC is on fire and select specific schedules on this condition such as SCHED_JUMP_IN_WATER.

GatherConditions

GatherConditions can be overridden in child classes to implement the selection of custom conditions; the function sets the NPC's conditions appropriate at the time based on game state.

The following condition has been taken from the headcrabs GatherConditions() method.

if( m_lifeState == LIFE_ALIVE && GetWaterLevel() > 1 ) 
{ 
          // Start Drowning! 
         SetCondition( COND_HEADCRAB_IN_WATER ); 
} 

This if block checks to see if the headcrab is alive but submerged in water, if so a condition COND_HEADCRAB_IN_WATER is set.

BuildScheduleTestBits

BuildScheduleTestBits can be overridden to set custom condition to interrupt schedules. If you want to see your NPC react to conditions, this needs to be overriden so the NPC reacts to fire (COND_ON_FIRE) or start drowing (COND_HEADCRAB_IN_WATER) right away, not after the current schedule ends.

Here is code from the headcrabs BuildScheduleTestBits()

if ( !IsCurSchedule(SCHED_HEADCRAB_DROWN) )
{
	// Interrupt any schedule unless already drowning.
	SetCustomInterruptCondition( COND_HEADCRAB_IN_WATER );
}
else
{
	// Don't stop drowning just because you're in water!
	ClearCustomInterruptCondition( COND_HEADCRAB_IN_WATER );
}

If the condition COND_HEADCRAB_IN_WATER is set, it interrupts the current schedule unless it is already drowning. Then this is handled in SelectSchedule() to choose the appropriate schedule (SCHED_HEADCRAB_DROWN) that will end up drowning the headcrab.

See Also