
		      LINE TYPES
		     ************

  This file is written by Brian McKimens (samneric@connected.com)
  dmspec13 is written by Matt Fell (matt.burnett@acebbs.com)
     and distributed by Hank Leukart (ap641@cleveland.freenet.edu)
  DEU 5.1 is written by Raphael Quinet (quinet@montefiore.ulg.ac.be)
		   and	Brendon J. Wyber (b.wyber@csc.canterbury.ac.nz)


	Following is a list of LINE TYPES available for wad editing.
I hope this information will allow you to better design levels.

	I gathered this information from dmspec13 and from experiments with
DEU 5.1 to determine the actual effects of the line types.  I found numerous
errors in the descriptions in DEU 5.1 and many omissions in the descriptions
in dmspec13.  I just started to figure out what 1 particular type did.	In
the course of experimenting, I was able to determine what other line types
actually do and to fill-in a large part of the missing descriptions.  Newly
discovered line types are preceeded by an asterisk (*).	 I don't pretend
that this is error-free, but in as many cases as possible, I tested those
line types that I DID test under as many different conditions as needed to
feel secure in the description.	 If you find errors, please e-mail me and
be sure to include a GOOD description of the discrepency (hopefully, a
zipped, binary wad containing NO MORE THAN NECESSARY to run and illustrate
the condition!).  There are still line types not defined, and they are listed
at the end of this file.  There are also sector types (2) not defined yet
and some of these line types may behave differently when tagged to those
type of sectors.  Who knows?...	 A bottle of Murine to whoever figures out
what these undefined sector and line types do!

	DEU 5.1 allows use of these new and corrected types to be inserted
manually by entering a decimal number for the line type by hand.  It allows
you to insert a number up to 255, but the known line types at this time only
range from 0-104.  Dmspec13 refers to a line type of -1 that occurs in E2M7
in one room. Since this doesn't "appear" to have a function in the room that
uses it (on every major wall, I might add), I'm gonna consider it a bug for
ID to squash when they get around to it.  Like that Sargeant stuck between
walls, and the Spectre stuck TO a wall, in E1M6.  At least until someone
come up with a purpose for it.

   LINE TYPE is a term that refers to an effect that can be triggered by
an ACTION on the related linedef.  The word "function" might better describe
TYPE than "type" does.	The DOOM engine calls certains functions when the
linedefs are activated by shooting, crossing, or butting up next to them
and hitting the spacebar.  ID isn't likely to release their source code, but
we can experiment and discover "what happens" when we set a linedef to a
certain TYPE and then activate it.  This is what dmspec13 contains - results
of experiments performed on wads to see what happens.  This file is just a
continuation of the efforts of other people to unravel the "secrets" that the
mighty DOOM engine hides...

	I use some terms in this file that I have not seen used before to
describe the line types or the sectors that they affect, so I will define
them as I go.  The first two that I'll introduce refer to the relationship of
two sectors that share one or more linedefs.
	Such sectors are ADJACENT.  All sectors are also adjacent to
themselves, as they share linedefs (sidedefs even!) with themselves.
Sectors A & B below are adjacent, as are C & D, E & F.	Sector E can also
be said to CONTAIN sector F.  Sector F shares all of it's lindefs, but
with only one sector (E).  CONTAIN is a term that figures into the operation
of line type #9 (a floor-affecting line type).
	      ___________      ___________	 ___________
	     |		 |    |		  |	|	    |
	     |		 |    |	     D	  |	|   ___	 E  |
	 ____|	   B	 |    |____	  |	|  | F |    |
	| A  |		 |    | C  |	  |	|  |___|    |
	|____|___________|    |____|______|	|___________|

In describing the floor effects, dmspec13 used the term "neighbor" ("ne.").
This term was also echoed by the authors of the various editors.  The problem
with this term is that it implies that a neighbor to sector #X can not be
sector #X itself.  When the DOOM engine looks for the Lowest Adjacent Ceiling
to raise a floor up to, it may find that the LAC is the ceiling belonging
to the same sector as the rising floor.	 If it stops 8 below the LAC in this
instance, it will be 8 below it's own ceiling.	If we can adopt these or
similar terms, then describing effects of certain linetypes will be easier.

  ----------------

Following are the terms used in the descriptions of line types:

 DEC#
 ****	Decimal number of the line type.

 ACT.
 ****	Activated by.  This indicates what will activate the effect.
   S 1	-  Switch activated.  Not repeatable.
   S R	-  Switch - repeatable after sector is reset.
   S X	-  Switch - repeatable without requiring sector reset.
	   (use of this linetype is not recommended)
   W 1	-  Walking across line activates.  Not repeatable.
   W R	-  Walking - repeatable after sector reset.
   W X	-  Walking - repeatable without requiring resetting.
	   (use of this linetype is not recommended)
   G 1	-  Gun activated. (Shoot at or through line to activate)

 EFFECT
 ******	 What happens to the involved sector when triggered by the linedef.

 EFFECT	 Terms:

   HAC	-  Highest Adjacent Ceiling
   LAC	-  Lowest Adjacent Ceiling
   HAF	_  Highest Adjacent Floor
   LAF	-  Lowest Adjacent Floor
   NAF	-  Numeric Adjacent Floor.  This is the floor of the adjacent
	   sector that shares the lowest numbered linedef of the tagged
	   sector.
   NUMERIC CHANGE - defined before the section on floors
   TRIGGER CHANGE - defined before the section on floors


 DEC#  ACT.  EFFECT
 ****  ****  ******
  0    - -   Normal (used to indicate no special handling of linedef)

 -----------

    DOORS   These are actually ceiling effects, as doors are just ceilings
	    that are raised and lowered to allow access to the sectors
	    lying beyond them.	I'm grouping them separately since designers
	    put "doors" in wads, not "ceilings with specific behaviors".


  LOCAL DOORS - sectors bound to 2nd sidedef of activating linedef.
		(activated at door surface)

 DEC#  ACT.  EFFECT
 ****  ****  ******
  1    S R   Open door. Closes in 6 secs
  26   S R   Open door. Closes in 6 secs. Blue key
  27   S R   Open door. Closes in 6 secs. Yellow key
  28   S R   Open door. Closes in 6 secs. Red key
  31   S 1   Open door. Stays open
  46   G 1   Open door. Stays open
  32   S 1   Open door. Stays open	  Blue key
  33   S 1   Open door. Stays open	  Yellow key
  34   S 1   Open door. Stays open	  Red key


  REMOTE DOORS - sectors tagged by activating linedef.
		 (remotely activated at wall switches, walk-over lines)

(* indicates not in dmspec13 and unavailable in editor menus at this time.)

 DEC#  ACT.  EFFECT
 ****  ****  ******
  103  S 1   Open door. Stays open
  61   S R   Open door. Stays open
  2    W 1   Open door. Stays open
  86   W R   Open door. Stays open
  29   S 1   Open door. Closes in 6 seconds
  63   S R   Open door. Closes in 6 seconds
* 4    W 1   Open door	Closes in 6 seconds
  90   W R   Open door. Closes in 6 seconds
* 50   S 1   Close door
  42   S R   Close door
  3    W 1   Close door
  75   W R   Close door
  16   W 1   Close door for 30 seconds
  76   W R   Close door for 30 seconds

  ----------------------

       CEILINGS

 DEC#  ACT.  EFFECT
 ****  ****  ******
  40   W 1   Raise to HAC

  41   S 1   Lower to own floor
* 43   S R   Lower to own floor
* 49   S 1   Lower to 8 above own floor.
  44   W 1   Lower to 8 above own floor
* 72   W R   Lower to 8 above own floor

* 25   W 1   Start fast crushing ceiling. Fast crush. Slow damage
* 6    W 1   Start fast crushing ceiling. Fast crush. Fast damage
  77   W R   Start fast crushing ceiling. Fast crush. Slow damage
  73   W R   Start slow crushing ceiling. Slow crush. Fast damage
* 57   W 1   Stop crushing ceiling
  74   W R   Stop crushing ceiling

  ------------------

       FLOORS

Floor-affecting types trigger effects best described as RAISE, LOWER, GOTO.
There are also types affecting MOVING FLOORS, LIFTS, and STAIRS, but I'm
treating these as separate cases since most designers view these as complete
entities - much the same as doors are considered separate from ceilings,
even though door actions are actually ceiling actions.

RAISE types will move the floor up, either until a given numerical distance
has been traveled, or until it reaches a position relative to an adjacent
floor or ceiling.  RAISE types should not be used if the relative position
is, or can be relocated to, BELOW the floor before triggering.

LOWER types will move the floor only to positions relative to an adjacent
floor or ceiling.  LOWER types should not be used if the relative position
is, or can be relocated to, ABOVE the floor before triggering.

The GOTO type is a term not used before.  GOTO raises OR lowers the floor to
a given height or location.  Many of the earlier descriptions referred to
RAISE or LOWER types only, because the floors that were studied to find the
resulting actions were set below or above the GOTO destination already.
GOTO types are useful when multiple sectors are tagged together, each having
a different height.  Each will move in whatever direction is required to
end up at the same height.

		   SPECIAL NOTE
		   ************

Some floor types also cause the tagged sector to change floor texture and
"damage" trait to that of a 2nd sector (MODEL sector, for lack of a better
term). There are 2 different models involved in the changes.  A TRIGGER model
is the sector that is bound to the first sidedef of the triggering linedef.
A NUMERIC model is the adjacent sector sharing the LOWEST NUMBERED LINEDEF
comprising the tagged sector.  These are referred to in the EFFECTS column
below as either TRIGGER CHANGE or NUMERIC CHANGE.  In either case, the tagged
sector takes on the floor texture of the model sector.	In the case of the
NUMERIC CHANGE a second trait is also passed to the tagged sector - the
ability to do health damage.  This was previously considered to be a passing
of the SECTOR TYPE from the model to the tagged sector, but that is not the
case.  The sector type also describes light characteristics, but these are
not passed to the tagged sector.  A TRIGGER CHANGE also appears to "lock-out"
any further changes to a sector by any linedef tagged to it.

I refer to the floor of a Numeric model as an NAF - Numeric Adjacent Floor.
Dmspec13 referred to the change as "matching", but it also used that term to
describe a RAISE or LOWER destination height.  I will try to avoid the term,
as its meaning has already been muddied.

One notable line type involving floors:

Line type #9 is recognizable as the switch to activate the chainsaw pillar
in E1M2.  The tagged sector (pillar) moves in GOTO mode to its NAF (Numeric
Adjacent Floor) comprised of the acid pool surrounding it.  (If the acid
pool is the tagged sector and the pillar shares its lowest numbered linedef,
the pool will GOTO the level of the pillar.  You can turn off clipping and
climb up to it and still be harmed by the acid.)  But in this case, the pillar
is tagged, so it moves to the floor level of the acid pool sector.  Note
that the pillar is CONTAINED by its NAF sector, as all of its linedefs are
shared by the acid pool.  Because of this, a second condition sets in -
the acid pool "GOesTO" >its< NAF and undergoes a NUMERIC CHANGE, assuming
the same floor texture and damage trait (no longer damaging to health).
The acid pool is contained by its own NAF in this case, but that is not
required for the second step to occur.	The pool would move to its NAF even
if stuck in a corner, as long as the lowest numbered linedef bounding the
acid pool is a TWO-SIDED LINEDEF.  The primary NAF sector (the acid pool)
does NOT consider the tagged sector (the pillar) to contain its NAF.  It
looks elsewhere, EVEN IF its lowest numbered linedef is shared with the
tagged sector.	The acid pool finds its NAF among its other shared linedefs.

There is a bug I found.	 If the acid pool's lowest numbered linedef is a
ONE-SIDED linedef, the pillar and acid pool floors both GOTO a height of 34,
and the acid pool turns from NUKAGEn to TLITE6_6 - the last one on the list.
(Probably from a function returning a pointer to it after being passed junk.)
Since ID doesn't make this mistake, you would do well to emulate them.

One last note on this line type - If the tagged sector's lowest numbered
linedef is ONE-SIDED, it is considered to have no NAF, and nothing happens.


     FLOORS

 DEC#  ACT.  EFFECT
 ****  ****  ******
  18   S 1   Raise to next-higher floor
* 69   S X   Raise to next-higher floor
  5    W 1   Raise to next-higher floor
  20   S 1   Raise to next-higher floor	  TRIGGER CHANGE
* 68   S 1   Raise to next-higher floor	  TRIGGER CHANGE
  22   W 1   Raise to next-higher floor	  TRIGGER CHANGE
* 95   W 1   Raise to next-higher floor	  TRIGGER CHANGE
* 47   G 1   Raise to next-higher floor	  TRIGGER CHANGE
* 101  S 1   Raise to LAC
* 64   S R   Raise to LAC
* 24   G 1   Raise to LAC
* 55   S 1   Raise to 8 below LAC   CRUSH
* 65   S R   Raise to 8 below LAC   CRUSH
* 94   W 1   Raise to 8 below LAC   CRUSH
  56   W 1   Raise to 8 below LAC   CRUSH
  58   W 1   Raise 24
* 92   W X   Raise 24
* 15   S 1   Raise 24	TRIGGER CHANGE
* 66   S X   Raise 24	TRIGGER CHANGE
  59   W 1   Raise 24	TRIGGER CHANGE
* 93   W X   Raise 24	TRIGGER CHANGE
  14   S 1   Raise 32	TRIGGER CHANGE
* 67   S X   Raise 32	TRIGGER CHANGE
  30   W 1   Raise 128
* 96   W X   Raise 128

  23   S 1   Lower to LAF
* 60   S R   Lower to LAF
  38   W 1   Lower to LAF
  82   W R   Lower to LAF
  37   W 1   Lower to LAF   NUMERIC CHANGE
* 84   W R   Lower to LAF   NUMERIC CHANGE

  91   W R   Goto LAC
  102  S 1   Goto HAF
* 45   S R   Goto HAF
  19   W 1   Goto HAF
* 83   W R   Goto HAF
* 71   S 1   Goto 8 above HAF
  70   S R   Goto 8 above HAF
  36   W 1   Goto 8 above HAF
  98   W R   Goto 8 above HAF

  This next one is a bit involved.  Explained further above.
  Example: switch activating pillar with chainsaw in E1M2.

  9    S 1   {
	     Goto NAF1;
	       IF (contained by NAF1) {
		   NAF1 Goto its own NAF2 and undergo NUMERIC CHANGE;
	       }
	     }



      FLOORS USED AS LIFTS

 DEC#  ACT.  EFFECT
 ****  ****  ******
  21   S 1   Lower quickly for 3 seconds, then return
  62   S R   Lower quickly for 3 seconds, then return
  10   W 1   Lower quickly for 3 seconds, then return
  88   W R   Lower quickly for 3 seconds, then return


      MOVING FLOORS

 DEC#  ACT.  EFFECT
 ****  ****  ******
* 53   W 1   Start moving floor
  87   W R   Start moving floor
* 54   W 1   Stop moving floor
  89   W R   Stop moving floor

  ------------------------------------------

  From here on down, with the exception of those types marked with
  an asterisk (*) and those as yet undefined, I didn't experiment
  with these line types.  Most of the descriptions are unchanged from
  how they appear in dmspec13.


      STAIRS

 DEC#  ACT.  EFFECT
 ****  ****  ******
  7    S 1   Staircase rises up from floor in appropriate sectors.
  8    W 1   Stairs


     END LEVEL

 DEC#  ACT.  EFFECT
 ****  ****  ******
  11   S -   End level. Go to next level.
  51   S -   End level. Go to secret level 9.
  52   W -   End level. Go to next level


     TELEPORT

 DEC#  ACT.  EFFECT
 ****  ****  ******
  39   W 1   Teleport to sector. (Only ONE sector per tag #)
  97   W R   Teleport to sector. (Only ONE sector per tag #)


     LIGHT LEVELS

 DEC#  ACT.  EFFECT
 ****  ****  ******
  13   W 1   Brightness goes to 255
* 17   W 1   Change light to blink - 1 sec.
  104  W 1   Light drops to lowest light level amongst neighbor sectors
  35   W 1   Light drops to 0.
* 79   W R   Light drops to 0.
  80   W R   Brightness to maximum neighbor light level


     MISCELLANEOUS

 DEC#  ACT.  EFFECT
 ****  ****  ******
  48   - -   Animated, horizontally scrolling wall texture (right to left)
	     (This is an non-triggered condition affecting only how the
	       wall texture is painted onto the sidedef.)


     STILL UNKNOWN AT THIS TIME

  12 - affects light level
  78
  81
  83
  84
  85
  99
  100

