PolyObjects are special sets of one-sided linedefs which, unlike any other lines, can be moved on the map during gameplay. Unlike the Hexen and ZDoom implementation of PolyObjects, Eternity does not restrict these objects to one per subsector, and they are also allowed to move any distance from their spawn point, even across subsector boundaries.

PolyObjects fully clip normal objects such as the player and enemies, optionally doing crushing damage depending upon the type of spawn spot used. They also block bullet tracers and monsters' lines of sight. They do not, however, clip sound propagation, so it may be necessary to use sound blocking lines near areas where PolyObjects are meant to function as a normal wall until they move.

Although Eternity does allow PolyObjects to move between different subsectors, this will only work properly if the subsectors on both sides of a line have the same properties (floor & ceiling heights, light level, and flat). However, since the implementation of [[dynaseg]]s, Eternity does not require a "PolyObject-aware" node builder.

Finally, unlike ZDoom, Eternity allows PolyObjects to be used in DOOM-format maps via the use of [[ExtraData]]. See the subsections below for more information on how to create and move PolyObjects.
{{Backto|Linedef types}}

==Creating PolyObjects==

PolyObjects are a combination of a set of 1S lines, which are typically placed in a "control sector" area outside of the main map, and exactly two mapthings: one spawn spot, and one anchor point. There are two different methods for grouping lines into a PolyObject.

*'''Method 1: The ''Polyobj_StartLine'' Special'''

:The Polyobj_StartLine special marks the first line in a PolyObject which is made up of a cyclic set of linedefs (that is, each line "points toward" the next line, ending at the first vertex of the first line).

:Diagrammatic Example:
:[[File:Polyobjects_basic.png]]
:Assume that the linedef A is assigned the Polyobj_StartLine special and has argument #1 set to "1" -- this is its PolyObject ID number, which must be unique amongst all on the map, and must be a number greater than zero.

:Starting from line A, the engine will go from vertex to vertex, adding the first line found which shares the current line's second vertex as its first vertex. In this example, since the object is closed as is required, the process will end at the first vertex of line A, and there will be four lines in the PolyObject (note that unlike Hexen, there is NO limit to the number of lines that can be placed in one PolyObject).

:Now, once the lines are added, it is necessary to define the control objects. Points B and C are the two required objects:
:* B: This is the PolyObject's anchor point (type EEPolyObjAnchor with DoomEd #9300). It defines the point relative to which all the lines in the PolyObject will be translated to the spawn point. This object's angle must be set to the same value as the StartLine's first argument (the PolyObject ID). There must be one and only one of these objects for each PolyObject ID.
:* C: This is the PolyObject's spawn point (one of EEPolyObjSpawnSpot [9301] or EEPolyObjSpawnSpotCrush [9302]). It defines the point where the PolyObject will initially spawn on the map. The anchor point will be translated to this exact location, and all lines in the PolyObject will maintain their relative positions to it. This object must also have its angle field set to the same value as both the StartLine's first argument and the anchor point's angle field. There must be one and only one of these objects for each PolyObject ID. Use 9302 to cause the PolyObject to do crushing damage to things that block it while it is in motion.

:Note that when you use this method, the other lines belonging to the PolyObject can be given their own line specials, including ones which affect the PolyObject itself. When the player presses the PolyObject, the specials will work as expected.

:The complete arguments to Polyobj_StartLine are as follows:
:* ''polyobj_id'' : the unique ID number (greater than zero) of the PolyObject
:* ''mirror_id'' : the ID number of a PolyObject that you want to mirror every action that affects this PolyObject. This number cannot be the same as the PolyObject's own ID.

:In order to use this line special in a DOOM-format map, it is necessary to use [[ExtraData]]. In that case, you must give the line you want to have the Polyobj_StartLine special the ExtraData linedef control special (#270) instead, and then specify Polyobj_StartLine and its arguments in its corresponding ExtraData linedef record.

*'''Method 2: The ''Polyobj_ExplicitLine'' Special '''

:The Polyobj_ExplicitLine special demarcates every line that will be added to a PolyObject and the exact order in which the lines will be added. This affords a bit more flexibility in the construction of PolyObjects at the price of not allowing any other line specials to be placed on the object itself.

:Diagrammatic Example:
:[[File:Polyobjects_adv.png]]
:Assume that the linedefs labeled 1 through 4 are assigned the Polyobj_ExplicitLine special, all have argument #1 set to "1" -- this is its PolyObject ID number, which must be unique amongst all on the map, and must be a number greater than zero -- and all have argument #2 set to the integer values 1 through 4, corresponding to their labels in the diagram.

:The game engine will search through all linedefs in the entire map for ones with the current PolyObject ID in argument #1 and a value greater than zero in argument #2. The lines will be collected and then sorted by the value in their second argument and added to the PolyObject in that order. Note that unlike Hexen, it is not necessary for the numbers in the second argument to be sequential (ie, a sequence such as { 5, 10, 15, 20 } would also work).

:Now, once the lines are added, it is necessary to define the control objects. This is exactly the same as it is for the StartLine special above.
:* B: This is the PolyObject's anchor point (type EEPolyObjAnchor with DoomEd #9300). It defines the point relative to which all the lines in the PolyObject will be translated to the spawn point. This object's angle must be set to the same value as the ExplicitLines' first argument (the PolyObject ID). There must be one and only one of these objects for each PolyObject ID.
:* C: This is the PolyObject's spawn point (one of EEPolyObjSpawnSpot [9301] or EEPolyObjSpawnSpotCrush [9302]). It defines the point where the PolyObject will initially spawn on the map. The anchor point will be translated to this exact location, and all lines in the PolyObject will maintain their relative positions to it. This object must also have its angle field set to the same value as both the ExplicitLines' first argument and the anchor point's angle field. There must be one and only one of these objects for each PolyObject ID. Use 9302 to cause the PolyObject to do crushing damage to things that block it while it is in motion.

:The complete arguments to Polyobj_ExplicitLine are as follows:
:* ''polyobj_id'' : the unique ID number (greater than zero) of the PolyObject
:* ''number'' : specifies the order in which the line will be added to the PolyObject. This number should be unique amongst all lines to be added to the same object, and must be a value greater than zero.
:* ''mirror_id'' : the ID number of a PolyObject that you want to mirror every action that affects this PolyObject. This number cannot be the same as the PolyObject's own ID.

:In order to use this line special in a DOOM-format map, it is necessary to use ExtraData. In that case, you can either give the lines you want to have the Polyobj_ExplicitLine special the ExtraData linedef control special (#270) instead, and then specify Polyobj_ExplicitLine and its arguments in all the corresponding ExtraData linedef records; or simply use the line special normally, and specify the ExtraData record number in the linedef's tag, specifying only the arguments inside the ExtraData record.

====Note====
As of EE 3.37.00, thing type 9303 is available, which is similar to the ZDoom damaging polyobject type.

==Moving PolyObjects==

There are two types of basic motion which PolyObjects can currently undergo: translation and rotation. Using "override" actions, it is possible to combine the two to have a PolyObject which rotates while moving in the xy plane.

[[File:Polyobject_rotating.gif]]

===Translating PolyObjects===

To move a PolyObject in the xy plane, use one of the following line specials:
* <code>Polyobj_Move('''polyobj_id''', '''speed''', '''angle''', '''dist''')</code>
* <code>Polyobj_OR_Move('''polyobj_id''', '''speed''', '''angle''', '''dist''')</code>

Both of these line specials use the same arguments:
* ''polyobj_id'' : Specifies which PolyObject to intially move. If the object is already moving, nothing will happen unless the action is Polyobj_OR_Move. If this object has a mirror, the same action will be recursively applied to every mirror PolyObject, reversing the angle of movement for each subsequent mirror.
* ''speed'' : Speed of the motion in eighths of a unit per tic.
* ''angle'' : Byte angle specifying the direction of motion. To convert from degrees to byte angles, use this formula: byteangle = (degrees * 256) / 360. Round or chop the result to an integer. 0 means East, 64 means North, 128 means West, and 192 means South.
* ''dist'' : The total distance to move the object in units.

All PolyObjects will inflict thrust on objects which block them with force proportional to the speed of motion. If the PolyObject was spawned with the EEPolyObjSpawnSpotCrush object (DoomEd num 9302), then if the object does not fit at the location it is being pushed toward, it will be damaged 3 hitpoints per tic (105 damage per second).

===Rotating PolyObjects===

To rotate a PolyObject, use one of the following line specials:
* <code>Polyobj_RotateRight('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_OR_RotateRight('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_RotateLeft('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_OR_RotateLeft('''polyobj_id''', '''aspeed''', '''adist''')</code>

All these line specials use the same arguments:
* ''polyobj_id'' : Specifies which PolyObject to initially rotate. If the object is already moving, nothing will happen unless the action is Polyobj_OR_RotateRight or Polyobj_OR_RotateLeft. If this object has a mirror, the same action will be recursively applied to every mirror PolyObject, reversing the direction of rotation for each subsequent mirror.
* ''aspeed'' : Angular speed of the rotation in byte angles per tic. Same as for the "angle" parameter to Move actions.
* ''adist'' : Angular distance to rotate in byte angles. Same as for aspeed, except with two special caveats:

The byte angle value 0 (zero) means to rotate exactly 360 degrees.

The byte angle value 255 means to rotate perpetually. This type of action never ends and thus only override actions can subsequently be applied to the PolyObject.

===PolyObject Examples===
====[https://s3-eu-west-1.amazonaws.com/eternity/polyobjects.wad PolyObject Demo]====
A demonstration of both rotating and translating PolyObjects. Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]).

It is recommended that you open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' and '''ACS''' scripts together with provided comments. For example this script explains how LineDefs are configured for a manually operated rotating PolyObject:

<pre>
//===============================
//= MANUALLY ROTATING POLYOBJECT
//=============================

// This PolyObject doesn't move unless activated by a a nearby switch.
linedef {
recordnum = 2
special = PolyObj_StartLine
args = { 2 }
}

linedef {
recordnum = 3
extflags = "use player" // Defines how the LineDef action is activated.
// The lack of "repeat" flag means it's a one-time
// action.

special = Polyobj_RotateRight
args = { 2, 2, 255 } // Starts Rotating PolyObject with PolyID: 2
// at a speed of 2 units and angular distance
// of 255 units - which means it'll rotate
// continuously.
} (...)
</pre>

====[https://s3-eu-west-1.amazonaws.com/eternity/polyobjects_adv.wad PolyObject Advanced Demo]====
A demonstration of rotating and translating PolyObjects made with <code>PolyObj_ExplicitLine()</code> Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]). It shows how more advanced PolyObjects can be constructed and moved to fake 3D objects.

It is recommended that you play go through the first Demo in the series and open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' and '''ACS''' scripts together with provided comments.

==PolyObject Doors==
There are two distinct types of actions provided to allow PolyObjects to function as doors: swinging and sliding. There are no override versions of door actions, and applying other overrides to currently moving PolyObject doors will most likely cause the doors to malfunction and move erratically.

All PolyObject doors accept a delay parameter, and this specifies the amount of time the door will wait before closing. A door which is closing will reopen if blocked by an object.

===Swinging PolyObject Door===
{| class="wikitable"
|-
| [[Image:Poly_swingdoor_schema.png|200px]] || [[Image:Poly_swigning_door.gif]]
|-
| PolyObject swinging door schema || PolyObject swinging door
|}

<code>Polyobj_DoorSwing ('''polyobj_id''', '''aspeed''', '''adist''', '''delay''')</code>

This action creates a swinging door from a PolyObject and takes the following arguments:
:* ''polyobj_id'' : The ID number of PolyObject to affect. Mirroring works for doors as well and is the most common use for PolyObject mirroring.
:* ''aspeed'' : Angular speed in byte angles per tic.
:* ''adist'' : Angular distance to rotate when opening, and again but in the opposite direction when closing.
:* ''delay'' : Amount of time before the door attempts to close after fully opening in tics. If the door is forced to reopen due to being blocked, it will also wait this amount of time before once again closing.
Swinging doors currently only rotate left. A right-rotating swinging door special will be added in the near future.

===Sliding PolyObject Door===
{| class="wikitable"
|-
| [[Image:Poly_slidedoor_schema.png|200px]] || [[Image:Poly_sliding_door.gif|180px]]
|-
| PolyObject sliding door schema || PolyObject sliding door
|}

<code>Polyobj_DoorSlide ('''polyobj_id''', '''speed''', '''angle''', '''dist''', '''delay''')</code>

:This action creates a sliding door from a PolyObject and takes the following arguments:
:* ''polyobj_id'' : The ID number of PolyObject to affect. Mirroring works for doors as well and is the most common use for PolyObject mirroring.
:* ''speed'' : Speed of the door's opening and closing in eighths of a unit per tic.
:* ''angle'' : Byte angle of door's initial motion. This angle is reversed when the door closes.
:* ''dist'' : Distance the door moves when opening, and again when closing, in units.
:* ''delay'' : Amount of time before the door attempts to close after fully opening in tics. If the door is forced to reopen due to being blocked, it will also wait this amount of time before once again closing.

===PolyObject Door Examples===
====[https://s3-eu-west-1.amazonaws.com/eternity/polyobj_doors.wad PolyObject Doors Demo]====
A demonstration of both swinging and sliding doors, mirrored and single. Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]).

It is recommended that you open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' scripts together with provided comments. For example the first script explains how LineDefs are configured for a single swinging door:

<pre>
//=============================
//= BASIC SINGLE SWINGING DOOR
//===========================
linedef {
recordnum = 1 // corresponds to a LineDef with action: 270, tag: 1

special = PolyObj_StartLine // this defines the current LineDef as a
// starting point for the PolyObject

args = { 1 } // since this is a very basic PolyObj, it requires only one
// argument (it's not to be confused with LineDef / Sector tag)
}

linedef {
recordnum = 2 // corresponds to a LineDef with action: 270, tag: 2

extflags = "use player repeat" // describes how the LineDef is activated

special = PolyObj_DoorSwing
args = { 1,20,64,160 } // swing the door with PolyId: 1, AngularSpeed: 20
// AngularDeistance 64 units (90 deg),
// Delay: 160 tics
} (...)
</pre>

[[category:Editing reference]]

File:Polyobjects basic.png

2013-02-10T18:06:29Z

Ellmo: uploaded a new version of "File:Polyobjects basic.png"

File:Polyobjects basic.png

2013-02-10T18:05:24Z

Ellmo: uploaded a new version of "File:Polyobjects basic.png"

File:Polyobjects adv.png

2013-02-10T18:04:31Z

Ellmo: uploaded a new version of "File:Polyobjects adv.png"

Polyobject

2013-02-10T17:51:48Z

Ellmo: /* PolyObject Advanced Demo */

PolyObjects are special sets of one-sided linedefs which, unlike any other lines, can be moved on the map during gameplay. Unlike the Hexen and ZDoom implementation of PolyObjects, Eternity does not restrict these objects to one per subsector, and they are also allowed to move any distance from their spawn point, even across subsector boundaries.

PolyObjects fully clip normal objects such as the player and enemies, optionally doing crushing damage depending upon the type of spawn spot used. They also block bullet tracers and monsters' lines of sight. They do not, however, clip sound propagation, so it may be necessary to use sound blocking lines near areas where PolyObjects are meant to function as a normal wall until they move.

Although Eternity does allow PolyObjects to move between different subsectors, this will only work properly if the subsectors on both sides of a line have the same properties (floor & ceiling heights, light level, and flat). However, since the implementation of [[dynaseg]]s, Eternity does not require a "PolyObject-aware" node builder.

Finally, unlike ZDoom, Eternity allows PolyObjects to be used in DOOM-format maps via the use of [[ExtraData]]. See the subsections below for more information on how to create and move PolyObjects.
{{Backto|Linedef types}}

==Creating PolyObjects==

PolyObjects are a combination of a set of 1S lines, which are typically placed in a "control sector" area outside of the main map, and exactly two mapthings: one spawn spot, and one anchor point. There are two different methods for grouping lines into a PolyObject.

*'''Method 1: The ''Polyobj_StartLine'' Special'''

:The Polyobj_StartLine special marks the first line in a PolyObject which is made up of a cyclic set of linedefs (that is, each line "points toward" the next line, ending at the first vertex of the first line).

:Diagrammatic Example:
[Control Sector] [Main Map Area]
+-------------------+ +-------------------------------+
| | | |
| | | | |
| +--->+ | | |
| ^ | | | |
| | |_ | | |
| A -| B | | | C |
| | v | | |
| +<---+ | | |
| | | | |
| | | |
+-------------------+ +-------------------------------+
:Assume that the linedef A is assigned the Polyobj_StartLine special and has argument #1 set to "1" -- this is its PolyObject ID number, which must be unique amongst all on the map, and must be a number greater than zero.

:Starting from line A, the engine will go from vertex to vertex, adding the first line found which shares the current line's second vertex as its first vertex. In this example, since the object is closed as is required, the process will end at the first vertex of line A, and there will be four lines in the PolyObject (note that unlike Hexen, there is NO limit to the number of lines that can be placed in one PolyObject).

:Now, once the lines are added, it is necessary to define the control objects. Points B and C are the two required objects:
:* B: This is the PolyObject's anchor point (type EEPolyObjAnchor with DoomEd #9300). It defines the point relative to which all the lines in the PolyObject will be translated to the spawn point. This object's angle must be set to the same value as the StartLine's first argument (the PolyObject ID). There must be one and only one of these objects for each PolyObject ID.
:* C: This is the PolyObject's spawn point (one of EEPolyObjSpawnSpot [9301] or EEPolyObjSpawnSpotCrush [9302]). It defines the point where the PolyObject will initially spawn on the map. The anchor point will be translated to this exact location, and all lines in the PolyObject will maintain their relative positions to it. This object must also have its angle field set to the same value as both the StartLine's first argument and the anchor point's angle field. There must be one and only one of these objects for each PolyObject ID. Use 9302 to cause the PolyObject to do crushing damage to things that block it while it is in motion.

:Note that when you use this method, the other lines belonging to the PolyObject can be given their own line specials, including ones which affect the PolyObject itself. When the player presses the PolyObject, the specials will work as expected.

:The complete arguments to Polyobj_StartLine are as follows:
:* ''polyobj_id'' : the unique ID number (greater than zero) of the PolyObject
:* ''mirror_id'' : the ID number of a PolyObject that you want to mirror every action that affects this PolyObject. This number cannot be the same as the PolyObject's own ID.

:In order to use this line special in a DOOM-format map, it is necessary to use [[ExtraData]]. In that case, you must give the line you want to have the Polyobj_StartLine special the ExtraData linedef control special (#270) instead, and then specify Polyobj_StartLine and its arguments in its corresponding ExtraData linedef record.

*'''Method 2: The ''Polyobj_ExplicitLine'' Special '''

:The Polyobj_ExplicitLine special demarcates every line that will be added to a PolyObject and the exact order in which the lines will be added. This affords a bit more flexibility in the construction of PolyObjects at the price of not allowing any other line specials to be placed on the object itself.

:Diagrammatic Example:
[Control Sector] [Main Map Area]
+-------------------+ +-------------------------------+
| 2 | | |
| | | | |
| +--->+ | | |
| ^ | | | |
| | |_ 4 | | |
| 1 -| B | | | C |
| | v | | |
| +<---+ | | |
| | | | |
| 3 | | |
+-------------------+ +-------------------------------+
:Assume that the linedefs labeled 1 through 4 are assigned the Polyobj_ExplicitLine special, all have argument #1 set to "1" -- this is its PolyObject ID number, which must be unique amongst all on the map, and must be a number greater than zero -- and all have argument #2 set to the integer values 1 through 4, corresponding to their labels in the diagram.

:The game engine will search through all linedefs in the entire map for ones with the current PolyObject ID in argument #1 and a value greater than zero in argument #2. The lines will be collected and then sorted by the value in their second argument and added to the PolyObject in that order. Note that unlike Hexen, it is not necessary for the numbers in the second argument to be sequential (ie, a sequence such as { 5, 10, 15, 20 } would also work).

:Now, once the lines are added, it is necessary to define the control objects. This is exactly the same as it is for the StartLine special above.
:* B: This is the PolyObject's anchor point (type EEPolyObjAnchor with DoomEd #9300). It defines the point relative to which all the lines in the PolyObject will be translated to the spawn point. This object's angle must be set to the same value as the ExplicitLines' first argument (the PolyObject ID). There must be one and only one of these objects for each PolyObject ID.
:* C: This is the PolyObject's spawn point (one of EEPolyObjSpawnSpot [9301] or EEPolyObjSpawnSpotCrush [9302]). It defines the point where the PolyObject will initially spawn on the map. The anchor point will be translated to this exact location, and all lines in the PolyObject will maintain their relative positions to it. This object must also have its angle field set to the same value as both the ExplicitLines' first argument and the anchor point's angle field. There must be one and only one of these objects for each PolyObject ID. Use 9302 to cause the PolyObject to do crushing damage to things that block it while it is in motion.

:The complete arguments to Polyobj_ExplicitLine are as follows:
:* ''polyobj_id'' : the unique ID number (greater than zero) of the PolyObject
:* ''number'' : specifies the order in which the line will be added to the PolyObject. This number should be unique amongst all lines to be added to the same object, and must be a value greater than zero.
:* ''mirror_id'' : the ID number of a PolyObject that you want to mirror every action that affects this PolyObject. This number cannot be the same as the PolyObject's own ID.

:In order to use this line special in a DOOM-format map, it is necessary to use ExtraData. In that case, you can either give the lines you want to have the Polyobj_ExplicitLine special the ExtraData linedef control special (#270) instead, and then specify Polyobj_ExplicitLine and its arguments in all the corresponding ExtraData linedef records; or simply use the line special normally, and specify the ExtraData record number in the linedef's tag, specifying only the arguments inside the ExtraData record.

====Note====
As of EE 3.37.00, thing type 9303 is available, which is similar to the ZDoom damaging polyobject type.

==Moving PolyObjects==

There are two types of basic motion which PolyObjects can currently undergo: translation and rotation. Using "override" actions, it is possible to combine the two to have a PolyObject which rotates while moving in the xy plane.

[[File:Polyobject_rotating.gif]]

===Translating PolyObjects===

To move a PolyObject in the xy plane, use one of the following line specials:
* <code>Polyobj_Move('''polyobj_id''', '''speed''', '''angle''', '''dist''')</code>
* <code>Polyobj_OR_Move('''polyobj_id''', '''speed''', '''angle''', '''dist''')</code>

Both of these line specials use the same arguments:
* ''polyobj_id'' : Specifies which PolyObject to intially move. If the object is already moving, nothing will happen unless the action is Polyobj_OR_Move. If this object has a mirror, the same action will be recursively applied to every mirror PolyObject, reversing the angle of movement for each subsequent mirror.
* ''speed'' : Speed of the motion in eighths of a unit per tic.
* ''angle'' : Byte angle specifying the direction of motion. To convert from degrees to byte angles, use this formula: byteangle = (degrees * 256) / 360. Round or chop the result to an integer. 0 means East, 64 means North, 128 means West, and 192 means South.
* ''dist'' : The total distance to move the object in units.

All PolyObjects will inflict thrust on objects which block them with force proportional to the speed of motion. If the PolyObject was spawned with the EEPolyObjSpawnSpotCrush object (DoomEd num 9302), then if the object does not fit at the location it is being pushed toward, it will be damaged 3 hitpoints per tic (105 damage per second).

===Rotating PolyObjects===

To rotate a PolyObject, use one of the following line specials:
* <code>Polyobj_RotateRight('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_OR_RotateRight('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_RotateLeft('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_OR_RotateLeft('''polyobj_id''', '''aspeed''', '''adist''')</code>

All these line specials use the same arguments:
* ''polyobj_id'' : Specifies which PolyObject to initially rotate. If the object is already moving, nothing will happen unless the action is Polyobj_OR_RotateRight or Polyobj_OR_RotateLeft. If this object has a mirror, the same action will be recursively applied to every mirror PolyObject, reversing the direction of rotation for each subsequent mirror.
* ''aspeed'' : Angular speed of the rotation in byte angles per tic. Same as for the "angle" parameter to Move actions.
* ''adist'' : Angular distance to rotate in byte angles. Same as for aspeed, except with two special caveats:

The byte angle value 0 (zero) means to rotate exactly 360 degrees.

The byte angle value 255 means to rotate perpetually. This type of action never ends and thus only override actions can subsequently be applied to the PolyObject.

===PolyObject Examples===
====[https://s3-eu-west-1.amazonaws.com/eternity/polyobjects.wad PolyObject Demo]====
A demonstration of both rotating and translating PolyObjects. Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]).

It is recommended that you open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' and '''ACS''' scripts together with provided comments. For example this script explains how LineDefs are configured for a manually operated rotating PolyObject:

<pre>
//===============================
//= MANUALLY ROTATING POLYOBJECT
//=============================

// This PolyObject doesn't move unless activated by a a nearby switch.
linedef {
recordnum = 2
special = PolyObj_StartLine
args = { 2 }
}

linedef {
recordnum = 3
extflags = "use player" // Defines how the LineDef action is activated.
// The lack of "repeat" flag means it's a one-time
// action.

special = Polyobj_RotateRight
args = { 2, 2, 255 } // Starts Rotating PolyObject with PolyID: 2
// at a speed of 2 units and angular distance
// of 255 units - which means it'll rotate
// continuously.
} (...)
</pre>

====[https://s3-eu-west-1.amazonaws.com/eternity/polyobjects_adv.wad PolyObject Advanced Demo]====
A demonstration of rotating and translating PolyObjects made with <code>PolyObj_ExplicitLine()</code> Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]). It shows how more advanced PolyObjects can be constructed and moved to fake 3D objects.

It is recommended that you play go through the first Demo in the series and open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' and '''ACS''' scripts together with provided comments.

==PolyObject Doors==
There are two distinct types of actions provided to allow PolyObjects to function as doors: swinging and sliding. There are no override versions of door actions, and applying other overrides to currently moving PolyObject doors will most likely cause the doors to malfunction and move erratically.

All PolyObject doors accept a delay parameter, and this specifies the amount of time the door will wait before closing. A door which is closing will reopen if blocked by an object.

===Swinging PolyObject Door===
{| class="wikitable"
|-
| [[Image:Poly_swingdoor_schema.png|200px]] || [[Image:Poly_swigning_door.gif]]
|-
| PolyObject swinging door schema || PolyObject swinging door
|}

<code>Polyobj_DoorSwing ('''polyobj_id''', '''aspeed''', '''adist''', '''delay''')</code>

This action creates a swinging door from a PolyObject and takes the following arguments:
:* ''polyobj_id'' : The ID number of PolyObject to affect. Mirroring works for doors as well and is the most common use for PolyObject mirroring.
:* ''aspeed'' : Angular speed in byte angles per tic.
:* ''adist'' : Angular distance to rotate when opening, and again but in the opposite direction when closing.
:* ''delay'' : Amount of time before the door attempts to close after fully opening in tics. If the door is forced to reopen due to being blocked, it will also wait this amount of time before once again closing.
Swinging doors currently only rotate left. A right-rotating swinging door special will be added in the near future.

===Sliding PolyObject Door===
{| class="wikitable"
|-
| [[Image:Poly_slidedoor_schema.png|200px]] || [[Image:Poly_sliding_door.gif|180px]]
|-
| PolyObject sliding door schema || PolyObject sliding door
|}

<code>Polyobj_DoorSlide ('''polyobj_id''', '''speed''', '''angle''', '''dist''', '''delay''')</code>

:This action creates a sliding door from a PolyObject and takes the following arguments:
:* ''polyobj_id'' : The ID number of PolyObject to affect. Mirroring works for doors as well and is the most common use for PolyObject mirroring.
:* ''speed'' : Speed of the door's opening and closing in eighths of a unit per tic.
:* ''angle'' : Byte angle of door's initial motion. This angle is reversed when the door closes.
:* ''dist'' : Distance the door moves when opening, and again when closing, in units.
:* ''delay'' : Amount of time before the door attempts to close after fully opening in tics. If the door is forced to reopen due to being blocked, it will also wait this amount of time before once again closing.

===PolyObject Door Examples===
====[https://s3-eu-west-1.amazonaws.com/eternity/polyobj_doors.wad PolyObject Doors Demo]====
A demonstration of both swinging and sliding doors, mirrored and single. Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]).

It is recommended that you open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' scripts together with provided comments. For example the first script explains how LineDefs are configured for a single swinging door:

<pre>
//=============================
//= BASIC SINGLE SWINGING DOOR
//===========================
linedef {
recordnum = 1 // corresponds to a LineDef with action: 270, tag: 1

special = PolyObj_StartLine // this defines the current LineDef as a
// starting point for the PolyObject

args = { 1 } // since this is a very basic PolyObj, it requires only one
// argument (it's not to be confused with LineDef / Sector tag)
}

linedef {
recordnum = 2 // corresponds to a LineDef with action: 270, tag: 2

extflags = "use player repeat" // describes how the LineDef is activated

special = PolyObj_DoorSwing
args = { 1,20,64,160 } // swing the door with PolyId: 1, AngularSpeed: 20
// AngularDeistance 64 units (90 deg),
// Delay: 160 tics
} (...)
</pre>

[[category:Editing reference]]

Polyobject

2013-02-10T17:51:16Z

Ellmo: /* https://s3-eu-west-1.amazonaws.com/eternity/polyobjects_adv.wad PolyObject Advanced Demo */

PolyObjects are special sets of one-sided linedefs which, unlike any other lines, can be moved on the map during gameplay. Unlike the Hexen and ZDoom implementation of PolyObjects, Eternity does not restrict these objects to one per subsector, and they are also allowed to move any distance from their spawn point, even across subsector boundaries.

PolyObjects fully clip normal objects such as the player and enemies, optionally doing crushing damage depending upon the type of spawn spot used. They also block bullet tracers and monsters' lines of sight. They do not, however, clip sound propagation, so it may be necessary to use sound blocking lines near areas where PolyObjects are meant to function as a normal wall until they move.

Although Eternity does allow PolyObjects to move between different subsectors, this will only work properly if the subsectors on both sides of a line have the same properties (floor & ceiling heights, light level, and flat). However, since the implementation of [[dynaseg]]s, Eternity does not require a "PolyObject-aware" node builder.

Finally, unlike ZDoom, Eternity allows PolyObjects to be used in DOOM-format maps via the use of [[ExtraData]]. See the subsections below for more information on how to create and move PolyObjects.
{{Backto|Linedef types}}

==Creating PolyObjects==

PolyObjects are a combination of a set of 1S lines, which are typically placed in a "control sector" area outside of the main map, and exactly two mapthings: one spawn spot, and one anchor point. There are two different methods for grouping lines into a PolyObject.

*'''Method 1: The ''Polyobj_StartLine'' Special'''

:The Polyobj_StartLine special marks the first line in a PolyObject which is made up of a cyclic set of linedefs (that is, each line "points toward" the next line, ending at the first vertex of the first line).

:Diagrammatic Example:
[Control Sector] [Main Map Area]
+-------------------+ +-------------------------------+
| | | |
| | | | |
| +--->+ | | |
| ^ | | | |
| | |_ | | |
| A -| B | | | C |
| | v | | |
| +<---+ | | |
| | | | |
| | | |
+-------------------+ +-------------------------------+
:Assume that the linedef A is assigned the Polyobj_StartLine special and has argument #1 set to "1" -- this is its PolyObject ID number, which must be unique amongst all on the map, and must be a number greater than zero.

:Starting from line A, the engine will go from vertex to vertex, adding the first line found which shares the current line's second vertex as its first vertex. In this example, since the object is closed as is required, the process will end at the first vertex of line A, and there will be four lines in the PolyObject (note that unlike Hexen, there is NO limit to the number of lines that can be placed in one PolyObject).

:Now, once the lines are added, it is necessary to define the control objects. Points B and C are the two required objects:
:* B: This is the PolyObject's anchor point (type EEPolyObjAnchor with DoomEd #9300). It defines the point relative to which all the lines in the PolyObject will be translated to the spawn point. This object's angle must be set to the same value as the StartLine's first argument (the PolyObject ID). There must be one and only one of these objects for each PolyObject ID.
:* C: This is the PolyObject's spawn point (one of EEPolyObjSpawnSpot [9301] or EEPolyObjSpawnSpotCrush [9302]). It defines the point where the PolyObject will initially spawn on the map. The anchor point will be translated to this exact location, and all lines in the PolyObject will maintain their relative positions to it. This object must also have its angle field set to the same value as both the StartLine's first argument and the anchor point's angle field. There must be one and only one of these objects for each PolyObject ID. Use 9302 to cause the PolyObject to do crushing damage to things that block it while it is in motion.

:Note that when you use this method, the other lines belonging to the PolyObject can be given their own line specials, including ones which affect the PolyObject itself. When the player presses the PolyObject, the specials will work as expected.

:The complete arguments to Polyobj_StartLine are as follows:
:* ''polyobj_id'' : the unique ID number (greater than zero) of the PolyObject
:* ''mirror_id'' : the ID number of a PolyObject that you want to mirror every action that affects this PolyObject. This number cannot be the same as the PolyObject's own ID.

:In order to use this line special in a DOOM-format map, it is necessary to use [[ExtraData]]. In that case, you must give the line you want to have the Polyobj_StartLine special the ExtraData linedef control special (#270) instead, and then specify Polyobj_StartLine and its arguments in its corresponding ExtraData linedef record.

*'''Method 2: The ''Polyobj_ExplicitLine'' Special '''

:The Polyobj_ExplicitLine special demarcates every line that will be added to a PolyObject and the exact order in which the lines will be added. This affords a bit more flexibility in the construction of PolyObjects at the price of not allowing any other line specials to be placed on the object itself.

:Diagrammatic Example:
[Control Sector] [Main Map Area]
+-------------------+ +-------------------------------+
| 2 | | |
| | | | |
| +--->+ | | |
| ^ | | | |
| | |_ 4 | | |
| 1 -| B | | | C |
| | v | | |
| +<---+ | | |
| | | | |
| 3 | | |
+-------------------+ +-------------------------------+
:Assume that the linedefs labeled 1 through 4 are assigned the Polyobj_ExplicitLine special, all have argument #1 set to "1" -- this is its PolyObject ID number, which must be unique amongst all on the map, and must be a number greater than zero -- and all have argument #2 set to the integer values 1 through 4, corresponding to their labels in the diagram.

:The game engine will search through all linedefs in the entire map for ones with the current PolyObject ID in argument #1 and a value greater than zero in argument #2. The lines will be collected and then sorted by the value in their second argument and added to the PolyObject in that order. Note that unlike Hexen, it is not necessary for the numbers in the second argument to be sequential (ie, a sequence such as { 5, 10, 15, 20 } would also work).

:Now, once the lines are added, it is necessary to define the control objects. This is exactly the same as it is for the StartLine special above.
:* B: This is the PolyObject's anchor point (type EEPolyObjAnchor with DoomEd #9300). It defines the point relative to which all the lines in the PolyObject will be translated to the spawn point. This object's angle must be set to the same value as the ExplicitLines' first argument (the PolyObject ID). There must be one and only one of these objects for each PolyObject ID.
:* C: This is the PolyObject's spawn point (one of EEPolyObjSpawnSpot [9301] or EEPolyObjSpawnSpotCrush [9302]). It defines the point where the PolyObject will initially spawn on the map. The anchor point will be translated to this exact location, and all lines in the PolyObject will maintain their relative positions to it. This object must also have its angle field set to the same value as both the ExplicitLines' first argument and the anchor point's angle field. There must be one and only one of these objects for each PolyObject ID. Use 9302 to cause the PolyObject to do crushing damage to things that block it while it is in motion.

:The complete arguments to Polyobj_ExplicitLine are as follows:
:* ''polyobj_id'' : the unique ID number (greater than zero) of the PolyObject
:* ''number'' : specifies the order in which the line will be added to the PolyObject. This number should be unique amongst all lines to be added to the same object, and must be a value greater than zero.
:* ''mirror_id'' : the ID number of a PolyObject that you want to mirror every action that affects this PolyObject. This number cannot be the same as the PolyObject's own ID.

:In order to use this line special in a DOOM-format map, it is necessary to use ExtraData. In that case, you can either give the lines you want to have the Polyobj_ExplicitLine special the ExtraData linedef control special (#270) instead, and then specify Polyobj_ExplicitLine and its arguments in all the corresponding ExtraData linedef records; or simply use the line special normally, and specify the ExtraData record number in the linedef's tag, specifying only the arguments inside the ExtraData record.

====Note====
As of EE 3.37.00, thing type 9303 is available, which is similar to the ZDoom damaging polyobject type.

==Moving PolyObjects==

There are two types of basic motion which PolyObjects can currently undergo: translation and rotation. Using "override" actions, it is possible to combine the two to have a PolyObject which rotates while moving in the xy plane.

[[File:Polyobject_rotating.gif]]

===Translating PolyObjects===

To move a PolyObject in the xy plane, use one of the following line specials:
* <code>Polyobj_Move('''polyobj_id''', '''speed''', '''angle''', '''dist''')</code>
* <code>Polyobj_OR_Move('''polyobj_id''', '''speed''', '''angle''', '''dist''')</code>

Both of these line specials use the same arguments:
* ''polyobj_id'' : Specifies which PolyObject to intially move. If the object is already moving, nothing will happen unless the action is Polyobj_OR_Move. If this object has a mirror, the same action will be recursively applied to every mirror PolyObject, reversing the angle of movement for each subsequent mirror.
* ''speed'' : Speed of the motion in eighths of a unit per tic.
* ''angle'' : Byte angle specifying the direction of motion. To convert from degrees to byte angles, use this formula: byteangle = (degrees * 256) / 360. Round or chop the result to an integer. 0 means East, 64 means North, 128 means West, and 192 means South.
* ''dist'' : The total distance to move the object in units.

All PolyObjects will inflict thrust on objects which block them with force proportional to the speed of motion. If the PolyObject was spawned with the EEPolyObjSpawnSpotCrush object (DoomEd num 9302), then if the object does not fit at the location it is being pushed toward, it will be damaged 3 hitpoints per tic (105 damage per second).

===Rotating PolyObjects===

To rotate a PolyObject, use one of the following line specials:
* <code>Polyobj_RotateRight('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_OR_RotateRight('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_RotateLeft('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_OR_RotateLeft('''polyobj_id''', '''aspeed''', '''adist''')</code>

All these line specials use the same arguments:
* ''polyobj_id'' : Specifies which PolyObject to initially rotate. If the object is already moving, nothing will happen unless the action is Polyobj_OR_RotateRight or Polyobj_OR_RotateLeft. If this object has a mirror, the same action will be recursively applied to every mirror PolyObject, reversing the direction of rotation for each subsequent mirror.
* ''aspeed'' : Angular speed of the rotation in byte angles per tic. Same as for the "angle" parameter to Move actions.
* ''adist'' : Angular distance to rotate in byte angles. Same as for aspeed, except with two special caveats:

The byte angle value 0 (zero) means to rotate exactly 360 degrees.

The byte angle value 255 means to rotate perpetually. This type of action never ends and thus only override actions can subsequently be applied to the PolyObject.

===PolyObject Examples===
====[https://s3-eu-west-1.amazonaws.com/eternity/polyobjects.wad PolyObject Demo]====
A demonstration of both rotating and translating PolyObjects. Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]).

It is recommended that you open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' and '''ACS''' scripts together with provided comments. For example this script explains how LineDefs are configured for a manually operated rotating PolyObject:

<pre>
//===============================
//= MANUALLY ROTATING POLYOBJECT
//=============================

// This PolyObject doesn't move unless activated by a a nearby switch.
linedef {
recordnum = 2
special = PolyObj_StartLine
args = { 2 }
}

linedef {
recordnum = 3
extflags = "use player" // Defines how the LineDef action is activated.
// The lack of "repeat" flag means it's a one-time
// action.

special = Polyobj_RotateRight
args = { 2, 2, 255 } // Starts Rotating PolyObject with PolyID: 2
// at a speed of 2 units and angular distance
// of 255 units - which means it'll rotate
// continuously.
} (...)
</pre>

===[https://s3-eu-west-1.amazonaws.com/eternity/polyobjects_adv.wad PolyObject Advanced Demo]===
A demonstration of rotating and translating PolyObjects made with <code>PolyObj_ExplicitLine()</code> Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]). It shows how more advanced PolyObjects can be constructed and moved to fake 3D objects.

It is recommended that you play go through the first Demo in the series and open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' and '''ACS''' scripts together with provided comments.

==PolyObject Doors==
There are two distinct types of actions provided to allow PolyObjects to function as doors: swinging and sliding. There are no override versions of door actions, and applying other overrides to currently moving PolyObject doors will most likely cause the doors to malfunction and move erratically.

All PolyObject doors accept a delay parameter, and this specifies the amount of time the door will wait before closing. A door which is closing will reopen if blocked by an object.

===Swinging PolyObject Door===
{| class="wikitable"
|-
| [[Image:Poly_swingdoor_schema.png|200px]] || [[Image:Poly_swigning_door.gif]]
|-
| PolyObject swinging door schema || PolyObject swinging door
|}

<code>Polyobj_DoorSwing ('''polyobj_id''', '''aspeed''', '''adist''', '''delay''')</code>

This action creates a swinging door from a PolyObject and takes the following arguments:
:* ''polyobj_id'' : The ID number of PolyObject to affect. Mirroring works for doors as well and is the most common use for PolyObject mirroring.
:* ''aspeed'' : Angular speed in byte angles per tic.
:* ''adist'' : Angular distance to rotate when opening, and again but in the opposite direction when closing.
:* ''delay'' : Amount of time before the door attempts to close after fully opening in tics. If the door is forced to reopen due to being blocked, it will also wait this amount of time before once again closing.
Swinging doors currently only rotate left. A right-rotating swinging door special will be added in the near future.

===Sliding PolyObject Door===
{| class="wikitable"
|-
| [[Image:Poly_slidedoor_schema.png|200px]] || [[Image:Poly_sliding_door.gif|180px]]
|-
| PolyObject sliding door schema || PolyObject sliding door
|}

<code>Polyobj_DoorSlide ('''polyobj_id''', '''speed''', '''angle''', '''dist''', '''delay''')</code>

:This action creates a sliding door from a PolyObject and takes the following arguments:
:* ''polyobj_id'' : The ID number of PolyObject to affect. Mirroring works for doors as well and is the most common use for PolyObject mirroring.
:* ''speed'' : Speed of the door's opening and closing in eighths of a unit per tic.
:* ''angle'' : Byte angle of door's initial motion. This angle is reversed when the door closes.
:* ''dist'' : Distance the door moves when opening, and again when closing, in units.
:* ''delay'' : Amount of time before the door attempts to close after fully opening in tics. If the door is forced to reopen due to being blocked, it will also wait this amount of time before once again closing.

===PolyObject Door Examples===
====[https://s3-eu-west-1.amazonaws.com/eternity/polyobj_doors.wad PolyObject Doors Demo]====
A demonstration of both swinging and sliding doors, mirrored and single. Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]).

It is recommended that you open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' scripts together with provided comments. For example the first script explains how LineDefs are configured for a single swinging door:

<pre>
//=============================
//= BASIC SINGLE SWINGING DOOR
//===========================
linedef {
recordnum = 1 // corresponds to a LineDef with action: 270, tag: 1

special = PolyObj_StartLine // this defines the current LineDef as a
// starting point for the PolyObject

args = { 1 } // since this is a very basic PolyObj, it requires only one
// argument (it's not to be confused with LineDef / Sector tag)
}

linedef {
recordnum = 2 // corresponds to a LineDef with action: 270, tag: 2

extflags = "use player repeat" // describes how the LineDef is activated

special = PolyObj_DoorSwing
args = { 1,20,64,160 } // swing the door with PolyId: 1, AngularSpeed: 20
// AngularDeistance 64 units (90 deg),
// Delay: 160 tics
} (...)
</pre>

[[category:Editing reference]]

Polyobject

2013-02-10T17:50:43Z

Ellmo: /* PolyObject Examples */

PolyObjects are special sets of one-sided linedefs which, unlike any other lines, can be moved on the map during gameplay. Unlike the Hexen and ZDoom implementation of PolyObjects, Eternity does not restrict these objects to one per subsector, and they are also allowed to move any distance from their spawn point, even across subsector boundaries.

PolyObjects fully clip normal objects such as the player and enemies, optionally doing crushing damage depending upon the type of spawn spot used. They also block bullet tracers and monsters' lines of sight. They do not, however, clip sound propagation, so it may be necessary to use sound blocking lines near areas where PolyObjects are meant to function as a normal wall until they move.

Although Eternity does allow PolyObjects to move between different subsectors, this will only work properly if the subsectors on both sides of a line have the same properties (floor & ceiling heights, light level, and flat). However, since the implementation of [[dynaseg]]s, Eternity does not require a "PolyObject-aware" node builder.

Finally, unlike ZDoom, Eternity allows PolyObjects to be used in DOOM-format maps via the use of [[ExtraData]]. See the subsections below for more information on how to create and move PolyObjects.
{{Backto|Linedef types}}

==Creating PolyObjects==

PolyObjects are a combination of a set of 1S lines, which are typically placed in a "control sector" area outside of the main map, and exactly two mapthings: one spawn spot, and one anchor point. There are two different methods for grouping lines into a PolyObject.

*'''Method 1: The ''Polyobj_StartLine'' Special'''

:The Polyobj_StartLine special marks the first line in a PolyObject which is made up of a cyclic set of linedefs (that is, each line "points toward" the next line, ending at the first vertex of the first line).

:Diagrammatic Example:
[Control Sector] [Main Map Area]
+-------------------+ +-------------------------------+
| | | |
| | | | |
| +--->+ | | |
| ^ | | | |
| | |_ | | |
| A -| B | | | C |
| | v | | |
| +<---+ | | |
| | | | |
| | | |
+-------------------+ +-------------------------------+
:Assume that the linedef A is assigned the Polyobj_StartLine special and has argument #1 set to "1" -- this is its PolyObject ID number, which must be unique amongst all on the map, and must be a number greater than zero.

:Starting from line A, the engine will go from vertex to vertex, adding the first line found which shares the current line's second vertex as its first vertex. In this example, since the object is closed as is required, the process will end at the first vertex of line A, and there will be four lines in the PolyObject (note that unlike Hexen, there is NO limit to the number of lines that can be placed in one PolyObject).

:Now, once the lines are added, it is necessary to define the control objects. Points B and C are the two required objects:
:* B: This is the PolyObject's anchor point (type EEPolyObjAnchor with DoomEd #9300). It defines the point relative to which all the lines in the PolyObject will be translated to the spawn point. This object's angle must be set to the same value as the StartLine's first argument (the PolyObject ID). There must be one and only one of these objects for each PolyObject ID.
:* C: This is the PolyObject's spawn point (one of EEPolyObjSpawnSpot [9301] or EEPolyObjSpawnSpotCrush [9302]). It defines the point where the PolyObject will initially spawn on the map. The anchor point will be translated to this exact location, and all lines in the PolyObject will maintain their relative positions to it. This object must also have its angle field set to the same value as both the StartLine's first argument and the anchor point's angle field. There must be one and only one of these objects for each PolyObject ID. Use 9302 to cause the PolyObject to do crushing damage to things that block it while it is in motion.

:Note that when you use this method, the other lines belonging to the PolyObject can be given their own line specials, including ones which affect the PolyObject itself. When the player presses the PolyObject, the specials will work as expected.

:The complete arguments to Polyobj_StartLine are as follows:
:* ''polyobj_id'' : the unique ID number (greater than zero) of the PolyObject
:* ''mirror_id'' : the ID number of a PolyObject that you want to mirror every action that affects this PolyObject. This number cannot be the same as the PolyObject's own ID.

:In order to use this line special in a DOOM-format map, it is necessary to use [[ExtraData]]. In that case, you must give the line you want to have the Polyobj_StartLine special the ExtraData linedef control special (#270) instead, and then specify Polyobj_StartLine and its arguments in its corresponding ExtraData linedef record.

*'''Method 2: The ''Polyobj_ExplicitLine'' Special '''

:The Polyobj_ExplicitLine special demarcates every line that will be added to a PolyObject and the exact order in which the lines will be added. This affords a bit more flexibility in the construction of PolyObjects at the price of not allowing any other line specials to be placed on the object itself.

:Diagrammatic Example:
[Control Sector] [Main Map Area]
+-------------------+ +-------------------------------+
| 2 | | |
| | | | |
| +--->+ | | |
| ^ | | | |
| | |_ 4 | | |
| 1 -| B | | | C |
| | v | | |
| +<---+ | | |
| | | | |
| 3 | | |
+-------------------+ +-------------------------------+
:Assume that the linedefs labeled 1 through 4 are assigned the Polyobj_ExplicitLine special, all have argument #1 set to "1" -- this is its PolyObject ID number, which must be unique amongst all on the map, and must be a number greater than zero -- and all have argument #2 set to the integer values 1 through 4, corresponding to their labels in the diagram.

:The game engine will search through all linedefs in the entire map for ones with the current PolyObject ID in argument #1 and a value greater than zero in argument #2. The lines will be collected and then sorted by the value in their second argument and added to the PolyObject in that order. Note that unlike Hexen, it is not necessary for the numbers in the second argument to be sequential (ie, a sequence such as { 5, 10, 15, 20 } would also work).

:Now, once the lines are added, it is necessary to define the control objects. This is exactly the same as it is for the StartLine special above.
:* B: This is the PolyObject's anchor point (type EEPolyObjAnchor with DoomEd #9300). It defines the point relative to which all the lines in the PolyObject will be translated to the spawn point. This object's angle must be set to the same value as the ExplicitLines' first argument (the PolyObject ID). There must be one and only one of these objects for each PolyObject ID.
:* C: This is the PolyObject's spawn point (one of EEPolyObjSpawnSpot [9301] or EEPolyObjSpawnSpotCrush [9302]). It defines the point where the PolyObject will initially spawn on the map. The anchor point will be translated to this exact location, and all lines in the PolyObject will maintain their relative positions to it. This object must also have its angle field set to the same value as both the ExplicitLines' first argument and the anchor point's angle field. There must be one and only one of these objects for each PolyObject ID. Use 9302 to cause the PolyObject to do crushing damage to things that block it while it is in motion.

:The complete arguments to Polyobj_ExplicitLine are as follows:
:* ''polyobj_id'' : the unique ID number (greater than zero) of the PolyObject
:* ''number'' : specifies the order in which the line will be added to the PolyObject. This number should be unique amongst all lines to be added to the same object, and must be a value greater than zero.
:* ''mirror_id'' : the ID number of a PolyObject that you want to mirror every action that affects this PolyObject. This number cannot be the same as the PolyObject's own ID.

:In order to use this line special in a DOOM-format map, it is necessary to use ExtraData. In that case, you can either give the lines you want to have the Polyobj_ExplicitLine special the ExtraData linedef control special (#270) instead, and then specify Polyobj_ExplicitLine and its arguments in all the corresponding ExtraData linedef records; or simply use the line special normally, and specify the ExtraData record number in the linedef's tag, specifying only the arguments inside the ExtraData record.

====Note====
As of EE 3.37.00, thing type 9303 is available, which is similar to the ZDoom damaging polyobject type.

==Moving PolyObjects==

There are two types of basic motion which PolyObjects can currently undergo: translation and rotation. Using "override" actions, it is possible to combine the two to have a PolyObject which rotates while moving in the xy plane.

[[File:Polyobject_rotating.gif]]

===Translating PolyObjects===

To move a PolyObject in the xy plane, use one of the following line specials:
* <code>Polyobj_Move('''polyobj_id''', '''speed''', '''angle''', '''dist''')</code>
* <code>Polyobj_OR_Move('''polyobj_id''', '''speed''', '''angle''', '''dist''')</code>

Both of these line specials use the same arguments:
* ''polyobj_id'' : Specifies which PolyObject to intially move. If the object is already moving, nothing will happen unless the action is Polyobj_OR_Move. If this object has a mirror, the same action will be recursively applied to every mirror PolyObject, reversing the angle of movement for each subsequent mirror.
* ''speed'' : Speed of the motion in eighths of a unit per tic.
* ''angle'' : Byte angle specifying the direction of motion. To convert from degrees to byte angles, use this formula: byteangle = (degrees * 256) / 360. Round or chop the result to an integer. 0 means East, 64 means North, 128 means West, and 192 means South.
* ''dist'' : The total distance to move the object in units.

All PolyObjects will inflict thrust on objects which block them with force proportional to the speed of motion. If the PolyObject was spawned with the EEPolyObjSpawnSpotCrush object (DoomEd num 9302), then if the object does not fit at the location it is being pushed toward, it will be damaged 3 hitpoints per tic (105 damage per second).

===Rotating PolyObjects===

To rotate a PolyObject, use one of the following line specials:
* <code>Polyobj_RotateRight('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_OR_RotateRight('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_RotateLeft('''polyobj_id''', '''aspeed''', '''adist''')</code>
* <code>Polyobj_OR_RotateLeft('''polyobj_id''', '''aspeed''', '''adist''')</code>

All these line specials use the same arguments:
* ''polyobj_id'' : Specifies which PolyObject to initially rotate. If the object is already moving, nothing will happen unless the action is Polyobj_OR_RotateRight or Polyobj_OR_RotateLeft. If this object has a mirror, the same action will be recursively applied to every mirror PolyObject, reversing the direction of rotation for each subsequent mirror.
* ''aspeed'' : Angular speed of the rotation in byte angles per tic. Same as for the "angle" parameter to Move actions.
* ''adist'' : Angular distance to rotate in byte angles. Same as for aspeed, except with two special caveats:

The byte angle value 0 (zero) means to rotate exactly 360 degrees.

The byte angle value 255 means to rotate perpetually. This type of action never ends and thus only override actions can subsequently be applied to the PolyObject.

===PolyObject Examples===
====[https://s3-eu-west-1.amazonaws.com/eternity/polyobjects.wad PolyObject Demo]====
A demonstration of both rotating and translating PolyObjects. Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]).

It is recommended that you open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' and '''ACS''' scripts together with provided comments. For example this script explains how LineDefs are configured for a manually operated rotating PolyObject:

<pre>
//===============================
//= MANUALLY ROTATING POLYOBJECT
//=============================

// This PolyObject doesn't move unless activated by a a nearby switch.
linedef {
recordnum = 2
special = PolyObj_StartLine
args = { 2 }
}

linedef {
recordnum = 3
extflags = "use player" // Defines how the LineDef action is activated.
// The lack of "repeat" flag means it's a one-time
// action.

special = Polyobj_RotateRight
args = { 2, 2, 255 } // Starts Rotating PolyObject with PolyID: 2
// at a speed of 2 units and angular distance
// of 255 units - which means it'll rotate
// continuously.
} (...)
</pre>

===https://s3-eu-west-1.amazonaws.com/eternity/polyobjects_adv.wad PolyObject Advanced Demo===
A demonstration of rotating and translating PolyObjects made with <code>PolyObj_ExplicitLine()</code> Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]). It shows how more advanced PolyObjects can be constructed and moved to fake 3D objects.

It is recommended that you play go through the first Demo in the series and open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' and '''ACS''' scripts together with provided comments.

==PolyObject Doors==
There are two distinct types of actions provided to allow PolyObjects to function as doors: swinging and sliding. There are no override versions of door actions, and applying other overrides to currently moving PolyObject doors will most likely cause the doors to malfunction and move erratically.

All PolyObject doors accept a delay parameter, and this specifies the amount of time the door will wait before closing. A door which is closing will reopen if blocked by an object.

===Swinging PolyObject Door===
{| class="wikitable"
|-
| [[Image:Poly_swingdoor_schema.png|200px]] || [[Image:Poly_swigning_door.gif]]
|-
| PolyObject swinging door schema || PolyObject swinging door
|}

<code>Polyobj_DoorSwing ('''polyobj_id''', '''aspeed''', '''adist''', '''delay''')</code>

This action creates a swinging door from a PolyObject and takes the following arguments:
:* ''polyobj_id'' : The ID number of PolyObject to affect. Mirroring works for doors as well and is the most common use for PolyObject mirroring.
:* ''aspeed'' : Angular speed in byte angles per tic.
:* ''adist'' : Angular distance to rotate when opening, and again but in the opposite direction when closing.
:* ''delay'' : Amount of time before the door attempts to close after fully opening in tics. If the door is forced to reopen due to being blocked, it will also wait this amount of time before once again closing.
Swinging doors currently only rotate left. A right-rotating swinging door special will be added in the near future.

===Sliding PolyObject Door===
{| class="wikitable"
|-
| [[Image:Poly_slidedoor_schema.png|200px]] || [[Image:Poly_sliding_door.gif|180px]]
|-
| PolyObject sliding door schema || PolyObject sliding door
|}

<code>Polyobj_DoorSlide ('''polyobj_id''', '''speed''', '''angle''', '''dist''', '''delay''')</code>

:This action creates a sliding door from a PolyObject and takes the following arguments:
:* ''polyobj_id'' : The ID number of PolyObject to affect. Mirroring works for doors as well and is the most common use for PolyObject mirroring.
:* ''speed'' : Speed of the door's opening and closing in eighths of a unit per tic.
:* ''angle'' : Byte angle of door's initial motion. This angle is reversed when the door closes.
:* ''dist'' : Distance the door moves when opening, and again when closing, in units.
:* ''delay'' : Amount of time before the door attempts to close after fully opening in tics. If the door is forced to reopen due to being blocked, it will also wait this amount of time before once again closing.

===PolyObject Door Examples===
====[https://s3-eu-west-1.amazonaws.com/eternity/polyobj_doors.wad PolyObject Doors Demo]====
A demonstration of both swinging and sliding doors, mirrored and single. Plays on '''Doom 2''' / '''Map01'''. The map is linked to an [[ExtraData]] lump (via [[EMAPINFO]]).

It is recommended that you open the Demo WAD in a WAD manager program like '''SLADE3''' or '''XWE''' to read the '''ExtraData''' scripts together with provided comments. For example the first script explains how LineDefs are configured for a single swinging door:

<pre>
//=============================
//= BASIC SINGLE SWINGING DOOR
//===========================
linedef {
recordnum = 1 // corresponds to a LineDef with action: 270, tag: 1

special = PolyObj_StartLine // this defines the current LineDef as a
// starting point for the PolyObject

args = { 1 } // since this is a very basic PolyObj, it requires only one
// argument (it's not to be confused with LineDef / Sector tag)
}

linedef {
recordnum = 2 // corresponds to a LineDef with action: 270, tag: 2

extflags = "use player repeat" // describes how the LineDef is activated

special = PolyObj_DoorSwing
args = { 1,20,64,160 } // swing the door with PolyId: 1, AngularSpeed: 20
// AngularDeistance 64 units (90 deg),
// Delay: 160 tics
} (...)
</pre>

[[category:Editing reference]]

File:Polyobjects adv.png

2013-02-10T17:48:35Z

Ellmo:

File:Polyobjects basic.png

2013-02-10T17:47:11Z

Ellmo:

Linked portal

2013-02-10T01:15:57Z

Ellmo: /* demo file */

'''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.
{{backto|Portal linedef types}}

==Screenshots==
{| class="wikitable"
|-
| [[File:Linked_portals_bottom.png|320px]] || [[File:Linked_portals_top.png|320px]]
|-
| 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

==Terminology==
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.

==Usage==
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.

==Setup==

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 /::::::::::::::::::
:::::::::::::::::x-------------x-------x:::::::::::::::::::::::::::::::::::::::x-------------x-------x:::::::::::::::::::
:::::::::::::::::::::::::::::::::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.

==Tutorial==
Refer to Zarkyb's [[linked portals tutorial]] for more examples on usage.

==Examples==
===[https://s3-eu-west-1.amazonaws.com/eternity/linked_port.wad Linked Portals Demo]===
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.

[[File:Linked_portals.png]]

[[Category:Editing]]
[[Category:Editing reference]]

Linked portal

2013-02-10T01:15:33Z

Ellmo: /* Examples */

'''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.
{{backto|Portal linedef types}}

==Screenshots==
{| class="wikitable"
|-
| [[File:Linked_portals_bottom.png|320px]] || [[File:Linked_portals_top.png|320px]]
|-
| 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

==Terminology==
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.

==Usage==
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.

==Setup==

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 /::::::::::::::::::
:::::::::::::::::x-------------x-------x:::::::::::::::::::::::::::::::::::::::x-------------x-------x:::::::::::::::::::
:::::::::::::::::::::::::::::::::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.

==Tutorial==
Refer to Zarkyb's [[linked portals tutorial]] for more examples on usage.

==Examples==
===[https://s3-eu-west-1.amazonaws.com/eternity/linked_port.wad 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.

[[File:Linked_portals.png]]

[[Category:Editing]]
[[Category:Editing reference]]

Polyobject

2013-02-08T21:49:30Z

Ellmo: Linked portals schema.

Linked portals schema.

File:Linked portals 2.png

2013-02-08T21:47:52Z

Ellmo: Linked portals schema.

Linked portals schema.