Attached surface linedef types: Difference between revisions

From Eternity Wiki
Jump to navigationJump to search
(→‎Using attached surfaces with linked portals: maybe discretion is better though.)
(Added UDMF mirrored movement example)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
Attached surfaces cause multiple sectors to move together. This allows for the creation of complex lifts, doors, or elevators comprised of multiple sectors which will remain synchronized even if any sector's movement is blocked by a player or other object.  
Attached surfaces cause multiple sectors to move together. This allows for the creation of complex lifts, doors, or elevators comprised of multiple sectors which will remain synchronized even if any sector's movement is blocked by a player or other object.  
One sector is the "control", which the attached surfaces will move in sync with. The control can either be inside the map or a dummy sector outside of it.
By use of the mirror attachments you can, for example, attach a ceiling to the mirrored movement of a floor, to create a split door which opens from the middle.
{{Backto|Linedef types}}
{{Backto|Linedef types}}
== UDMF format ==
UDMF format doesn't use linedef types, but the '''floorid''', '''ceilingid''', '''attachfloor''' and '''attachceiling'''. They use IDs separate from the sector or linedef tags, equivalent to the linedef tags used in the classic format for this purpose.
For mirrored movement, use negative values of IDs in '''attachfloor''' and '''attachceiling'''. So if a master sector's ceiling moves up and a slave sector's floor will move down, set the '''ceilingid''' of master to 1 and the '''attachfloor''' value of slave to -1.
== Classic format ==


Attached surface linedefs are as follows:
Attached surface linedefs are as follows:
Line 16: Line 29:
* 384 -- Attach_MirrorCeilingToControl
* 384 -- Attach_MirrorCeilingToControl
:The sector on the front side of this line will have its ceiling movement controlled inversely by the surface whose control line shares this line's tag.
:The sector on the front side of this line will have its ceiling movement controlled inversely by the surface whose control line shares this line's tag.
For example, put an Attach_SetFloorControl special on a line with its front side facing the control sector and give it a tag. Then put Attach_FloorToControl specials on lines facing all the sectors to be attached to it.


==Using attached surfaces with linked portals==
==Using attached surfaces with linked portals==
Attached surfaces can be used to create effects like doors or lifts between different sector groups connected by linked portals.
Attached surfaces can be used to create effects like doors or lifts between different sector groups connected by linked portals.


One sector is the "control", which the attached surfaces will move in sync with. The control can either be inside the map or a dummy sector outside of it.
In the classic format, 385 (Apply_PortalToFrontsector) isn't directly related to attached surfaces, but is useful for them because it makes it possible to have lifts and such tagged in sectors that are also tagged for portals. The portal is tagged by putting a line with special 385 facing the affected sector(s), and the line's tag set to the portal tag number you want to apply to those sectors.


Put an Attach_SetFloorControl special on a line with its front side facing the control sector and give it a tag. Then put Attach_FloorToControl specials on lines facing all the sectors to be attached to it.
In UDMF, you simply apply '''portalfloor''' or '''portalceiling''' to apply the intended linked portal, at exactly the height it needs to be.


By use of the mirror attachments you can, for example, attach a ceiling to the mirrored movement of a floor, to create a split door which opens from the middle.
Build the same lift or elevator on both sides of your portal (this will require floors that are higher than the ceiling on one side of it), attach one of them to the other, and set up the portal between them. Under the classic format you will most likely want to use special 385 because otherwise linked portals start defined on the same level as surfaces, but for through-portal elevators you will need to have a floor far beneath the portal or above the ceiling portal.


385 (Apply_PortalToFrontsector) isn't directly related to attached surfaces, but is useful for them because it makes it possible to have lifts and such tagged in sectors that are also tagged for portals. The portal is tagged by putting a line with special 385 facing the affected sector(s), and the line's tag set to the portal tag number you want to apply to those sectors.
==Attached portals==
By default the linked portal plane does not move -- it stays fixed -- so it can allow solid lifts to move through it. But sometimes you'll want the portal to move. For that, you apply the UDMF '''portal_floor_attached'''/'''portal_ceiling_attached''' attribute or (in the classic format) the [[ExtraData]] '''ATTACHEDPORTAL''' flag to the '''portalflags.floor'''/'''portalflags.ceiling''' '''sector''' flag.


Build the same lift or elevator on both sides of your portal (this will require floors that are higher than the ceiling on one side of it), attach one of them to the other, and set up the portal between them.
Beware that the non-interactive portals (such as visual anchored ones) ''always'' move with the sector plane, so this flag isn't needed there.


[[category:Editing reference]]
[[category:Editing reference]]

Latest revision as of 08:48, 26 September 2020

Attached surfaces cause multiple sectors to move together. This allows for the creation of complex lifts, doors, or elevators comprised of multiple sectors which will remain synchronized even if any sector's movement is blocked by a player or other object.

One sector is the "control", which the attached surfaces will move in sync with. The control can either be inside the map or a dummy sector outside of it.

By use of the mirror attachments you can, for example, attach a ceiling to the mirrored movement of a floor, to create a split door which opens from the middle.

Back to Linedef types

UDMF format[edit]

UDMF format doesn't use linedef types, but the floorid, ceilingid, attachfloor and attachceiling. They use IDs separate from the sector or linedef tags, equivalent to the linedef tags used in the classic format for this purpose.

For mirrored movement, use negative values of IDs in attachfloor and attachceiling. So if a master sector's ceiling moves up and a slave sector's floor will move down, set the ceilingid of master to 1 and the attachfloor value of slave to -1.

Classic format[edit]

Attached surface linedefs are as follows:

  • 379 -- Attach_SetCeilingControl
The sector on the front side of this line will have its ceiling used to control the movement of the attached surfaces that share this line's tag number.
  • 380 -- Attach_SetFloorControl
The sector on the front side of this line will have its floor used to control the movement of the attached surfaces that share this line's tag.
  • 381 -- Attach_FloorToControl
The sector on the front side of this line will have its floor movement controlled by the surface whose control line shares this line's tag.
  • 382 -- Attach_CeilingToControl
The sector on the front side of this line will have its ceiling movement controlled by the surface whose control line shares this line's tag.
  • 383 -- Attach_MirrorFloorToControl
The sector on the front side of this line will have its floor movement controlled inversely by the surface whose control line shares this line's tag.
  • 384 -- Attach_MirrorCeilingToControl
The sector on the front side of this line will have its ceiling movement controlled inversely by the surface whose control line shares this line's tag.

For example, put an Attach_SetFloorControl special on a line with its front side facing the control sector and give it a tag. Then put Attach_FloorToControl specials on lines facing all the sectors to be attached to it.

Using attached surfaces with linked portals[edit]

Attached surfaces can be used to create effects like doors or lifts between different sector groups connected by linked portals.

In the classic format, 385 (Apply_PortalToFrontsector) isn't directly related to attached surfaces, but is useful for them because it makes it possible to have lifts and such tagged in sectors that are also tagged for portals. The portal is tagged by putting a line with special 385 facing the affected sector(s), and the line's tag set to the portal tag number you want to apply to those sectors.

In UDMF, you simply apply portalfloor or portalceiling to apply the intended linked portal, at exactly the height it needs to be.

Build the same lift or elevator on both sides of your portal (this will require floors that are higher than the ceiling on one side of it), attach one of them to the other, and set up the portal between them. Under the classic format you will most likely want to use special 385 because otherwise linked portals start defined on the same level as surfaces, but for through-portal elevators you will need to have a floor far beneath the portal or above the ceiling portal.

Attached portals[edit]

By default the linked portal plane does not move -- it stays fixed -- so it can allow solid lifts to move through it. But sometimes you'll want the portal to move. For that, you apply the UDMF portal_floor_attached/portal_ceiling_attached attribute or (in the classic format) the ExtraData ATTACHEDPORTAL flag to the portalflags.floor/portalflags.ceiling sector flag.

Beware that the non-interactive portals (such as visual anchored ones) always move with the sector plane, so this flag isn't needed there.