Difference between revisions of "Linked portal"

From Eternity Wiki
Jump to: navigation, search
Line 127: Line 127:
[https://s3-eu-west-1.amazonaws.com/eternity/linked_port.wad demo file] - a demonstration of both plane and wall portals.
===[https://s3-eu-west-1.amazonaws.com/eternity/linked_port.wad demo file]===
Played on '''Doom2, Map01'''.
a demonstration of both plane and wall portals.
Played on '''Doom2''' / '''Map01'''.
Things to note:
Things to note:

Revision as of 20:15, 9 February 2013

Linked portals are a powerful feature which make it possible to connect two separate areas of a map via the floor/ceiling or one-sided linedefs, allowing the player to see, shoot, and even move seamlessly from one area into another. They are used similarly to two-way portals, apart from the fact that you can pass through them. They can be used to create 3D architecture and room-over-room effects, with very few limitations.

Back to Portal linedef types


Linked portals bottom.png Linked portals top.png
View from the bottom room View from the top room.

Line triggers

#     Class  Trig Description

358   Ext    --   Apply linked portal to like-tagged ceilings

359   Ext    --   Apply linked portal to like-tagged floors

360   Ext    --   Linked portal anchor line for special 358

361   Ext    --   Linked portal anchor line for special 359

376   Ext    --   Apply linked portals to like-tagged lines

377   Ext    --   Anchor line for special 376

385   Ext    --   Apply portal to front sector


Linked portals have their own specific sub-set of terminology used to describe certain aspects and behaviors.

Portal Plane

Unlike the basic portal types, which were rendered and could cover height variances (much like the doom sky), linked portals form an actual map structure. The Portal Plane refers to an X/Y plane that bisects the sector(s) that contain the portal. The z-position of the portal is fixed, and should be the same height on both sides of the linked portal.

Beyond the Plane

Map architecture is said to be beyond the portal plane when its vertical height is equal to or beyond the portal height--that is, at or above a ceiling portal plane or at or below a floor portal plane. When map architecture is beyond a portal plane, the portal will display at the height of the plane.

Inside the plane

Map architecture is said to be inside the portal plane when its vertical height is not beyond the portal plane--that is, below a ceiling portal or above a floor portal. Any architecture that is inside the portal plane will render normally and will obscure rendering of the portal.


Linked portals use trigger and anchor lines (much like anchored portals) to determine an X and Y offset from one part of the map to another, but there are specific requirements unique to linked portals:

  • Linked portals must be two-way, meaning the upper area must reference the lower area and vice versa.
  • Linked portals have specific behavior relating to z-coordinates of the portal plane.


There are two kinds of linked portals: plane portals and line portals. Plane portals are sector floor or ceiling surfaces that vertically connect different sector groups (layers) of the map. Line portals are linedefs that connect areas horizontally.

Setting up plane portals

There must be (at least) two sectors in the map, not linked together by any path (similar to how disjoint areas exist in classic Doom maps and are gameplay-connected only by teleporters).

The ceiling height of one of them must match the floor height of the other. Let's call the bottom sector A and the top sector B.

Even though the sectors need to have the same outline, they can have different detail inner sectors in them. For example, sector A can have several crate sectors whose outlines don't need to be copied into upper sector B, which has much less detail. Note that one-sided linedef walls inside sectors (e.g. columns) must have their outlines copied.

Reserve two linedefs for each sector. Make sure the two linedefs selected for sector A will have the same relative coordinates and sizes as the two corresponding linedefs from B.

Tag sector A and its inner details with a number. Tag B and its details with another number.

Give the reserved linedefs from A special 359, tag of B and special 360, tag of A respectively. Give the reserved linedefs from B special 358, tag of A and special 361, tag of B respectively. Here is how they should correspond:

  • Reserved linedef 1 of sector A: special 359, tag B (Apply linked portal to floor of B)
  • Reserved linedef 1 of sector B: special 361, tag B (Linked portal anchor line for special 359)
  • Reserved linedef 2 of sector A: special 360, tag A (Linked portal anchor line for special 358)
  • Reserved linedef 2 of sector B: special 358, tag A (Apply linked portal to ceiling of A)

Note that with this implementation, you'll have to give a tag to every sector which needs a portal. Sometimes this is not practical, because you may want to make various sectors with special effects within A or B. To bypass this problem, you can tag the special sector differently, but one of the linedefs facing it must have special 385 (Apply portal to front sector) and have the tag of the non-special sectors that surround it (A or B). This will copy the portal information into the special sector.

Here is a diagram on how to set up:

-----------------x---------------------x:::::::::::::      ~-------------------x---------------------x:::::::::::::::::::
                /                       \::::::::::::      ~ Neighbour        /                       \::::::::::::::::::
 Neighbour     /         SECTOR A        \::::::::::       ~ sector of       /         SECTOR B        \:::::::::::::::::
 sector of    /  x----x             floor \:::::::::       ~ B              /  x----x                   \::::::::::::::::
 A           /   |::::|             detail \::::::::       ~ (not tagged)  /   |    |                    \:::::::::::::::
 (untagged) /    |::::|wall         x---x   \:::::::       ~              /    |    |top of wall from A   \::::::::::::::
-----------x     x----x             |   |    x:::::::::    ~-------------x     x----x <NOT tagged          x:::::::::::::
::::::::::::\                       x---x   /:::::::::::::::::::::::::::::\                               /::::::::::::::
:::::::::::::\    x---x-----x same tag as^ /:::::::::::::::::::::::::::::::\     x-------------x         /:::::::::::::::
::::::::::::::\    \   \    | <  A        x:::::::::::::::::::::::::::::::::\    x-------------x        x::::::::::::::::
:::::::::::::::\    x---x---x            /360,A::::::::::::::::::::::::::::::\ ceil. detail            /358,A::::::::::::
::::::::::::::::\ flr.detail    359,B   /:::::::::::::::::::::::::::::::::::::\ tag of B      361,B   /::::::::::::::::::
:::::::::::::::::::::::::::::::::THE PORTAL LINEDEFS:::::::::::::::::::::::::::::::::::::::::THE PORTAL LINEDEFS:::::::::

Setting up wall portals

Wall portals are slightly simpler to implement. The two separate sectors must have the same floor and ceiling heights and the portal linedefs need to be of the same length and angle. They must also be two-sided, passable and have a buffer sector behind them, with enough depth so the portal is walkable by the intended actors (so they don't bump into the back wall of the buffer sector).

The two linedefs will have the 376 and 377 specials (respectively, order not being important) and a common tag (which doesn't have to belong to any sector).

Note that to render correctly, the buffer sectors behind them will need to have different light levels from the one in front of them. If the portal works correctly, they will never be visible during the game, and won't be accessible unless the user activates no-clipping mode.

Here is a diagram on how to set up:

----------x <----main area sectors--------->    x---------
          |        Visible            x---------x
          |                           |         |
          |                           |         |<linedef B
          x-------x                   |         | type 377
linedef A>|       |<-buffer sectors-> |         | tag n
type 376  |       |                   x---------x
tag n     |       |  Never visible in-game      |
          |       |  but wide enough to fit     |
----------x-------x  walking objects            x---------
                     Set their light levels to different values from neighbouring main area sectors

Lifts between plane portals

You can make the floor or ceiling of a sector move from a sector group (layer) to another by using the Attached surface linedef types.

Caveats and limitations

  • Linked areas must have corresponding floor or ceiling heights. It's not possible to look and move into an area with different Z coordinates.
  • It is possible to make "impossible" structures, both with plane and line portals, but note that Eternity will attempt to render any scene relative to viewer's coordinates when looking at the portal, including any unrelated sectors placed at the same XY coordinates as the "virtual" tunnel. This undesired effect can be reduced by setting up the layout of the map properly.
  • An "infinite" tunnel can be created, but it must consist of at least three sector groups in a cycle, as well as avoiding any visibility glitches mentioned in the previous point.

The following four points are valid because linked portals as a reliable feature are not fully implemented, but have been made available to the user, or for experimentation:

  • Currently the hitscan traversal through portals is not implemented, which means that bullet attacks will be stopped, monsters will not be able to see you etc. The monsters will be able to hear and follow you through the portal however, and projectiles will pass through.
  • Currently, an actor standing between two layers separated by a plane portal will jump repeatedly between the two areas and have difficulty walking.
  • Currently sprites aren't seamlessly rendered through portals, appearing cut off by the portal plane.
  • Currently, moving through portals can result in objects getting stuck, telefragged etc. Previously it was a hazard to the player too, as anything could telefrag, but it has been changed to be less hazardous.

Regardless, it is still possible to make convincing levels with linked portals even at their current state, as long as you make sure that major combat scenes will not take place between portals. Flying monsters can still follow the player through portals, so they have an advantage.


Refer to Zarkyb's linked portals tutorial for more examples on usage.


demo file

a demonstration of both plane and wall portals. Played on Doom2 / Map01.

Things to note:

  • In compatibility menu the option actors have infinite height needs to be set to false in order for any actor to fall through a portal.
  • The "upper part" is textured differently from the "lower part". While in game observe when textures change and where exactly the clipping occurs.
  • The lower room has a different shape than the room upstairs. Only the tagged, corresponding sectors which make up a "hole" have to be shaped alike.
  • Any LineDef that copies floor / ceiling requires an appropriate Anchor action on correspodning LineDef in the copied sector. E.g. should the action special: 360; tag: 1 be cleared from where it is and set on any other LineDef, you'd get clipping errors, HoM effects or the renderer would simply refuse to connect portals.
  • When viewing automap notice how position is updated. Player doesn't seem to "teleport" from one place of the map to another, yet his X/Y coordinates change when passing a portal boundary.
  • Use console commands like spawn doomimp to test how monsters see, hear and aim through portals.
  • Use console command fly to test that you can indeed cross portals from both sides of the "hole".
  • When viewing through map editor note that there's no sector tagged with a 3 (tag used to link wall portals). Wall portals clipping is based on LineDefs, not sectors.

Linked portals.png