Targetname: Difference between revisions
Jump to navigation
Jump to search
Note:Not all entity parameters can evaluate these targetnames.
Note:When used in an output's parameter override field, targetnames are evaluated by the entity that receives the output, not the one that sends it. This can change what is pointed to.
No edit summary |
TeamSpen210 (talk | contribs) (Add player_blue/orange (Portal 2)) |
||
Line 43: | Line 43: | ||
: The entity from which the current output originates. If a player walks into a trigger that that fires a logic_relay, the relay is the <code>!self</code> of its output(s). | : The entity from which the current output originates. If a player walks into a trigger that that fires a logic_relay, the relay is the <code>!self</code> of its output(s). | ||
; <code>!player</code> | ; <code>!player</code> | ||
: The player. Only useful in singleplayer. {{tip|To target all players in a server, use <code>player</code>.}} | : The player. Only useful in singleplayer. {{tip|To target all players in a server, use the <code>player</code> classname.}} | ||
; <code>!player_blue</code>{{Portal2}} | |||
: In Portal 2 Coop, this targets ATLAS (player 1). | |||
; <code>!player_orange</code>{{Portal2}} | |||
: In Portal 2 Coop, this targets P-Body (player 2). | |||
; <code>!pvsplayer</code> | ; <code>!pvsplayer</code> | ||
: The first player found in the entity's [[Potential Visibility Set]]. The PVS used is taken from the entity doing the searching, or the activator if no searching entity exists. If no activator exists either, the first player in the game is returned (i.e. <code>!player</code>). | : The first player found in the entity's [[Potential Visibility Set]]. The PVS used is taken from the entity doing the searching, or the activator if no searching entity exists. If no activator exists either, the first player in the game is returned (i.e. <code>!player</code>). |
Revision as of 14:42, 12 August 2018
A targetname is the name of an entity. A targetname is not required for an entity to exist, but generally must be present for an entity to play a part in the I/O System
Tips
Also known as name when smartedit is on
- It is sometimes possible to target entites by classname (e.g. prop_dynamic).
- A targetname must be stored in the map's entity data block, so avoid naming entities that don't need a name (i.e. aren't ever referenced by another entity). The comment field in Hammer is useful for describing entities that don't need targetnames, and doesn't get saved into the
.bsp
entity data block. - Targetnames do not need to be unique. As many entities as the mapper wants can share the same name, and they will all respond to the same inputs. Duplicated targetnames are displayed in bold font.
- Targetnames are also useful for categorizing entities (area1_name, area2_name, etc.).
- Targetnames cannot contain
!
or*
characters (see below).
Notes
Instances
- Instances may use prefix or postfix name fixups, and will auto-generate a prefix if no parameters are specified.
- Prefixes and Postfixes are separated by a single dash e.g. hall_a3-door_02.
- Placing an
@
symbol at the beginning of a targetname (e.g. @exit_door) will bypass a naming fixup for that particular entity. If @exit_door and exit_door_relay were part of an instance prefixed as Door_01, the names of the entities would be @exit_door and Door_01-exit_door_relay.
Name Searching
There are several extended features to name searches that are useful in a variety of situations. The most common use is to target an entity with an unknown name that is somehow involved in the current I/O chain. The extended features are:
- Wildcards
- Name searching supports trailing * wildcards only. So searching for area1* will match any targetnames that start with area1 (i.e. area1_portal and area1_door, but not area2_door).
- The I/O System is classname friendly, but Hammer isn't. This is the case that doesn't require a targetname for the I/O System.
- An example of this is use of ent_fire with a classname as opposed to a targetname.
Keywords
The following special targetnames can be used to dynamically select an entity.


!activator
- The entity that began the current I/O chain. If a player walks into a trigger that fires a logic_relay, the player is the
!activator
of the relay's output(s). !caller
- The previous entity in the current I/O chain. If a player walks into a trigger that that fires a logic_relay, the trigger is the
!caller
of the relay's output(s). !self
- The entity from which the current output originates. If a player walks into a trigger that that fires a logic_relay, the relay is the
!self
of its output(s). !player
- The player. Only useful in singleplayer.
Tip:To target all players in a server, use the
player
classname. !player_blue
- In Portal 2 Coop, this targets ATLAS (player 1).
!player_orange
- In Portal 2 Coop, this targets P-Body (player 2).
!pvsplayer
- The first player found in the entity's Potential Visibility Set. The PVS used is taken from the entity doing the searching, or the activator if no searching entity exists. If no activator exists either, the first player in the game is returned (i.e.
!player
). !speechtarget
- The entity at which the
!caller
is looking due to a Look At Actor or Face Actor choreography event. !picker
- The first entity under the player's crosshair. Only useful in single-player, and mostly only for debugging. Entities without collision can only be selected by aiming at their origin.
See also
- List of Entity Classes that cannot have a Targetname
- Client Command by Trigger proximity, a mini-tutorial explaining the process of letting the player(s) in your game execute a Client Command by a trigger.
- User Inputs and Outputs
GetDebugName()
, for accessing an entity's targetname in C++.