assault_rallypoint
assault_rallypoint is a point entity available in all 
Source games.
…
This article needs more links to other articles to help integrate it into the encyclopedia. Please help improve this article by adding links that are relevant to the context within the existing text.
January 2024
January 2024
It specifies a point used to rally NPCs for assault behavior. Used with either an ai_goal_assault or the Assaultinput available on some NPCs. All assaults begin at an assault_rallypoint. NPCs move to these points when cued for an assault, optionally waiting here, before commencing the assault by heading to an assault_assaultpoint.
Not available in 
.
In code, it is represented by theCRallyPointclass, defined in theai_behavior_assault.cppfile.Limitations and bugs
- A rallypoint can only serve one NPC per assault. If multiple NPCs are required to assault at the same time, each needs their own rallypoint. There may be a solution to this but it is not yet documented. Use of wildcards can make the assignment of individual NPCs to individual rallypoints easier.
- NPCs will always turn to face in the direction the entity is set to when arriving at a rally point. This is might look unnatural in some cases.
Keyvalues
- Priority (priority) <integer>
- How appealing the rallypoint will be. When an NPC receives the
Assaultinput, it will select a suitable rallypoint from those available to it, preferring the one with the highest Priority value. If the Priority is the same between any rallypoints, the closest one will be chosen.
- Assault Point (assaultpoint) <targetname>
- The first
assault_assaultpointin the chain to move to as the assault begins.
- Assault Delay (assaultdelay) <float>
- The amount of time to wait here once the assault cue has been given, before moving to the first
assault_assaultpoint.
- Rally Sequence (rallysequence) <string>
- Set a specific animation sequence for NPCs waiting to begin the assault, overriding the wait activity of the NPC.
- Force Crouch (forcecrouch) <boolean>
- NPCs using this assault point are forced into crouching while holding it.
- Urgent (urgent) <boolean>
- If set, NPCs will consider movement to this rally point as Urgent Navigation (ignoring prop_physics blockers, eventually teleporting).
- Should Point Lock (lockpoint) <boolean> (in all games since
) !FGD - Should this point be considered unusable by other NPCs once one has "claimed" it?[confirm]
- 0: No
- 1: Yes
Base:
- Parent
(parentname)<targetname> - Maintain the same initial offset to this entity. An attachment point can also be used if separated by a comma at the end. (
parentname [targetname],[attachment])
Tip:Entities transition to the next map with their parentsTip:phys_constraintcan be used as a workaround if parenting fails.
- Origin (X Y Z)
(origin)<coordinates> - The position of this entity's center in the world. Rotating entities typically rotate around their origin.
Note:Hammer does not move the entities accordingly only in the editor.
- Pitch Yaw Roll (X Y Z)
(angles)<angle> - This entity's orientation in the world. Pitch is rotation around the Y axis, yaw is the rotation around the Z axis, roll is the rotation around the X axis.Note:This works on brush entities, although Hammer doesn't show the new angles.
- Classname
(classname)<string> !FGD - Determines the characteristics of the entity before it spawns. Tip:Changing this on runtime still has use, like making matching an entry in S_PreserveEnts will persist the entity on new rounds!
- Spawnflags
(spawnflags)<flags> !FGD - Toggles exclusive features of an entity, its specific number is determined by the combination of flags added.
- Effects
(effects)<flags> !FGD - Combination of effect flags to use.
- Entity Scripts
(vscripts)<scriptlist> (in all games since
) (also in 
) - Space delimited list of VScript files (without file extension) that are executed after all entities have spawned. The scripts are all executed in the same script scope, later ones overwriting any identical variables and functions. Scripts executed on the worldspawn entity will be placed in root scope.
- Think function
(thinkfunction)<string> (in all games since) (also in ) - Name of the function within this entity's script that'll be called automatically every 100 milliseconds, or a user-defined interval if the function returns a number. Avoid expensive operations in this function, as it may cause performance problems.
- Lag Compensation
(LagCompensate)<boolean> (in all games since) !FGD - Set to Yes to lag compensate this entity. Should be used very sparingly!
- Is Automatic-Aim Target
(is_autoaim_target)<boolean> (in all games since
) !FGD - If set to 1, this entity will slow down aiming movement for consoles and joystick controllers when the entity is under the crosshairs.
Inputs
Base:
AddContext<string>- Adds to the entity's list of response contexts. See Context.
AddOutput<string>- Assigns a new keyvalue/output on this entity. For keyvalues, some rely on extra necessary code to be ran and won't work if its simply just changed through this input. There is a strict format that must be followed:
// Format of changing KeyValues: "AddOutput [key] [value]"
//// Raw text:
"OnUser1" "!self,AddOutput,targetname new_name"
// Format of adding an Output: "AddOutput {targetname}:{inputname}:{parameter}:{delay}:{max times to fire, -1 means infinite}"
//// Raw text:
"OnUser1" "!self,AddOutput,OnUser1:SetParent:!activator:0.0:-1"
// Arguments can be left blank, but the empty blank should still be contained.
//// Raw text:
"OnUser1" "!self,AddOutput,OnUser1:ClearParent::0.0:-1"
|
ClearContext- Removes all contexts from this entity's list.
ClearParent- Removes this entity from the the movement hierarchy, leaving it free to move independently.
FireUser1toFireUser4- Fires the respective
OnUseroutputs; see User Inputs and Outputs.
Kill- Removes this entity and any entities parented to it from the world.
KillHierarchy- Functions the same as
Kill, although this entity and any entities parented to it are killed on the same frame, being marginally faster thanKillinput.
RemoveContext<string>- Remove a context from this entity's list. The name should match the key of an existing context.
SetParent<string>- Move with this entity. See Entity Hierarchy (parenting).
SetParentAttachment<string>- Change this entity to attach to a specific attachment point on its parent. The entity will teleport so that the position of its root bone matches that of the attachment. Entities must be parented before being sent this input.
SetParentAttachmentMaintainOffset<string>- As above, but without teleporting. The entity retains its position relative to the attachment at the time of the input being received.
DispatchResponse<string> !FGD- Dispatches a response to the entity. See Response and Concept.
DispatchEffect<string> (removed since
) !FGD- Dispatches a special effect from the entity's origin; See also List of Client Effects. Replaced by the particle system since .
RunScriptFile<script> (in all games since) (also in )- Execute a VScript file from disk, without file extension. The script contents are merged with the script scope of the receiving entity.
RunScriptCode<string> (in all games since) (also in )- Execute a string of VScript source code in the scope of the entity receiving the input. String quotation may be needed when fired via console.
Bug:In Hammer, using string arguments will corrupt the VMF file's structure, making the file unviewable for the next Hammer session.Fix:Remove the string argument manually with a text editor.Note: Backtick characters ` are replaced with quotation marks at runtime, allowing quotation marks to be used when normally not possible.
CallScriptFunction<string> (in all games since) (also in ) !FGD- Calls a VScript function defined in the scope of the receiving entity.
TerminateScriptScope(only in) !FGD- Destroys the script scope of the receving entity.
SetLocalOrigin<coordinates> (in all games since) !FGD- Send this entity to a spot in the map. If the entity is parented to something, it will be offset from the parent by this amount.
Outputs
OnArrival- Fires when the NPC arrives.
Base:
OnUser1toOnUser4- These outputs each fire in response to the firing of the like-numbered
FireUser1toFireUser4Input; see User Inputs and Outputs.
