A targetname (also known simply as Name) 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
- Entities may also be targeted by their classname (e.g. prop_dynamic).
- Targetnames do not need to be unique, they can be shared (and inputs will be sent to each one). Duplicated targetnames are displayed in bold font.
- Targetnames cannot contain
*characters (see below).
- 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.
Any entity with the following targetnames will have a Use input sent to them when that event occurs.
game_playerdie- Fires every time a player dies. The player who died is the !activator.
game_playerkill- Fires every time a player kills another player, the killer is the !activator.
game_playerjoin- Fires every time a player joins the game, the joining player is the !activator.Bug:
game_playerjoinis not fired by bots.
game_playerspawn- Fires every time a player spawns, the spawning player is the !activator.
game_playerleave- Fires every time a player leaves the game, !activator will not work in this case as the player entity no longer exists.
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:
- 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.
The following special targetnames can be used to dynamically select an entity.
- 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
!activatorof the relay's output(s).
- 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
!callerof the relay's 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
!selfof its output(s).
- The player.
When finding an entity by name, this return the player in slot 1 (if any), which is generally only useful in singleplayer.
- In Portal 2 Coop, this targets ATLAS (player 1).
- In Portal 2 Coop, this targets P-Body (player 2).
- 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.
- The entity at which the
!calleris looking due to a Look At Actor or Face Actor choreography event.
- 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.
- The special targetnames !activator and !caller are not managed by the I/O system itself, rather, each entity in the chain chooses the values to be passed on to the next. Often, this choice is stupid. About 10% of outputs pass self where they should have passed on activator, and about 10% preserve caller when they should have replaced it with self.
- Targetnames used in an output's parameter override field are evaluated after the point at which the sending entity has chosen the new activator and caller values to be seen by the receiving entity. This causes !caller to evaluate to the sending entity (the same as !self) when used in output parameter override fields in about 90% of cases.