linked_portal_door
linked_portal_door
is a point entity available in Portal 2. It is a special type of portal without any effects, which can be used to seamlessly link together two distant parts of a map. These portals are square, and players can fire their portal gun through them. They are commonly called world portals by the community, referring to the fact that they are seamlessly integrated into the map rather than being placed by the player or a test element.
In the default FGD, the entity is represented as an axis helper. The red axis is normal to the surface of the portal, the green axis is the width, and the blue axis is the height. The default model has no directional indicators for these, so you must use the additional axis lines that appear when the entity is selected to determine which side is the front.
While this is a powerful entity, it has a number of bugs and considerations which must be taken into account when using it:
- Having a solid, moving brush entity in close proximity to the portal causes it to close. Non-moving brush entities and animated or moving props are okay though.
- Lasers passing through world portals will have the point they exit from offset based on the distance to a wall behind the world portal. If you are using world portals and lasers in the same map, you must make sure there is a wall directly behind the portal, otherwise lasers will not pass through correctly.
- By default, having more than 4 portals visible on-screen (including regular portals, but not incluidng portals seen through other portals) will cause major graphical bugs. This can be fixed/worked around by setting the cvar
r_portal_fastpath
to0
on clients. This has no known negative effects on its own, though having many portals visible at once will still degrade performance. - On lower graphics settings, world portals may stop rendering at a distance or when seen through another portal, so you should make sure there is something behind the portal for it to fall back to (rather than nodraw).
- The actual portal appears half of a unit in front of the entity's position, so to create a fully seamless link, it should be offset 0.5 units backwards using Hammer's transform tool (Ctrl+M).
- Moving the entity will not dynamically change the portal's position (even with
sv_allow_mobile_portals
on), it must be sent anEnable
input for it to update. - Portals are one sided, the back does not render.
- Players will still funnel into world portals if
sv_player_funnel_into_portals
is enabled, the same as regular portals.
Contents
Example uses
All Puzzlemaker levels use world portals to connect the exit and entrance elevators to the respective corridors; this avoids the embed spaces of the doors needing to be extremely large to accommodate the entire elevator shafts. They are also used twice in the campaign (contrary to the commentary's claim that they are only used once): in the GLaDOS wakeup sequence where they are used to connect the incinerator shaft to GLaDOS' chamber, and in Finale 2 where they are used to connect the "trap" chamber to the main map. These are the only uses of this entity in the final game.
However, the developer commentary explains that Valve extensively used these throughout Portal 2's development to make prototyping and iterating on levels faster. By connecting separate rooms with portals, sections of the level could be added, changed, or reordered without having to give any consideration to whether or not the space was physically possible and without having to spend significant amounts of time moving around and reconnecting chunks of the level. For a period of time, "every connection between any space was a portal", and they would even switch between them dynamically. As the game's development concluded and levels were finalized, most of these portals were removed, aside from the two cases listed above.
World portals are also extensively used in The Stanley Parable for the sections that loop infinitely on themselves or where backtracking leads the player somewhere completely different than where they came from.
Keyvalues
- Width <integer>
- 1/2 width of the desired portal. Must be less than 1024, and match the corresponding property of the partner.
- Height <integer>
- 1/2 height of the desired portal. Must be less than 1024, and match the corresponding property of the partner.
- Static Portal <boolean> (only in )
- If set to true, this portal does not ever move or toggle, and allows VRAD to cast light through it.Note:You need special arguments for VRAD to compile static lighting through world portals, click here.
- Start Active <boolean>
- Whether to start the linkage as active from the start. Note:(As of DLC1) This will create a logic_auto entity somewhere in your map. The engine will try to tell you that the logic_auto has invalid i/o. You can safely ignore this.
LinkedPortalDoor:
- Linked Partner <targetname>
- Another 'linked_portal_door' entity which will link to this one.
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_constraint
can 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!
- Flags
(spawnflags)
<integer> !FGD - Toggles exclusive features of an entity, its specific number is determined by the combination of flags added.
- Effects
(effects)
<integer> !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!
Inputs
LinkedPortalDoor:
SetPartner
<string>- Set a new partner door.
Open
- Open the door and cause the portal to activate.
Close
- Close the door and cause the portal to deactivate.
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.
FireUser1
toFireUser4
- Fires the respective
OnUser
outputs; 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 thanKill
input.
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.
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.
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
LinkedPortalDoor:
OnOpen
- Called when the door has started its open animation.
OnClose
- Called when the door has started its close animation.
OnEntityTeleportFromMe
- Called when an entity enters this linked portal.
OnPlayerTeleportFromMe
- Called when the player enters this linked portal.
OnEntityTeleportToMe
- Called when an entity exits this linked portal.
OnPlayerTeleportToMe
- Called when the player exits this linked portal.
Base:
OnUser1
toOnUser4
- These outputs each fire in response to the firing of the like-numbered
FireUser1
toFireUser4
Input; see User Inputs and Outputs.