| Latest revision |
Your text |
| Line 1: |
Line 1: |
| '''Linked portals''' are a powerful feature which make it possible to connect two separate areas of a map via the floor/ceiling or 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. | | '''Linked portals''' are a powerful feature which make it possible to connect two separate areas of a map via the floor/ceiling or 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. |
|
| |
| '''NOTE''': for [[UDMF]] portals, you use the [[Portal_Define]] and [[Line_QuickPortal]] specials.
| |
| {{backto|Portal linedef types}} | | {{backto|Portal linedef types}} |
|
| |
|
| Line 13: |
Line 11: |
|
| |
|
| ==Line triggers== | | ==Line triggers== |
| Linked portals are set up by using linedef types (specials). If the map format is [[UDMF]], they are also set up using UDMF sector and linedef properties.
| |
| ===UDMF format===
| |
| The following specials are used in UDMF to setup portals: [[Portal_Define]] and [[Line_QuickPortal]]. Then, on each sector you can set the '''portalfloor''' and '''portalceiling''' properties, using portal ID, to apply newly defined portal on the respective surfaces. On each linedef you can set the '''portal''' property similarly.
| |
|
| |
| The portal ID can be made negative as well: this spawns a portal going the opposite direction. For example, a linedef linked portal going from area A to B has a positive '''portal''' setting, and the corresponding linedef going from B to A has the negative value for '''portal'''.
| |
|
| |
| ===Classic Doom format===
| |
| # Class Trig Description | | # Class Trig Description |
| | | |
| Line 35: |
Line 26: |
| | | |
| 385 Ext -- Apply portal to front sector | | 385 Ext -- Apply portal to front sector |
|
| |
| For sectors you will use the specials 358, 359, 360, 361 and 385, while for lines you'll use 376 and 377.
| |
|
| |
|
| ==Terminology== | | ==Terminology== |
| Line 102: |
Line 91: |
|
| |
|
| ===Setting up wall portals=== | | ===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. | | 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). |
|
| |
|
| On [[UDMF]], use the [[Line_QuickPortal]] (301) special on both lines and give them the same tag (line ID, not the first arg). The first arg can be used to specify if it's a completely linked portal, or a mere visual one.
| | 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. |
|
| |
|
| On the classic format, 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).
| | Here is a diagram on how to set up: |
|
| |
|
| Note that on older Eternity versions, the portal lines needed to be 2-sided and passable, and you had to add a buffer sector behind the portal lines. On the latest versions, 1-sided lines are accepted. The only requirement left is to leave enough space in the void behind these 1-sided lines to prevent actors from bumping on other walls from the same layer.
| | ----------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 sector portals=== | | ===Lifts between sector portals=== |
| Line 118: |
Line 119: |
| * Attach the floor movement between the two sectors. Check the link above to see how it's done. | | * Attach the floor movement between the two sectors. Check the link above to see how it's done. |
| * To adjust the floor to the bottom or top height, you can use a special at the beginning of the level (either through an OPEN ACS script, using Boom voodoo dolls / conveyors or a trigger near the player start). | | * To adjust the floor to the bottom or top height, you can use a special at the beginning of the level (either through an OPEN ACS script, using Boom voodoo dolls / conveyors or a trigger near the player start). |
|
| |
| ===Polyobject portals===
| |
| You can even place portals on polyobjects now. Connecting the edges of a polyobject with a sector matching its "interior", you can now have moving platforms. Unlike conventional wall portals, the ones on the polyobject's exterior must be one-sided. Upper and lower textures will still work, despite this. The wall portals from the inside area to the outside will have to be conventional though (2-sided with a buffer sector behind).
| |
| ====Caveats====
| |
| Though this may get fixed in future versions, make sure to connect the polyobject control sector (the one holding all prototype polyobjects) to the main area it will appear in. You can use tunnel sectors or joined sectors. To avoid glitches, the sector containing the prototypes must not be the same sector as the one where polyobjects will be spawned.
| |
| ====Simple moving platform illusion====
| |
| You can put a linked portal in the ceiling of the inner sector to give the illusion that a simple platform is moving on the floor. It works if you used the [[Portal_Define]] special for the line portals and if the background room has the same ceiling height, or in very small variation, in the area where the polyobject moves. Acceptable variations are at most 8 map units. Otherwise, you get bleeding effects.
| |
|
| |
| The platform sector must have the ceiling height set to the maximum ceiling of the outside area. Set the '''portalceiling''' field of the sector to the same ID you used for the walls. Make sure the z offset of [[Portal_Define]] is set correctly: if the inner sector is a raised platform compared to the outside sector, the z offset should be the ''minimum'' ceiling height from the outside area, minus the elevation of the platform against the background. If it's a "moving pit", the z offset should be the negative of the height of the lowest ceiling detail from the outside area.
| |
|
| |
| It is recommended to set '''portal_ceil_nopass''' on the sector, especially if there is no height variation. This prevents unnecessary side effects.
| |
|
| |
| An example is available for download: [https://www.dropbox.com/s/xi1xhv92h27ptep/polyceilport.wad?dl=0 PolyCeilPort.wad].
| |
|
| |
| ===Edge portals===
| |
| You can also put portals on upper and lower edges of linedefs. See [[Edge portals]].
| |
|
| |
| ===Attached portals===
| |
| You can attach linked portals to their floors or ceiling. By default they stay fixed, so that making elevators going through portals is possible. But if you want the linked portal to move along with the floor or ceiling over which it's drawn, you enable the [[UDMF]] '''portal_floor_attached''' or '''portal_ceil_attached''' flags, or the [[ExtraData]] '''ATTACHEDPORTAL''' portal flag. Set these flags for both parts of the portal, and combine them with the [[attached surfaces]] feature, so that all required surfaces move synchronized.
| |
|
| |
| An example usage of this is a platform you can walk both under and above, which is made possible by sector portals (optionally with [[edge portals]] surrounding it). Giving the "attached portal" flag to the portals, and attaching both their surfaces and platform's surfaces to a moving floor, will allow you to setup the effect of the platform itself bobbing up and down. You can also setup other less realistic effects with this flag.
| |
|
| |
|
| ==Caveats and limitations== | | ==Caveats and limitations== |
| Line 147: |
Line 127: |
| ==Tutorial== | | ==Tutorial== |
| Refer to Zarkyb's [[linked portals tutorial]] for more examples on usage. | | Refer to Zarkyb's [[linked portals tutorial]] for more examples on usage. |
|
| |
| ==UDMF portals editor support==
| |
| At the moment of this writing, Doom Builder X (Windows only) by anotak highlights sectors with matching portal IDs for you. You can otherwise use any editor with full UDMF support, but may not get all the visual support.
| |
|
| |
|
| ==Examples== | | ==Examples== |
| Line 168: |
Line 145: |
|
| |
|
| [[File:Linked_portals.png]] | | [[File:Linked_portals.png]] |
|
| |
| ==See also==
| |
| *[[3DMidTex]]: for lighter ways to achieve room-over-room.
| |
|
| |
|
| [[Category:Editing]] | | [[Category:Editing]] |
| [[Category:Editing reference]] | | [[Category:Editing reference]] |
| [[Category:Portals]]
| |
