Patrol Assault Entities

This example map illustrates the use of the assault entities to move a group of NPCs into rally positions and then assault positions following a trigger.

The general configuration was taken from the SDK example map "sdk_d2_coast_12.vmf."

Note the suggested order of placing entities below.

"assault_assaultpoint" entities are placed at the final positions to which the NPCs are to move when the assault is underway. The assault points are each named differing only by the last digit in the name for simplicity.

"assault_rallypoint" entities are then placed at the start positions to which the NPCs are to move when the assault begins. The assault rallypoints are each named differing only by the last digit in the name to allow a wildcard search by the ai_goal_assault entity. This is an important point!

The "assault point" property of each rally point is then associated with a corresponding assault_assaultpoint entity. Each rally point must point to a different assault point. The naming convention suggested above simplifies choosing associated points.

NPCs (in this case, npc_combine_s entities) are then added and placed in close proximity to (or directly on top of) rally points. The NPCs are each named differing only by the last digit in the name to allow a wildcard search by the ai_goal_assault entity. This is also an important point!

An "ai_goal_assault" entity is then added (anywhere within the map) and given a name. The rallpoint property is set to a wildcard string for the names of the rally points. In this case, the rally points are named "soldier_assault1_rally1," "solider_assault1_rally2," etc. The rallypoint property of the ai_goal_assault is then set to the string "solider_assault1_rally*" allowing activation of all the rally points.

The affected actor property of the ai_goal_assault is set to a wildcard string for the names of the NPCs to rally for the assault. In this case, the combine soldiers are named "patrol_1_soldier1," "patrol_1_solider2," etc. The actor property of the ai_goal_assault is then set to the string "patrol_1_soldier*" allowing activation of all the soldiers.

A logic_relay entity is then added, named and set with two outputs: one to trigger the Activate input of the ai_goal_assault; a second to trigger the BeginAssault input of the ai_goal_assault. In this case, the triggers are set just a tenth of a second apart.

A trigger (in this example a func_button) is then added which triggers the logic_relay. The func_button can be replaced with any triggering entity, such as a trigger_once block to start the assault when the player enters an area.

The sequence:

Load the bsp and "Use" the func_button which triggers the logic_relay.

When the logic_relay is triggered, it Activates the ai_goal_assault and the soldiers each seek a rally point close to them. When the logic_relay triggers the ai_goal_assault BeginAssault input, the solider at each rally point seeks the assault point associated with the rally point they've chosen.

The assault points need not be in direct line-of-sight from its rally point. A wall has been added to the map to illustrate this. However, ground nodes have been added to allow the NPC AI (artificial intelligence) to chose a route around the wall to the assault points.

A viewing platform constructed from PLAYER_CLIP blocks has been added only to provide you with a platform to watch the assault. Block LOS (line-of-sight) blocks have been added to the platform to prevent the NPCs from seeing you as you observe.