Eternity Wiki - User contributions [en]

Polyobject

2026-06-14T14:12:31Z

Printz: /* Polyobjects with 2-sided lines */

PolyObjects are special sets of one-sided linedefs which, unlike any other lines, can be moved on the map during gameplay. Unlike the Hexen 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, 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 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.

The lines are typically one-sided walls, but two-sided line polyobjects are also possible.

==='''Method 1: The <code>Polyobj_StartLine</code> Special'''===

:The <code>348:Polyobj_StartLine('''polyobj_id''', '''mirror_id''')</code> 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 <code>Polyobj_StartLine</code> 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 <code>Polyobj_StartLine('''polyobj_id''', '''mirror_id''')</code> 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 <code>Polyobj_ExplicitLine</code> Special'''===

:The <code>349:Polyobj_ExplicitLine('''polyobj_id''', '''index''', '''mirror_id''')</code> 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 (via [[ExtraData]]) the <code>Polyobj_ExplicitLine</code> 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 argument '''#2''' set also to whatever their tag is (in this case again it's ''1'').

: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 '''LineDef id'''.

:Now, once the lines are added, it is necessary to define the control objects. This is exactly the same as it is for the <code>StartLine(...)</code> 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 <code>ExplicitLines'</code> 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 <code>Polyobj_ExplicitLine('''polyobj_id''', '''index''', '''mirror_id''')</code> are as follows:
:* ''polyobj_id'' : the unique ID number (greater than zero) of the PolyObject
:* ''index'' : 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 also includes PolyObject Doors discussed in the next section of this article.

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>

==Polyobjects with portals==
:See [[Linked_portals#Polyobject_portals | Polyobject portals]]

==Polyobjects with 2-sided lines==
Polyobjects made of 2-sided lines have always worked in all games which had polyobjects, but with limitations. Keep in mind that Polyobj_StartLine only works for closed polygons of linedefs going the same way. Otherwise, use Polyobj_ExplicitLine for all involved lines. You will need to use an OPEN [[ACS]] script with the [[SetLineSpecial]] and [[SetLineActivation]] if you want lines with Polyobj_ExplicitLine to have in-game activation effects. In Eternity, a polyobject can have any number of one-sided and two-sided lines.

As of Eternity 4.06.00, the following improvements have been made to 2-sided lines belonging to polyobjects:
# Passable lines no longer push things standing in their way, if they can just move into them (normally in Hexen they would push). Pushing will only happen on the category of solid things affected by the specific blocking type (monsters, players or both)
# Textures will retain their initial Y offset when the line moves across different sector elevations. Previously in Hexen they would always make sure the Y offset agrees to the current sectors where they're located.
# No more collision detection influenced by the source control sector. Previously in Hexen you would need to match the height of the control sector with the one of the game sector. Normally this wasn't an issue, because of the subsector restriction, which no longer exists in Eternity.
# 2-sided lines with actions will also trigger if actor stands still and is crossed by the polyobject.
# 3DMidTex lines now work properly and as expected. You can use them as horizontal moving platforms.
# Impassable 2-sided lines also behave as transporters to things above if moving below sector portals.

[[category:Editing reference]]

ExtraData

2026-06-14T14:11:42Z

Printz: /* extflags */

With support of [[Universal Doom Map Format]] in releases of Eternity, ExtraData is now considered {{Deprecated}}. In the future new features introduced into UDMF will not be supported by ExtraData. ExtraData maps will still work, but new projects should use UDMF due to its greatly streamlined mapping experience, especially if using editors such as [https://www.doomworld.com/forum/topic/96943 Doom Builder X] or [https://forum.zdoom.org/viewtopic.php?t=54957 GZDoomBuilder-Bugfix] are used (the former including specific improvements for Eternity's UDMF, such as for [[linked portals]]).

ExtraData is a new data specification language for the [[Eternity Engine]] that allows arbitrary extension of mapthings, lines, and sectors with any number of new fields, with data provided in more or less any format. The use of a textual input language forever removes any future problems caused by binary format limitations. The ExtraData parser is based on the libConfuse configuration file parser library by Martin Hedenfalk, which is also used by GFS and EDF.

Each section in this document deals with one of the ExtraData constructs, as well as how to embed ExtraData in a WAD and how to associate it with a given map.
{{Backto|Eternity Engine}}
{{editref}}
=General Syntax=
''See [[EDF#Syntax|EDF Syntax]], as it is the same.''

=Embedding and Associating ExtraData =

ExtraData is embedded directly as a text script into a lump of any name. This can be done with any number of wad file management tools, such as SLumpEd, SLADE 3, or XWE.

An ExtraData script is associated with a map via use of the [[MapInfo]] variable '''extradata'''. A map can only have one ExtraData script, but it is possible for multiple maps to share the same script.

Example of ExtraData specification via EMAPINFO:
[MAP01]
extradata = EDLUMP01

=Mapthings =

Mapthings define monsters, lamps, control points, items, etc -- anything that is spawned on the map at level start.

Each field in the mapthing definition, with the exception of the '''recordnum''' field, is optional. If a field is not provided, it takes on the default value indicated below the syntax information. Fields may also be provided in any order.

Note that the order of mapthing definitions in ExtraData is not important. The '''recordnum''' field serves to identify mapthing records.

==Creating ExtraData Control Objects ==

Mapthing records in ExtraData are only associated with a special control object that must be placed on the map in the usual manner.

The ExtraData control object has a '''doomednum''' of 5004. Each control object specifies its corresponding ExtraData mapthing record number as an integer value in its mapthing '''options''' field. If your editor does not allow entering arbitrary values into the options field of mapthings, you will need to use the BOOM command-line editor, CLED. As of the initial writing time of this document, both DETH and Doom Builder support entering arbitrary integer values for the options field. Check your editor's documentation or user interface to verify if it supports this.

The x, y, and angle fields of the ExtraData control object are passed on to the thing which will be spawned at the control point's location, so those fields of the control object should be set normally. The true type and options fields of the thing to be spawned, along with any extended fields, are specified in the ExtraData record.

Any number of ExtraData control objects can reference the same ExtraData record. In the event that a control object references a non-existent ExtraData record, the ExtraData script for a level is missing, or the thing type referenced by an ExtraData record isn't valid, an [[Unknown]] thing will be spawned at the control point's location. Note that you cannot spawn ExtraData control objects using ExtraData. Attempting this will also result in an Unknown thing.

==Mapthing Syntax and Fields ==

The syntax of the ExtraData mapthing record is as follows. Remember that all fields except the '''recordnum''' field are optional and can be specified in any order.
mapthing
{
recordnum <unique number>

// These fields are normal mapthing fields
type <doomednum> OR <EDF thingtype mnemonic>
options <options flag list>

// These fields are ExtraData extensions
tid <number>
special <number>
args { <special field>, ... }
height <number>
}
===Explanation of fields:===
====recordnum====
The recordnum serves to identify this record, and is the number which ExtraData control objects must use to associate themselves with a mapthing record. Every ExtraData mapthing record must have a unique record number. If a duplicate record number is detected, the engine will currently exit with an error message. The record number is limited to values between 0 and 65535 inclusive. Some editors may only allow input of numbers up to 32767 in the mapthing options field, or may treat values above 32767 as negative numbers. Beware of this.

====type====
Default: No meaningful default value; an Unknown thing will be spawned if not valid.

This field specifies the type of object to spawn at the location and angle of ExtraData control objects using this record. This field can accept one of two types of values. The first is a normal thingtype doomednum as specified via [[EDF]] and used by all editors. For example, the DOOM Imp's doomednum is 3001.

This field can also accept EDF thingtype mnemonics. EDF thingtype mnemonics must be prefixed with ''thing:'' -- this allows the parser to know it is dealing with a string instead of a number. EDF thingtypes must have a unique doomednum to be specified in an ExtraData mapthing record. If the specified EDF thingtype doesn't exist or has a doomednum of -1, an Unknown object will be spawned instead.

See [[Thing types]] for a list of potentially useful types, new to Eternity, to use here.

Example:
mapthing { type 3001 } // This record specifies an Imp via its doomednum

mapthing { type DoomImp } // This record specifies an Imp by its EDF mnemonic

====options====
Default: No flags are set by default.

This field specifies the options (also known as mapthing flags). This field uses the same syntax as BEX/EDF flag strings, but the syntax will be reviewed here for completeness.

A BEX flag list is a string of flag names separated by whitespace, pipe characters, commas, or plus characters. In ExtraData, if a flag list contains whitespace, commas, or plus signs, it must be enclosed in double or single quotations. Flags are combined using bitwise-OR logic, so a flag name can be specified more than once. Specifying a flag name causes that flag to be turned on. The default state of all flags is off.

These are the flag values which are available for this field:
Flag name Meaning
------------------------------------------------------------------------------
EASY Thing appears in easy difficulties
NORMAL Thing appears in "Hurt Me Plenty"
HARD Thing appears in Ultra-Violence and Nightmare
AMBUSH Thing is "deaf", will not wake up via sound
NOTSINGLE Thing doesn't appear in single-player mode
NOTDM Thing doesn't appear in deathmatch
NOTCOOP Thing doesn't appear in cooperative multiplayer
FRIEND Thing uses MBF friendly logic
DORMANT Thing is dormant at map startup (script feature)
STANDING Currently only used for [[Thing_types#Sector_actions|sector actions]].
------------------------------------------------------------------------------

The mapthing options value 256 (0x0100) is reserved. If this bit is set, all BOOM, MBF, and Eternity extended mapthing bits will be cleared. This is to guard against editors like Hellmaker which set all bits they do not understand, instead of leaving them zero.

Example options fields -- All of these are equivalent:
// This is the only syntax that does not require quotations.

mapthing { options EASY|NORMAL|HARD }

// All of these syntaxes must be quoted, because unquoted strings in
// ExtraData cannot contain spaces, commas, or plus signs.

mapthing { options "EASY NORMAL HARD" }
mapthing { options "EASY | NORMAL | HARD" }
mapthing { options "EASY+NORMAL+HARD" }
mapthing { options "EASY + NORMAL + HARD" }
mapthing { options "EASY,NORMAL,HARD" }
mapthing { options "EASY, NORMAL, HARD" }

====tid====
Default: 0

The TID, or "Thing ID", is a tag for mapthings which is used for identification in [[ACS]] scripts. TID values must be positive numbers between 1 and 65535. The TID value zero means no TID. Negative TID values are reserved and are used to indicate special things within the engine. TIDs are not required to be unique, and most ACS functions that accept TIDs will perform an action on all mapthings which bear the same TID.

====special====
Default: 0

The thing special field, which will execute when thing dies if it's a monster or picked up if it's an item. Use '''args''' to control the parameters.

====args====
Default: All args values default to zero.

The args field is a list of up to five special values which can have a broad range of meanings. Any values not provided in the args list will default, and if more than five values are provided, only the first five will be used. Currently, all args values are interpreted as integers (a non-number string evaluates to zero). This may change in the future.

Example args list:
mapthing { args { 0, 1, 2, 3, 4 } }

====height====
Default: 0

For normal objects, this field indicates a distance above the floor that the thing will spawn at level start. For objects with the SPAWNCEILING flag, this field indicates a distance below the ceiling instead. This field will have no effect on objects which spawn at a randomized height.

=Linedefs =

Linedefs define walls, two-sided textures, and provide action triggers within maps.

Each field in the linedef definition, with the exception of the '''recordnum''' field, is optional. If a field is not provided, it takes on the default value indicated below the syntax information. Fields may also be provided in any order.

Note that the order of linedef definitions in ExtraData is not important. The '''recordnum''' field serves to identify linedef records.

==Creating ExtraData Linedefs ==

Linedef records in ExtraData are associated either with lines which bear the ExtraData Control Line Special (270), or with any linedef in a DOOM-format map which uses a parameterized line special. You can place the 270 special, as well as parameterized special numbers, into the normal "special" field of a line using virtually any map editor. Editors with Eternity-specific configurations should support these specials natively.

Each control linedef (or directly-used parameterized special) specifies its corresponding ExtraData linedef record number as an integer value in its linedef tag field. If your editor does not allow entering arbitrary values up to 32767 into the tag field of linedefs, you will need to use the BOOM command-line editor, CLED. As of the initial writing time of this document, both DETH and Doom Builder support entering arbitrary integer values for the tag field. Check your editor's documentation or user interface to verify if it supports this.

The flags, sidedefs, textures, and location of the ExtraData control linedef are used normally by the line and cannot be altered from within ExtraData. The true special (if 270 is used) and tag fields of the linedef, along with any extended fields, are specified in the ExtraData record which the control linedef references.

Any number of linedefs can reference the same ExtraData record. In the event that a control linedef references a non-existent ExtraData record or the ExtraData script for a level is missing, the special and tag of the ExtraData control linedef will both be set to zero.

==Linedef Syntax and Fields ==

The syntax of the ExtraData linedef record is as follows. Remember that all fields except the '''recordnum''' field are optional and can be specified in any order.
linedef
{
recordnum <unique number>

// These fields are normal linedef fields
special <number> OR <special name>
tag <number>

// These fields are ExtraData extensions
extflags <extended line flags list>
args { <special field>, ... }
id <number>
alpha <number>

portalid <number>
}
===Explanation of fields: ===
====recordnum====
The recordnum serves to identify this record, and is the number which ExtraData control linedefs must use to associate themselves with a linedef record. Every ExtraData linedef record must have a unique record number. If a duplicate record number is detected, the engine will currently exit with an error message. The record number is limited to values between 0 and 32767 inclusive. Some editors may only allow input of numbers up to 255 in the linedef tag field. Beware of this.

====special====
:''Default: 0 ''

The special field determines what [[Linedef_types|type of action]] may be taken when a line is crossed, used, shot, etc. There are three types of linedef specials in Eternity: normal, generalized, and parameterized. Parameterized specials use the '''args''' field documented below to provide complete customization of line actions.

This field can accept numbers for any special type, including generalized and parameterized, but it can also accept special names for parameterized line types. See the [[Detailed parameterized linedef specification]] for a complete list of the available names.

====tag====
:''Default: 0 ''

The tag of the linedef, used by DOOM-style line specials and sector effects.

====extflags====
:''Default: No flags are set by default. ''

This field specifies extended linedef flag values which impact the functionality of parameterized linedef specials. This field uses the same syntax as BEX/EDF flag strings, but the syntax will be reviewed here for completeness.

A BEX flag list is a string of flag names separated by whitespace, pipe characters, commas, or plus characters. In ExtraData, if a flag list contains whitespace, commas, or plus signs, it must be enclosed in double or single quotations. Flags are combined using bitwise-OR logic, so a flag name can be specified more than once. Specifying a flag name causes that flag to be turned on. The default state of all flags is off.

These are the flag values which are available for this field:
Flag name Meaning
---------------------------------------------------------------------------------------
CROSS Linedef can be activated by being crossed.
USE Linedef can be activated by being used.
IMPACT Linedef can be activated by being shot.
PUSH Linedef can be activated by being pushed.
PLAYER Linedef can be activated by players.
MONSTER Linedef can be activated by objects with SPACMONSTER flag.
MISSILE Linedef can be activated by objects with SPACMISSILE flag.
POLYOBJECT Linedef can be activated by polyobjects (only works with CROSS)
REPEAT Linedef action is repeatable.
1SONLY Linedef can only be activated from first side.
ADDITIVE Linedef's midtexture is drawn with additive blending.
BLOCKALL Linedef will block everything that can be clipped.
ZONEBOUNDARY Linedef will work as a reverb effect boundary. Not needed for one-sided lines.
CLIPMIDTEX Linedef middle texture will not "bleed" on floor and ceiling.
WRAPMIDTEX Linedef middle texture of two-sided is repeated vertically instead of being drawn only once.
3DMTPASSPROJ Linedef will always let projectiles pass even if marked as 3DMidTex
LOWERPORTAL Linedef copies floor portal from its backside to its lower visible edge
UPPERPORTAL Linedef copies ceiling portal from its backside to its upper visible edge
---------------------------------------------------------------------------------------

Notes: IMPACT is currently only implemented for bullet weapons.

LOWERPORTAL and UPPERPORTAL are used to enable portals on the front side's upper and/or lower edges of a linedef, if the sector in front of the linedef is tall enough compared to the back sector to expose them. It is the only way to enable such portals, which will copy the sector portal(s) from the backside, if any.

Example flags fields -- All of these are equivalent:
// This is the only syntax that does not require quotations.

linedef { extflags CROSS|PLAYER|MISSILE|REPEAT }

// All of these syntaxes must be quoted, because unquoted strings in
// ExtraData cannot contain spaces, commas, or plus signs.

linedef { extflags "CROSS PLAYER MISSILE REPEAT" }
linedef { extflags "CROSS | PLAYER | MISSILE | REPEAT" }
linedef { extflags "CROSS+PLAYER+MISSILE+REPEAT" }
linedef { extflags "CROSS + PLAYER + MISSILE + REPEAT" }
linedef { extflags "CROSS,PLAYER,MISSILE,REPEAT" }
linedef { extflags "CROSS, PLAYER, MISSILE, REPEAT" }

====args====
:''Default: All args values default to zero. ''

The args field is a list of up to five special values which can have a broad range of meanings. Any values not provided in the args list will default, and if more than five values are provided, only the first five will be used. Currently, all args values are interpreted as integers (a non-number string evaluates to zero). This may change in the future. The args list is used by parameterized linedef specials.

Example args list:
linedef { args { 0, 1, 2, 3, 4 } }

====id====
:''Default: 0''
This field is equivalent to '''tag'''. It will only have effect if '''tag''' is not already set.

====alpha====
:''Default: Alpha defaults to 1.0.''

The alpha field takes a value from 0.0 to 1.0 to set the opacity at which this linedef's midtexture is drawn. When combined with the ADDITIVE extflag, this can be used for additive-blended translucency as well.

====portalid====
:''Default: none''

Portal ID to apply on front side middle part, as defined from [[Portal_Define]].

=Sectors=

Sectors define distinct areas of the map that are bordered by linedefs, with floor and ceiling properties, lighting data, and specials.

Each field in the sector definition, with the exception of the '''recordnum''' field, is optional. If a field is not provided, it takes on the default value indicated below the syntax information. Fields may also be provided in any order.

Note that the order of sector definitions in ExtraData is not important. The '''recordnum''' field serves to identify sector records.

==Creating ExtraData Sectors==

Sector records in ExtraData are associated with lines which bear the ExtraData Sector Control Special (401). The linedef's front side sector is the map sector that will receive properties from the ExtraData record which is specified by number in the linedef's tag.

Since ExtraData is attached to sectors via linedefs and not through overriding any of the sectors' native fields, you specify all of the normal data for a sector in the map itself, and overriding that data through ExtraData sector records is not supported.

Any number of linedefs can reference the same ExtraData sector record. In the event that a control linedef references a non-existent ExtraData record or the ExtraData script for a level is missing, the tag of the ExtraData sector control linedef will be set to zero and will otherwise be ignored.

==Sector Syntax and Fields ==

The syntax of the ExtraData sector record is as follows. Remember that all fields except the '''recordnum''' field are optional and can be specified in any order.
sector
{
recordnum <unique number>

// These fields are ExtraData extensions to sector data
flags <sector flag list>
flags.add <sector flag list>
flags.remove <sector flag list>
damage <integer>
damagemask <integer>
damagemod <method of damage type>
damageflags <sector damage flags list>
damageflags.add <sector damage flags list>
damageflags.remove <sector damage flags list>
floorterrain <terrain name>
floorangle <float>
flooroffsetx <float>
flooroffsety <float>
floorscalex <float>
floorscaley <float>
ceilingterrain <terrain name>
ceilingangle <float>
ceilingoffsetx <float>
ceilingoffsety <float>
ceilingscalex <float>
ceilingscaley <float>
colormaptop <lump name>
colormapmid <lump name>
colormapbottom <lump name>
portalflags.floor <portal flags list>
portalflags.ceiling <portal flags list>
overlayalpha.floor <percentage or value from 0 to 255>
overlayalpha.ceiling <percentage or value from 0 to 255>
portalid.floor <number>
portalid.ceiling <number>
}
===Explanation of fields: ===
====recordnum====
The recordnum serves to identify this record, and is the number which ExtraData sector control linedefs must use to associate themselves with a sector record. Every ExtraData sector record must have a unique record number. If a duplicate record number is detected, the engine will currently exit with an error message. The record number is limited to values between 0 and 32767 inclusive. Some editors may only allow input of numbers up to 255 in the linedef tag field. Beware of this.

====flags====
:''Default: No flags are set by default. ''

This field specifies sector flag values which specify various properties of sectors. This field uses the same syntax as BEX/EDF flag strings.

These are the flag values which are available for this field:

Flag name Meaning
---------------------------------------------------------------------------------------
SECRET Sector is secret
FRICTION Sector has friction enabled, if targeted by a BOOM friction transfer line
PUSH Sector has BOOM push effects enabled
KILLSOUND Objects in sector cannot make sounds.
KILLMOVESOUND Sector makes no movement sounds, even if it has a special sound sequence
PHASEDLIGHT Sector is phased light sequence start
LIGHTSEQUENCE Sector is phased light sequence step (alternates with below flag)
LIGHTSEQALT Sector is phased light sequence alternate step (alternates with above flag)
---------------------------------------------------------------------------------------

Example flags fields -- All of these are equivalent:
// This is the only syntax that does not require quotations.

sector { flags SECRET|FRICTION|KILLMOVESOUND }

// All of these syntaxes must be quoted, because unquoted strings in
// ExtraData cannot contain spaces, commas, or plus signs.

sector { flags "SECRET FRICTION KILLMOVESOUND" }
sector { flags "SECRET | FRICTION | KILLMOVESOUND" }
sector { flags "SECRET+FRICTION+KILLMOVESOUND" }
sector { flags "SECRET + FRICTION + KILLMOVESOUND" }
sector { flags "SECRET,FRICTION,KILLMOVESOUND" }
sector { flags "SECRET, FRICTION, KILLMOVESOUND" }

====flags.add====
:''Default: No flags are set by default. ''

This is a list of sector flags to add to the sector. This is supported because some sector specials (such as sector special 9, "Secret") imply that certain sector flags will be set on the sector before ExtraData is applied. If you wish to only add flags and not override any that may have been set by sector specials, use this field to specify only the flags that you wish to be added to the sector.

====flags.remove====
:''Default: No flags are set by default. ''

This is a list of sector flags to remove from the sector. If you wish to only remove flags and not override any that may have been set by sector specials, use this field to specify only the flags that you wish to be removed from the sector.

====damage====
:''Default: 0''

Specifies the amount of damage this sector does to players if the players are standing inside the sector and do not meet any special exemption criteria, such as wearing a Radiation Suit. This amount is done at each damage opportunity, which is determined by the '''damagemask''' field.

====damagemask====
:''Default: 0''

Specifies the interval in gametics between damage opportunities for a player standing in this sector. The default value of 0 will cause the sector to do constant and instantaneous damage every gametic. Setting this value to an integer greater than 0 will cause damage to be done every Nth gametic, with N being the value of this field. The default DOOM nukage types all use a damagemask of 32, which is roughly once per in-game second (there are 35 gametics per second).

====damagemod====
:''Default: "Unknown"''

Specifies the type of damage done by this sector. If "Unknown" is specified, the damage done is generic. The value specified should be a valid EDF damagetype mnemonic. If it is not, "Unknown" will be used. This can be used to have a sector type trigger special pain and death states when it deals damage. For example, you can use '''slime''' or '''lava''' damagemod.

====damageflags====
:''Default: No flags are set by default.''

This field specifies sector damage flag values which affect the manner in which a sector does damage. This field uses the same syntax as BEX/EDF flag strings.

These are the flag values which are available for this field:

Flag name Meaning
---------------------------------------------------------------------------------------
LEAKYSUIT The player may take damage at random even if he has the radsuit powerup
IGNORESUIT Radiation suit powerups are ignored entirely
ENDGODMODE God mode will be disabled when the player enters this sector
EXITLEVEL The player will exit if has < 11 health and this sector tries to do damage
TERRAINHIT A TerrainTypes hit will occur when this sector does damage
---------------------------------------------------------------------------------------

====damageflags.add====
:''Default: No flags are set by default.''

Because some sector types imply the activation of various sector damageflags (for example, DOOM sector type 11 sets sector damageflags ENDGODMODE and EXITLEVEL), this field is supported to add additional damageflags to any that may have been set by the map itself. Simply specify whatever flags you wish to have added to those that are already set.

====damageflags.remove====
:''Default: No flags are set by default.''

As with damageflags.add, it may be desirable to turn off some flags that were set by sector specials or other portions of the map data. Use this field to specify any sector damage flags you want to remove from sectors.

====floorterrain====
:''Default: "@flat"''

Specifies an EDF TerrainTypes mnemonic for the type of terrain this sector should exhibit on its floor. If left to default or specified with an invalid name, the terrain of the sector will be determined by its floorpic as usual.

====floorangle====
:''Default: 0 (East, or upper edge to the north)''

Specifies the angle of the floor flat in floating-point degrees from 0 to 359. Note that for compatibility with ZDoom, the angle specified advances in a '''clockwise''' fashion, contrary to most other angles in the DOOM engine.

====flooroffsetx/flooroffsety====
:''Default: 0''

Specifies the x and y offsets of the floor flat, relative to the normal floor grid, in floating point units.

====floorscalex/floorscaley====
:''Default: 1.0''

Specifies the x and y offsets of the floor flat. A higher number means a smaller texture.

====ceilingterrain====
:''Default: "@flat"''

Specifies an EDF TerrainTypes mnemonic for the type of terrain this sector should exhibit on its ceiling. If left to default or specified with an invalid name, the terrain of the sector will be determined by its floorpic as usual. This currently only affects the behavior of bullet puffs when particles are enabled.

====ceilingangle====
:''Default: 0 (East, or upper edge to the north)''

Specifies the angle of the ceiling flat in floating-point degrees from 0 to 359. Note that for compatibility with ZDoom, the angle specified advances in a '''clockwise''' fashion, contrary to most other angles in the DOOM engine.

====ceilingoffsetx/ceilingoffsety====
:''Default: 0''

Specifies the x and y offsets of the ceiling flat, relative to the normal ceiling grid, in floating point units.

====ceilingscalex/ceilingscaley====
:''Default: 1.0''

Specifies the x and y offsets of the ceiling flat. A higher number means a smaller texture.

====colormaptop====
:''Default: "@default"''

Specifies the colormap lump to use when a player's viewpoint is above the fake ceiling of a BOOM 242 "deep water" effect applying to this sector. If left to default, the global colormap from MapInfo will be used as normal, unless one is specified by the 242 effect.

====colormapmid====
:''Default: "@default"''

Specifies the colormap lump to use when a player's viewpoint is between the normal floor and ceiling for an ordinary sector, or between the fake floor and ceiling for a BOOM 242 "deep water" sector. If left to default, the global colormap from MapInfo will be used as normal, unless one is specified by a 242 effect.

====colormapbottom====
:''Default: "@default"''

Specifies the colormap lump to use when a player's viewpoint is below the fake floor of a BOOM 242 "deep water" effect applying to this sector. If left to default, the global colormap from MapInfo will be used as normal, unless one is specified by the 242 effect.

====portalflags.floor/portalflags.ceiling====
:''Default: No flags are set by default.''

These two fields (portalflags.floor and portalflags.ceiling) specify portal property flag values which affect the rendering and behavior of portals attached to this sector's surfaces. These fields use the same syntax as BEX/EDF flag strings.

These are the flag values which are available for this field:

Flag name Meaning
---------------------------------------------------------------------------------------
DISABLED Portal is completely disabled
NORENDER Portal will not be rendered, but may still be interactive
NOPASS Objects cannot pass through the portal even if it is a linked portal
BLOCKSOUND Sound will not traverse through a linked portal
OVERLAY The portal will render the sector's flat as a blended overlay
ADDITIVE If OVERLAY is also specified, the overlay will use additive blending
USEGLOBALTEX Reserved for future per-portal texture specification
ATTACHEDPORTAL If a linked portal is on the respective floor or ceiling, move it along
with the surface. Useful for vertically moving platforms.
---------------------------------------------------------------------------------------

====overlayalpha.floor/overlayalpha.ceiling====
:''Default'': 100%

These two fields (overlayalpha.floor and overlayalpha.ceiling) specify the opacity of the corresponding portal overlay, if any exists. You can specify either a percentage value from 0% to 100%, or a plain integer number from 0 to 255. 100%/255 are completely solid, while 0% is invisible.

====portalid.floor/portalid.ceiling====
:''Default'': 0

These two fields control the placement of portals defined by [[Portal_Define]] on the floor or ceiling of this sector. Values can be positive (in which case the direct portal will be used) or negative (in which case the opposite direction portal will be used, ''if'' applicable).

ExtraData

2026-06-14T14:11:34Z

Printz: /* extflags */

With support of [[Universal Doom Map Format]] in releases of Eternity, ExtraData is now considered {{Deprecated}}. In the future new features introduced into UDMF will not be supported by ExtraData. ExtraData maps will still work, but new projects should use UDMF due to its greatly streamlined mapping experience, especially if using editors such as [https://www.doomworld.com/forum/topic/96943 Doom Builder X] or [https://forum.zdoom.org/viewtopic.php?t=54957 GZDoomBuilder-Bugfix] are used (the former including specific improvements for Eternity's UDMF, such as for [[linked portals]]).

ExtraData is a new data specification language for the [[Eternity Engine]] that allows arbitrary extension of mapthings, lines, and sectors with any number of new fields, with data provided in more or less any format. The use of a textual input language forever removes any future problems caused by binary format limitations. The ExtraData parser is based on the libConfuse configuration file parser library by Martin Hedenfalk, which is also used by GFS and EDF.

Each section in this document deals with one of the ExtraData constructs, as well as how to embed ExtraData in a WAD and how to associate it with a given map.
{{Backto|Eternity Engine}}
{{editref}}
=General Syntax=
''See [[EDF#Syntax|EDF Syntax]], as it is the same.''

=Embedding and Associating ExtraData =

ExtraData is embedded directly as a text script into a lump of any name. This can be done with any number of wad file management tools, such as SLumpEd, SLADE 3, or XWE.

An ExtraData script is associated with a map via use of the [[MapInfo]] variable '''extradata'''. A map can only have one ExtraData script, but it is possible for multiple maps to share the same script.

Example of ExtraData specification via EMAPINFO:
[MAP01]
extradata = EDLUMP01

=Mapthings =

Mapthings define monsters, lamps, control points, items, etc -- anything that is spawned on the map at level start.

Each field in the mapthing definition, with the exception of the '''recordnum''' field, is optional. If a field is not provided, it takes on the default value indicated below the syntax information. Fields may also be provided in any order.

Note that the order of mapthing definitions in ExtraData is not important. The '''recordnum''' field serves to identify mapthing records.

==Creating ExtraData Control Objects ==

Mapthing records in ExtraData are only associated with a special control object that must be placed on the map in the usual manner.

The ExtraData control object has a '''doomednum''' of 5004. Each control object specifies its corresponding ExtraData mapthing record number as an integer value in its mapthing '''options''' field. If your editor does not allow entering arbitrary values into the options field of mapthings, you will need to use the BOOM command-line editor, CLED. As of the initial writing time of this document, both DETH and Doom Builder support entering arbitrary integer values for the options field. Check your editor's documentation or user interface to verify if it supports this.

The x, y, and angle fields of the ExtraData control object are passed on to the thing which will be spawned at the control point's location, so those fields of the control object should be set normally. The true type and options fields of the thing to be spawned, along with any extended fields, are specified in the ExtraData record.

Any number of ExtraData control objects can reference the same ExtraData record. In the event that a control object references a non-existent ExtraData record, the ExtraData script for a level is missing, or the thing type referenced by an ExtraData record isn't valid, an [[Unknown]] thing will be spawned at the control point's location. Note that you cannot spawn ExtraData control objects using ExtraData. Attempting this will also result in an Unknown thing.

==Mapthing Syntax and Fields ==

The syntax of the ExtraData mapthing record is as follows. Remember that all fields except the '''recordnum''' field are optional and can be specified in any order.
mapthing
{
recordnum <unique number>

// These fields are normal mapthing fields
type <doomednum> OR <EDF thingtype mnemonic>
options <options flag list>

// These fields are ExtraData extensions
tid <number>
special <number>
args { <special field>, ... }
height <number>
}
===Explanation of fields:===
====recordnum====
The recordnum serves to identify this record, and is the number which ExtraData control objects must use to associate themselves with a mapthing record. Every ExtraData mapthing record must have a unique record number. If a duplicate record number is detected, the engine will currently exit with an error message. The record number is limited to values between 0 and 65535 inclusive. Some editors may only allow input of numbers up to 32767 in the mapthing options field, or may treat values above 32767 as negative numbers. Beware of this.

====type====
Default: No meaningful default value; an Unknown thing will be spawned if not valid.

This field specifies the type of object to spawn at the location and angle of ExtraData control objects using this record. This field can accept one of two types of values. The first is a normal thingtype doomednum as specified via [[EDF]] and used by all editors. For example, the DOOM Imp's doomednum is 3001.

This field can also accept EDF thingtype mnemonics. EDF thingtype mnemonics must be prefixed with ''thing:'' -- this allows the parser to know it is dealing with a string instead of a number. EDF thingtypes must have a unique doomednum to be specified in an ExtraData mapthing record. If the specified EDF thingtype doesn't exist or has a doomednum of -1, an Unknown object will be spawned instead.

See [[Thing types]] for a list of potentially useful types, new to Eternity, to use here.

Example:
mapthing { type 3001 } // This record specifies an Imp via its doomednum

mapthing { type DoomImp } // This record specifies an Imp by its EDF mnemonic

====options====
Default: No flags are set by default.

This field specifies the options (also known as mapthing flags). This field uses the same syntax as BEX/EDF flag strings, but the syntax will be reviewed here for completeness.

A BEX flag list is a string of flag names separated by whitespace, pipe characters, commas, or plus characters. In ExtraData, if a flag list contains whitespace, commas, or plus signs, it must be enclosed in double or single quotations. Flags are combined using bitwise-OR logic, so a flag name can be specified more than once. Specifying a flag name causes that flag to be turned on. The default state of all flags is off.

These are the flag values which are available for this field:
Flag name Meaning
------------------------------------------------------------------------------
EASY Thing appears in easy difficulties
NORMAL Thing appears in "Hurt Me Plenty"
HARD Thing appears in Ultra-Violence and Nightmare
AMBUSH Thing is "deaf", will not wake up via sound
NOTSINGLE Thing doesn't appear in single-player mode
NOTDM Thing doesn't appear in deathmatch
NOTCOOP Thing doesn't appear in cooperative multiplayer
FRIEND Thing uses MBF friendly logic
DORMANT Thing is dormant at map startup (script feature)
STANDING Currently only used for [[Thing_types#Sector_actions|sector actions]].
------------------------------------------------------------------------------

The mapthing options value 256 (0x0100) is reserved. If this bit is set, all BOOM, MBF, and Eternity extended mapthing bits will be cleared. This is to guard against editors like Hellmaker which set all bits they do not understand, instead of leaving them zero.

Example options fields -- All of these are equivalent:
// This is the only syntax that does not require quotations.

mapthing { options EASY|NORMAL|HARD }

// All of these syntaxes must be quoted, because unquoted strings in
// ExtraData cannot contain spaces, commas, or plus signs.

mapthing { options "EASY NORMAL HARD" }
mapthing { options "EASY | NORMAL | HARD" }
mapthing { options "EASY+NORMAL+HARD" }
mapthing { options "EASY + NORMAL + HARD" }
mapthing { options "EASY,NORMAL,HARD" }
mapthing { options "EASY, NORMAL, HARD" }

====tid====
Default: 0

The TID, or "Thing ID", is a tag for mapthings which is used for identification in [[ACS]] scripts. TID values must be positive numbers between 1 and 65535. The TID value zero means no TID. Negative TID values are reserved and are used to indicate special things within the engine. TIDs are not required to be unique, and most ACS functions that accept TIDs will perform an action on all mapthings which bear the same TID.

====special====
Default: 0

The thing special field, which will execute when thing dies if it's a monster or picked up if it's an item. Use '''args''' to control the parameters.

====args====
Default: All args values default to zero.

The args field is a list of up to five special values which can have a broad range of meanings. Any values not provided in the args list will default, and if more than five values are provided, only the first five will be used. Currently, all args values are interpreted as integers (a non-number string evaluates to zero). This may change in the future.

Example args list:
mapthing { args { 0, 1, 2, 3, 4 } }

====height====
Default: 0

For normal objects, this field indicates a distance above the floor that the thing will spawn at level start. For objects with the SPAWNCEILING flag, this field indicates a distance below the ceiling instead. This field will have no effect on objects which spawn at a randomized height.

=Linedefs =

Linedefs define walls, two-sided textures, and provide action triggers within maps.

Each field in the linedef definition, with the exception of the '''recordnum''' field, is optional. If a field is not provided, it takes on the default value indicated below the syntax information. Fields may also be provided in any order.

Note that the order of linedef definitions in ExtraData is not important. The '''recordnum''' field serves to identify linedef records.

==Creating ExtraData Linedefs ==

Linedef records in ExtraData are associated either with lines which bear the ExtraData Control Line Special (270), or with any linedef in a DOOM-format map which uses a parameterized line special. You can place the 270 special, as well as parameterized special numbers, into the normal "special" field of a line using virtually any map editor. Editors with Eternity-specific configurations should support these specials natively.

Each control linedef (or directly-used parameterized special) specifies its corresponding ExtraData linedef record number as an integer value in its linedef tag field. If your editor does not allow entering arbitrary values up to 32767 into the tag field of linedefs, you will need to use the BOOM command-line editor, CLED. As of the initial writing time of this document, both DETH and Doom Builder support entering arbitrary integer values for the tag field. Check your editor's documentation or user interface to verify if it supports this.

The flags, sidedefs, textures, and location of the ExtraData control linedef are used normally by the line and cannot be altered from within ExtraData. The true special (if 270 is used) and tag fields of the linedef, along with any extended fields, are specified in the ExtraData record which the control linedef references.

Any number of linedefs can reference the same ExtraData record. In the event that a control linedef references a non-existent ExtraData record or the ExtraData script for a level is missing, the special and tag of the ExtraData control linedef will both be set to zero.

==Linedef Syntax and Fields ==

The syntax of the ExtraData linedef record is as follows. Remember that all fields except the '''recordnum''' field are optional and can be specified in any order.
linedef
{
recordnum <unique number>

// These fields are normal linedef fields
special <number> OR <special name>
tag <number>

// These fields are ExtraData extensions
extflags <extended line flags list>
args { <special field>, ... }
id <number>
alpha <number>

portalid <number>
}
===Explanation of fields: ===
====recordnum====
The recordnum serves to identify this record, and is the number which ExtraData control linedefs must use to associate themselves with a linedef record. Every ExtraData linedef record must have a unique record number. If a duplicate record number is detected, the engine will currently exit with an error message. The record number is limited to values between 0 and 32767 inclusive. Some editors may only allow input of numbers up to 255 in the linedef tag field. Beware of this.

====special====
:''Default: 0 ''

The special field determines what [[Linedef_types|type of action]] may be taken when a line is crossed, used, shot, etc. There are three types of linedef specials in Eternity: normal, generalized, and parameterized. Parameterized specials use the '''args''' field documented below to provide complete customization of line actions.

This field can accept numbers for any special type, including generalized and parameterized, but it can also accept special names for parameterized line types. See the [[Detailed parameterized linedef specification]] for a complete list of the available names.

====tag====
:''Default: 0 ''

The tag of the linedef, used by DOOM-style line specials and sector effects.

====extflags====
:''Default: No flags are set by default. ''

This field specifies extended linedef flag values which impact the functionality of parameterized linedef specials. This field uses the same syntax as BEX/EDF flag strings, but the syntax will be reviewed here for completeness.

A BEX flag list is a string of flag names separated by whitespace, pipe characters, commas, or plus characters. In ExtraData, if a flag list contains whitespace, commas, or plus signs, it must be enclosed in double or single quotations. Flags are combined using bitwise-OR logic, so a flag name can be specified more than once. Specifying a flag name causes that flag to be turned on. The default state of all flags is off.

These are the flag values which are available for this field:
Flag name Meaning
---------------------------------------------------------------------------------------
CROSS Linedef can be activated by being crossed.
USE Linedef can be activated by being used.
IMPACT Linedef can be activated by being shot.
PUSH Linedef can be activated by being pushed.
PLAYER Linedef can be activated by players.
MONSTER Linedef can be activated by objects with SPACMONSTER flag.
MISSILE Linedef can be activated by objects with SPACMISSILE flag.
POLYOBJECT Linedef can be activated by polyobjects (only works with CROSS)
REPEAT Linedef action is repeatable.
1SONLY Linedef can only be activated from first side.
ADDITIVE Linedef's midtexture is drawn with additive blending.
BLOCKALL Linedef will block everything that can be clipped.
ZONEBOUNDARY Linedef will work as a reverb effect boundary. Not needed for one-sided lines.
CLIPMIDTEX Linedef middle texture will not "bleed" on floor and ceiling.
WRAPMIDTEX Linedef middle texture of two-sided is repeated vertically instead of being drawn only once.
3DMDPASSPROJ Linedef will always let projectiles pass even if marked as 3DMidTex
LOWERPORTAL Linedef copies floor portal from its backside to its lower visible edge
UPPERPORTAL Linedef copies ceiling portal from its backside to its upper visible edge
---------------------------------------------------------------------------------------

Notes: IMPACT is currently only implemented for bullet weapons.

LOWERPORTAL and UPPERPORTAL are used to enable portals on the front side's upper and/or lower edges of a linedef, if the sector in front of the linedef is tall enough compared to the back sector to expose them. It is the only way to enable such portals, which will copy the sector portal(s) from the backside, if any.

Example flags fields -- All of these are equivalent:
// This is the only syntax that does not require quotations.

linedef { extflags CROSS|PLAYER|MISSILE|REPEAT }

// All of these syntaxes must be quoted, because unquoted strings in
// ExtraData cannot contain spaces, commas, or plus signs.

linedef { extflags "CROSS PLAYER MISSILE REPEAT" }
linedef { extflags "CROSS | PLAYER | MISSILE | REPEAT" }
linedef { extflags "CROSS+PLAYER+MISSILE+REPEAT" }
linedef { extflags "CROSS + PLAYER + MISSILE + REPEAT" }
linedef { extflags "CROSS,PLAYER,MISSILE,REPEAT" }
linedef { extflags "CROSS, PLAYER, MISSILE, REPEAT" }

====args====
:''Default: All args values default to zero. ''

The args field is a list of up to five special values which can have a broad range of meanings. Any values not provided in the args list will default, and if more than five values are provided, only the first five will be used. Currently, all args values are interpreted as integers (a non-number string evaluates to zero). This may change in the future. The args list is used by parameterized linedef specials.

Example args list:
linedef { args { 0, 1, 2, 3, 4 } }

====id====
:''Default: 0''
This field is equivalent to '''tag'''. It will only have effect if '''tag''' is not already set.

====alpha====
:''Default: Alpha defaults to 1.0.''

The alpha field takes a value from 0.0 to 1.0 to set the opacity at which this linedef's midtexture is drawn. When combined with the ADDITIVE extflag, this can be used for additive-blended translucency as well.

====portalid====
:''Default: none''

Portal ID to apply on front side middle part, as defined from [[Portal_Define]].

=Sectors=

Sectors define distinct areas of the map that are bordered by linedefs, with floor and ceiling properties, lighting data, and specials.

Each field in the sector definition, with the exception of the '''recordnum''' field, is optional. If a field is not provided, it takes on the default value indicated below the syntax information. Fields may also be provided in any order.

Note that the order of sector definitions in ExtraData is not important. The '''recordnum''' field serves to identify sector records.

==Creating ExtraData Sectors==

Sector records in ExtraData are associated with lines which bear the ExtraData Sector Control Special (401). The linedef's front side sector is the map sector that will receive properties from the ExtraData record which is specified by number in the linedef's tag.

Since ExtraData is attached to sectors via linedefs and not through overriding any of the sectors' native fields, you specify all of the normal data for a sector in the map itself, and overriding that data through ExtraData sector records is not supported.

Any number of linedefs can reference the same ExtraData sector record. In the event that a control linedef references a non-existent ExtraData record or the ExtraData script for a level is missing, the tag of the ExtraData sector control linedef will be set to zero and will otherwise be ignored.

==Sector Syntax and Fields ==

The syntax of the ExtraData sector record is as follows. Remember that all fields except the '''recordnum''' field are optional and can be specified in any order.
sector
{
recordnum <unique number>

// These fields are ExtraData extensions to sector data
flags <sector flag list>
flags.add <sector flag list>
flags.remove <sector flag list>
damage <integer>
damagemask <integer>
damagemod <method of damage type>
damageflags <sector damage flags list>
damageflags.add <sector damage flags list>
damageflags.remove <sector damage flags list>
floorterrain <terrain name>
floorangle <float>
flooroffsetx <float>
flooroffsety <float>
floorscalex <float>
floorscaley <float>
ceilingterrain <terrain name>
ceilingangle <float>
ceilingoffsetx <float>
ceilingoffsety <float>
ceilingscalex <float>
ceilingscaley <float>
colormaptop <lump name>
colormapmid <lump name>
colormapbottom <lump name>
portalflags.floor <portal flags list>
portalflags.ceiling <portal flags list>
overlayalpha.floor <percentage or value from 0 to 255>
overlayalpha.ceiling <percentage or value from 0 to 255>
portalid.floor <number>
portalid.ceiling <number>
}
===Explanation of fields: ===
====recordnum====
The recordnum serves to identify this record, and is the number which ExtraData sector control linedefs must use to associate themselves with a sector record. Every ExtraData sector record must have a unique record number. If a duplicate record number is detected, the engine will currently exit with an error message. The record number is limited to values between 0 and 32767 inclusive. Some editors may only allow input of numbers up to 255 in the linedef tag field. Beware of this.

====flags====
:''Default: No flags are set by default. ''

This field specifies sector flag values which specify various properties of sectors. This field uses the same syntax as BEX/EDF flag strings.

These are the flag values which are available for this field:

Flag name Meaning
---------------------------------------------------------------------------------------
SECRET Sector is secret
FRICTION Sector has friction enabled, if targeted by a BOOM friction transfer line
PUSH Sector has BOOM push effects enabled
KILLSOUND Objects in sector cannot make sounds.
KILLMOVESOUND Sector makes no movement sounds, even if it has a special sound sequence
PHASEDLIGHT Sector is phased light sequence start
LIGHTSEQUENCE Sector is phased light sequence step (alternates with below flag)
LIGHTSEQALT Sector is phased light sequence alternate step (alternates with above flag)
---------------------------------------------------------------------------------------

Example flags fields -- All of these are equivalent:
// This is the only syntax that does not require quotations.

sector { flags SECRET|FRICTION|KILLMOVESOUND }

// All of these syntaxes must be quoted, because unquoted strings in
// ExtraData cannot contain spaces, commas, or plus signs.

sector { flags "SECRET FRICTION KILLMOVESOUND" }
sector { flags "SECRET | FRICTION | KILLMOVESOUND" }
sector { flags "SECRET+FRICTION+KILLMOVESOUND" }
sector { flags "SECRET + FRICTION + KILLMOVESOUND" }
sector { flags "SECRET,FRICTION,KILLMOVESOUND" }
sector { flags "SECRET, FRICTION, KILLMOVESOUND" }

====flags.add====
:''Default: No flags are set by default. ''

This is a list of sector flags to add to the sector. This is supported because some sector specials (such as sector special 9, "Secret") imply that certain sector flags will be set on the sector before ExtraData is applied. If you wish to only add flags and not override any that may have been set by sector specials, use this field to specify only the flags that you wish to be added to the sector.

====flags.remove====
:''Default: No flags are set by default. ''

This is a list of sector flags to remove from the sector. If you wish to only remove flags and not override any that may have been set by sector specials, use this field to specify only the flags that you wish to be removed from the sector.

====damage====
:''Default: 0''

Specifies the amount of damage this sector does to players if the players are standing inside the sector and do not meet any special exemption criteria, such as wearing a Radiation Suit. This amount is done at each damage opportunity, which is determined by the '''damagemask''' field.

====damagemask====
:''Default: 0''

Specifies the interval in gametics between damage opportunities for a player standing in this sector. The default value of 0 will cause the sector to do constant and instantaneous damage every gametic. Setting this value to an integer greater than 0 will cause damage to be done every Nth gametic, with N being the value of this field. The default DOOM nukage types all use a damagemask of 32, which is roughly once per in-game second (there are 35 gametics per second).

====damagemod====
:''Default: "Unknown"''

Specifies the type of damage done by this sector. If "Unknown" is specified, the damage done is generic. The value specified should be a valid EDF damagetype mnemonic. If it is not, "Unknown" will be used. This can be used to have a sector type trigger special pain and death states when it deals damage. For example, you can use '''slime''' or '''lava''' damagemod.

====damageflags====
:''Default: No flags are set by default.''

This field specifies sector damage flag values which affect the manner in which a sector does damage. This field uses the same syntax as BEX/EDF flag strings.

These are the flag values which are available for this field:

Flag name Meaning
---------------------------------------------------------------------------------------
LEAKYSUIT The player may take damage at random even if he has the radsuit powerup
IGNORESUIT Radiation suit powerups are ignored entirely
ENDGODMODE God mode will be disabled when the player enters this sector
EXITLEVEL The player will exit if has < 11 health and this sector tries to do damage
TERRAINHIT A TerrainTypes hit will occur when this sector does damage
---------------------------------------------------------------------------------------

====damageflags.add====
:''Default: No flags are set by default.''

Because some sector types imply the activation of various sector damageflags (for example, DOOM sector type 11 sets sector damageflags ENDGODMODE and EXITLEVEL), this field is supported to add additional damageflags to any that may have been set by the map itself. Simply specify whatever flags you wish to have added to those that are already set.

====damageflags.remove====
:''Default: No flags are set by default.''

As with damageflags.add, it may be desirable to turn off some flags that were set by sector specials or other portions of the map data. Use this field to specify any sector damage flags you want to remove from sectors.

====floorterrain====
:''Default: "@flat"''

Specifies an EDF TerrainTypes mnemonic for the type of terrain this sector should exhibit on its floor. If left to default or specified with an invalid name, the terrain of the sector will be determined by its floorpic as usual.

====floorangle====
:''Default: 0 (East, or upper edge to the north)''

Specifies the angle of the floor flat in floating-point degrees from 0 to 359. Note that for compatibility with ZDoom, the angle specified advances in a '''clockwise''' fashion, contrary to most other angles in the DOOM engine.

====flooroffsetx/flooroffsety====
:''Default: 0''

Specifies the x and y offsets of the floor flat, relative to the normal floor grid, in floating point units.

====floorscalex/floorscaley====
:''Default: 1.0''

Specifies the x and y offsets of the floor flat. A higher number means a smaller texture.

====ceilingterrain====
:''Default: "@flat"''

Specifies an EDF TerrainTypes mnemonic for the type of terrain this sector should exhibit on its ceiling. If left to default or specified with an invalid name, the terrain of the sector will be determined by its floorpic as usual. This currently only affects the behavior of bullet puffs when particles are enabled.

====ceilingangle====
:''Default: 0 (East, or upper edge to the north)''

Specifies the angle of the ceiling flat in floating-point degrees from 0 to 359. Note that for compatibility with ZDoom, the angle specified advances in a '''clockwise''' fashion, contrary to most other angles in the DOOM engine.

====ceilingoffsetx/ceilingoffsety====
:''Default: 0''

Specifies the x and y offsets of the ceiling flat, relative to the normal ceiling grid, in floating point units.

====ceilingscalex/ceilingscaley====
:''Default: 1.0''

Specifies the x and y offsets of the ceiling flat. A higher number means a smaller texture.

====colormaptop====
:''Default: "@default"''

Specifies the colormap lump to use when a player's viewpoint is above the fake ceiling of a BOOM 242 "deep water" effect applying to this sector. If left to default, the global colormap from MapInfo will be used as normal, unless one is specified by the 242 effect.

====colormapmid====
:''Default: "@default"''

Specifies the colormap lump to use when a player's viewpoint is between the normal floor and ceiling for an ordinary sector, or between the fake floor and ceiling for a BOOM 242 "deep water" sector. If left to default, the global colormap from MapInfo will be used as normal, unless one is specified by a 242 effect.

====colormapbottom====
:''Default: "@default"''

Specifies the colormap lump to use when a player's viewpoint is below the fake floor of a BOOM 242 "deep water" effect applying to this sector. If left to default, the global colormap from MapInfo will be used as normal, unless one is specified by the 242 effect.

====portalflags.floor/portalflags.ceiling====
:''Default: No flags are set by default.''

These two fields (portalflags.floor and portalflags.ceiling) specify portal property flag values which affect the rendering and behavior of portals attached to this sector's surfaces. These fields use the same syntax as BEX/EDF flag strings.

These are the flag values which are available for this field:

Flag name Meaning
---------------------------------------------------------------------------------------
DISABLED Portal is completely disabled
NORENDER Portal will not be rendered, but may still be interactive
NOPASS Objects cannot pass through the portal even if it is a linked portal
BLOCKSOUND Sound will not traverse through a linked portal
OVERLAY The portal will render the sector's flat as a blended overlay
ADDITIVE If OVERLAY is also specified, the overlay will use additive blending
USEGLOBALTEX Reserved for future per-portal texture specification
ATTACHEDPORTAL If a linked portal is on the respective floor or ceiling, move it along
with the surface. Useful for vertically moving platforms.
---------------------------------------------------------------------------------------

====overlayalpha.floor/overlayalpha.ceiling====
:''Default'': 100%

These two fields (overlayalpha.floor and overlayalpha.ceiling) specify the opacity of the corresponding portal overlay, if any exists. You can specify either a percentage value from 0% to 100%, or a plain integer number from 0 to 255. 100%/255 are completely solid, while 0% is invisible.

====portalid.floor/portalid.ceiling====
:''Default'': 0

These two fields control the placement of portals defined by [[Portal_Define]] on the floor or ceiling of this sector. Values can be positive (in which case the direct portal will be used) or negative (in which case the opposite direction portal will be used, ''if'' applicable).

Thing types

2026-06-14T14:08:14Z

Printz: /* New to Eternity */

{{Backto|Editing reference}}
== New to BOOM ==
BOOM has implemented two new thing types as well, BoomPushPoint (5001), and BoomPullPoint (5002). These control the origin of the point source wind effect controlled by linedef type 226 in Doom format, or [[PointPush_SetForce]] in [[UDMF]], and set whether the wind blows towards or away from the origin depending on which is used.

== New to MBF ==

MBF introduces the following mapthing type:

*'''MBFHelperDog (DoomEd #888, DeHackEd #140)'''
:A dog similar to the one found in Wolfenstein. This dog is the one normally spawned with the player when the -dogs command-line option is used. It is not friendly by default, but must be given the FRIEND thing flag if you wish to make it so. Otherwise it will act as a normal enemy.

== New to SMMU ==

SMMU introduces the following mapthing type:

*'''SMMUCameraSpot (5003)'''
:A general-purpose camera place-holder. These cameras will be randomly chosen during "cool demo playback" and for a view of the level during the intermission.

== New to Eternity ==

Eternity introduces the following new mapthing types. Note that this list does not currently contain any Heretic mapthings, which may be documented in the future. Note that there are also some mapthing types within the engine which are not currently documented. Maps should refrain from using those things until they are made official, as they could change or be deleted later.

*'''EEEnviroSequence (1200 - 1300)'''
:This group of objects are all translated into EEEnviroSequence with DoomEdNum 1300. These objects are used to add environmental sound sequences to the environmental sequence manager. For types 1200 through 1299, the sequence number to add is type - 1200. For type 1300, the sequence number is the value in args[0] as specified via [[ExtraData]] or the Hexen map format.

*'''EESectorSequence (1400 - 1500)'''
:This group of objects are all translated into EESectorSequence with DoomEdNum 1500. These objects are used to assign sound sequences to sectors by number. For types 1400 through 1499, the sequence number is type - 1400. For type 1500, the sequence number is the value in args[0] as specified via [[ExtraData]] or the Hexen map format. For type 1500, if args[0] is 0, the sector is reset to default sound sequence behavior, even if the [[MapInfo]] variable "noautosequences" has been set to "true".

*'''ExtraData Thing Control Object (5004)'''
:This doomednum is used to reference an [[ExtraData]] mapthing record, the number of which must be placed in the options field of this mapthing. There is no [[EDF]] thingtype which corresponds to the ExtraData control point; it is only used during map startup to spawn the appropriate ExtraData-defined thing at the location and angle of this mapthing. In the cases that an ExtraData control object references an invalid ExtraData mapthing record, attempts to spawn another ExtraData control object, or references an unknown EDF thingtype mnemonic, the "Unknown" object described below will be spawned as a placeholder. If an EDF thingtype is used which has a doomednum of -1, no thing will be spawned at all. See the ExtraData Reference for full information.

*'''Unknown (5005)'''
:This thing type is used as a placeholder by EDF, ExtraData, and scripting. It may be spawned when an unknown thing type is requested, and its definition is required by the EDF language, so it is guaranteed to always exist. It uses DoomEd #5005 so that it can be used by ExtraData, but it will not generally be useful in maps.

*'''EESkyboxCam (5006)'''
:This thing type determines the origin for rendering of a skybox portal. See the [[Portals#Skybox_Portals|Skybox Portal]] documentation for complete information.

*'''EEParticleDrip (5007)'''
:A parameterized particle drip will be spawned at this mapthing's location with properties determined by the mapthing's ExtraData/Hexen arguments list. See the '''particlefx''' field documentation in the [[thingtype]] EDF Documentation for more information on particle effects, and see the [[ExtraData]] Documentation for full information on the ExtraData system.

*'''EEMapSpot (9001)'''
:This is a Hexen/ZDoom-compatible mapspot for scripting purposes. It is especially handy for playing sounds or spawning objects at a particular location without needing to remember the location's x/y/z coordinates.

*'''EEMapSpotGravity (9013)'''
:This object is exactly the same as EEMapSpot, but it will fall under gravity, allowing it to move up or down with sector floors/ceilings.

*'''EEParticleFountain (9027 - 9033)'''
:A particle fountain will be spawned at the mapthing's location. The fountain color depends on the mapthing number used, as follows:
:* 9027: Red
:* 9028: Green
:* 9029: Blue
:* 9030: Yellow
:* 9031: Purple
:* 9032: Black
:* 9033: White
*'''EEPolyObjAnchor (9300)'''
:This is a Hexen/zdoom-compatible PolyObject anchor spot. Each PolyObject defined in a map must have one and only one of these objects, and the object's angle field must be set to the PolyObject's integer id number. This spot determines the point relative to which lines will be translated and rotated.

*'''EEPolyObjSpawnSpot (9301)'''
:This is a Hexen/zdoom-compatible PolyObject spawn spot. Each PolyObject defined in a map must have one and only one of these objects, and the object's angle field must be set to the PolyObject's integer id number. This spot determines the exact location at which the PolyObject will start at the beginning of play on the map. The anchor spot will be translated exactly to this point, and all lines in the PolyObject are translated relative to it.

*'''EEPolyObjSpawnSpotCrush (9302)'''
:Exactly the same as EEPolyObjSpawnSpot, but PolyObjects which use this object instead will inflict damage upon shootable things which block the course of their movement at a rate of 3 HP/gametic (105 damage per second).

*'''EEPolyObjSpawnSpotDamage (9303)'''
:Harmful polyobject: this particular type of polyobject causes damage to any actor who touches it, without the need for crushing. It has the same doomednum as ZDoom's equivalent. New to Eternity 3.37.00.

*'''EEAmbience (14001 - 14065)'''
:This group of objects are all translated into EEAmbience with DoomEdNum 14065. These objects define control points that utilize [[EDF]] ambience definitions. For types 14001 through 14064, the ambience index used by that object is type - 14000. For type 14065, the ambience index used by the object is the value in args[0] as specified via [[ExtraData]] or the Hexen map format.

*'''EESoundEnvironment (9048)'''
:Partially ZDoom-compatible method of assigning an environmental effect to a sound zone. This thingtype uses its first two map arguments as the ID1 and ID2 to match an EDF reverb definition and assigns that definition to its spawn sector's sound zone.

*'''EENightmareSpectre (889; Dehacked number 158)'''
:Implements PlayStation Doom's subtractively blended spectre w/300 spawnhealth.

*'''EEPSXSpectre (890, Dehacked number 159)'''
:Implements PlayStation Doom's additive spectre.

*'''EEPSXBloodyChain (891, Dehacked number 160)'''
:Implements PlayStation Doom's bloody chain decorative object. A sprite is not included in eternity.pke. Requires BLCHA0 to be useful.

*'''EEBetaLostSoul (9037; Dehacked number 161)'''
:Slightly edited Lost Soul from the press release beta version of Doom.

*'''EEMusicChanger (14100 - 14165)'''
:Music changer from Risen3D and PrBoom+. You place it in the map. The player who steps inside the sector with this thing will have their music changed. For 14101-14164, see [[Doom Wiki:MUSINFO|MUSINFO]] in the Doom Wiki for info on how to use it. The MUSINFO lump is supported in Eternity. Type 14100 will reset the music to the current level music, while 14165 is the parameterized type, which will use the first argument.
:Another way to change music at runtime is to use [[ACS]] scripting with the [[LocalSetMusic]] function.
===Sector actions===
*'''EESectorActionEnter''' (9998), '''EESectorActionExit''' (9997)
:Special thing that triggers an [[Parameterized linedef specials|action special]] whenever someone enters or exits the sector this object is placed in at map startup. Use [[UDMF]] or [[ExtraData]] to provide it the special # and the args. You need to give it the following flags (in the editor or ExtraData) to control how it's activated:
:*deaf/ambush: can be activated by monsters;
:*dormant: can be activated by projectiles;
:*friend: cannot be activated by players;
:*standing (UDMF only): single-use only, not repeatable;

==Special==
DOOM thingtypes can now be spawned in other gamemodes' maps via use of DoomEd numbers in the 6000 range.

For a normal thingtype with a DoomEd number between 0 and 255, simply add 6000 to its DoomEd number. For example the Arch-vile, with a normal DoomEd number of 64, can be spawned in Heretic using DoomEd number 6064.

For DoomEd numbers in the 2000 and 3000 ranges, subtract 2000 or 3000 respectively and then add 6200 or 6300, respectively. For example, 3001 DoomImp can be spawned in Heretic using DoomEd number 6301.

==Credits==
This document uses text from the old documentation and new Bifrost feature list (eternity.mancubus.net/text/bifrost_docs.txt)
[[Category:Editing reference]]

Polyobject

2026-06-14T14:04:49Z

Printz:

PolyObjects are special sets of one-sided linedefs which, unlike any other lines, can be moved on the map during gameplay. Unlike the Hexen 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, 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 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.

The lines are typically one-sided walls, but two-sided line polyobjects are also possible.

==='''Method 1: The <code>Polyobj_StartLine</code> Special'''===

:The <code>348:Polyobj_StartLine('''polyobj_id''', '''mirror_id''')</code> 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 <code>Polyobj_StartLine</code> 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 <code>Polyobj_StartLine('''polyobj_id''', '''mirror_id''')</code> 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 <code>Polyobj_ExplicitLine</code> Special'''===

:The <code>349:Polyobj_ExplicitLine('''polyobj_id''', '''index''', '''mirror_id''')</code> 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 (via [[ExtraData]]) the <code>Polyobj_ExplicitLine</code> 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 argument '''#2''' set also to whatever their tag is (in this case again it's ''1'').

: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 '''LineDef id'''.

:Now, once the lines are added, it is necessary to define the control objects. This is exactly the same as it is for the <code>StartLine(...)</code> 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 <code>ExplicitLines'</code> 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 <code>Polyobj_ExplicitLine('''polyobj_id''', '''index''', '''mirror_id''')</code> are as follows:
:* ''polyobj_id'' : the unique ID number (greater than zero) of the PolyObject
:* ''index'' : 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 also includes PolyObject Doors discussed in the next section of this article.

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>

==Polyobjects with portals==
:See [[Linked_portals#Polyobject_portals | Polyobject portals]]

==Polyobjects with 2-sided lines==
Polyobjects made of 2-sided lines have always worked in all games which had polyobjects, but with limitations. Keep in mind that Polyobj_StartLine only works for closed polygons of linedefs going the same way. Otherwise, use Polyobj_ExplicitLine for all involved lines. You will need to use an OPEN [[ACS]] script with the [[SetLineSpecial]] and [[SetLineActivation]] if you want lines with Polyobj_ExplicitLine to have in-game activation effects. In Eternity, a polyobject can have any number of one-sided and two-sided lines.

As of Eternity 4.06.00, the following improvements have been made to 2-sided lines belonging to polyobjects:
# Passable lines no longer push things standing in their way, if they can just move into them (normally in Hexen they would push). Pushing will only happen on the category of solid things affected by the specific blocking type (monsters, players or both)
# Textures will retain their initial Y offset when the line moves across different sector elevations. Previously in Hexen they would always make sure the Y offset agrees to the current sectors where they're located.
# No more collision detection influenced by the source control sector. Previously in Hexen you would need to match the height of the control sector with the one of the game sector. Normally this wasn't an issue, because of the subsector restriction, which no longer exists in Eternity.
# 3DMidTex lines now work properly and as expected. You can use them as horizontal moving platforms.
# Impassable 2-sided lines also behave as transporters to things above if moving below sector portals.

[[category:Editing reference]]

ExtraData

2026-06-14T13:56:07Z

Printz: /* extflags */

With support of [[Universal Doom Map Format]] in releases of Eternity, ExtraData is now considered {{Deprecated}}. In the future new features introduced into UDMF will not be supported by ExtraData. ExtraData maps will still work, but new projects should use UDMF due to its greatly streamlined mapping experience, especially if using editors such as [https://www.doomworld.com/forum/topic/96943 Doom Builder X] or [https://forum.zdoom.org/viewtopic.php?t=54957 GZDoomBuilder-Bugfix] are used (the former including specific improvements for Eternity's UDMF, such as for [[linked portals]]).

ExtraData is a new data specification language for the [[Eternity Engine]] that allows arbitrary extension of mapthings, lines, and sectors with any number of new fields, with data provided in more or less any format. The use of a textual input language forever removes any future problems caused by binary format limitations. The ExtraData parser is based on the libConfuse configuration file parser library by Martin Hedenfalk, which is also used by GFS and EDF.

Each section in this document deals with one of the ExtraData constructs, as well as how to embed ExtraData in a WAD and how to associate it with a given map.
{{Backto|Eternity Engine}}
{{editref}}
=General Syntax=
''See [[EDF#Syntax|EDF Syntax]], as it is the same.''

=Embedding and Associating ExtraData =

ExtraData is embedded directly as a text script into a lump of any name. This can be done with any number of wad file management tools, such as SLumpEd, SLADE 3, or XWE.

An ExtraData script is associated with a map via use of the [[MapInfo]] variable '''extradata'''. A map can only have one ExtraData script, but it is possible for multiple maps to share the same script.

Example of ExtraData specification via EMAPINFO:
[MAP01]
extradata = EDLUMP01

=Mapthings =

Mapthings define monsters, lamps, control points, items, etc -- anything that is spawned on the map at level start.

Each field in the mapthing definition, with the exception of the '''recordnum''' field, is optional. If a field is not provided, it takes on the default value indicated below the syntax information. Fields may also be provided in any order.

Note that the order of mapthing definitions in ExtraData is not important. The '''recordnum''' field serves to identify mapthing records.

==Creating ExtraData Control Objects ==

Mapthing records in ExtraData are only associated with a special control object that must be placed on the map in the usual manner.

The ExtraData control object has a '''doomednum''' of 5004. Each control object specifies its corresponding ExtraData mapthing record number as an integer value in its mapthing '''options''' field. If your editor does not allow entering arbitrary values into the options field of mapthings, you will need to use the BOOM command-line editor, CLED. As of the initial writing time of this document, both DETH and Doom Builder support entering arbitrary integer values for the options field. Check your editor's documentation or user interface to verify if it supports this.

The x, y, and angle fields of the ExtraData control object are passed on to the thing which will be spawned at the control point's location, so those fields of the control object should be set normally. The true type and options fields of the thing to be spawned, along with any extended fields, are specified in the ExtraData record.

Any number of ExtraData control objects can reference the same ExtraData record. In the event that a control object references a non-existent ExtraData record, the ExtraData script for a level is missing, or the thing type referenced by an ExtraData record isn't valid, an [[Unknown]] thing will be spawned at the control point's location. Note that you cannot spawn ExtraData control objects using ExtraData. Attempting this will also result in an Unknown thing.

==Mapthing Syntax and Fields ==

The syntax of the ExtraData mapthing record is as follows. Remember that all fields except the '''recordnum''' field are optional and can be specified in any order.
mapthing
{
recordnum <unique number>

// These fields are normal mapthing fields
type <doomednum> OR <EDF thingtype mnemonic>
options <options flag list>

// These fields are ExtraData extensions
tid <number>
special <number>
args { <special field>, ... }
height <number>
}
===Explanation of fields:===
====recordnum====
The recordnum serves to identify this record, and is the number which ExtraData control objects must use to associate themselves with a mapthing record. Every ExtraData mapthing record must have a unique record number. If a duplicate record number is detected, the engine will currently exit with an error message. The record number is limited to values between 0 and 65535 inclusive. Some editors may only allow input of numbers up to 32767 in the mapthing options field, or may treat values above 32767 as negative numbers. Beware of this.

====type====
Default: No meaningful default value; an Unknown thing will be spawned if not valid.

This field specifies the type of object to spawn at the location and angle of ExtraData control objects using this record. This field can accept one of two types of values. The first is a normal thingtype doomednum as specified via [[EDF]] and used by all editors. For example, the DOOM Imp's doomednum is 3001.

This field can also accept EDF thingtype mnemonics. EDF thingtype mnemonics must be prefixed with ''thing:'' -- this allows the parser to know it is dealing with a string instead of a number. EDF thingtypes must have a unique doomednum to be specified in an ExtraData mapthing record. If the specified EDF thingtype doesn't exist or has a doomednum of -1, an Unknown object will be spawned instead.

See [[Thing types]] for a list of potentially useful types, new to Eternity, to use here.

Example:
mapthing { type 3001 } // This record specifies an Imp via its doomednum

mapthing { type DoomImp } // This record specifies an Imp by its EDF mnemonic

====options====
Default: No flags are set by default.

This field specifies the options (also known as mapthing flags). This field uses the same syntax as BEX/EDF flag strings, but the syntax will be reviewed here for completeness.

A BEX flag list is a string of flag names separated by whitespace, pipe characters, commas, or plus characters. In ExtraData, if a flag list contains whitespace, commas, or plus signs, it must be enclosed in double or single quotations. Flags are combined using bitwise-OR logic, so a flag name can be specified more than once. Specifying a flag name causes that flag to be turned on. The default state of all flags is off.

These are the flag values which are available for this field:
Flag name Meaning
------------------------------------------------------------------------------
EASY Thing appears in easy difficulties
NORMAL Thing appears in "Hurt Me Plenty"
HARD Thing appears in Ultra-Violence and Nightmare
AMBUSH Thing is "deaf", will not wake up via sound
NOTSINGLE Thing doesn't appear in single-player mode
NOTDM Thing doesn't appear in deathmatch
NOTCOOP Thing doesn't appear in cooperative multiplayer
FRIEND Thing uses MBF friendly logic
DORMANT Thing is dormant at map startup (script feature)
STANDING Currently only used for [[Thing_types#Sector_actions|sector actions]].
------------------------------------------------------------------------------

The mapthing options value 256 (0x0100) is reserved. If this bit is set, all BOOM, MBF, and Eternity extended mapthing bits will be cleared. This is to guard against editors like Hellmaker which set all bits they do not understand, instead of leaving them zero.

Example options fields -- All of these are equivalent:
// This is the only syntax that does not require quotations.

mapthing { options EASY|NORMAL|HARD }

// All of these syntaxes must be quoted, because unquoted strings in
// ExtraData cannot contain spaces, commas, or plus signs.

mapthing { options "EASY NORMAL HARD" }
mapthing { options "EASY | NORMAL | HARD" }
mapthing { options "EASY+NORMAL+HARD" }
mapthing { options "EASY + NORMAL + HARD" }
mapthing { options "EASY,NORMAL,HARD" }
mapthing { options "EASY, NORMAL, HARD" }

====tid====
Default: 0

The TID, or "Thing ID", is a tag for mapthings which is used for identification in [[ACS]] scripts. TID values must be positive numbers between 1 and 65535. The TID value zero means no TID. Negative TID values are reserved and are used to indicate special things within the engine. TIDs are not required to be unique, and most ACS functions that accept TIDs will perform an action on all mapthings which bear the same TID.

====special====
Default: 0

The thing special field, which will execute when thing dies if it's a monster or picked up if it's an item. Use '''args''' to control the parameters.

====args====
Default: All args values default to zero.

The args field is a list of up to five special values which can have a broad range of meanings. Any values not provided in the args list will default, and if more than five values are provided, only the first five will be used. Currently, all args values are interpreted as integers (a non-number string evaluates to zero). This may change in the future.

Example args list:
mapthing { args { 0, 1, 2, 3, 4 } }

====height====
Default: 0

For normal objects, this field indicates a distance above the floor that the thing will spawn at level start. For objects with the SPAWNCEILING flag, this field indicates a distance below the ceiling instead. This field will have no effect on objects which spawn at a randomized height.

=Linedefs =

Linedefs define walls, two-sided textures, and provide action triggers within maps.

Each field in the linedef definition, with the exception of the '''recordnum''' field, is optional. If a field is not provided, it takes on the default value indicated below the syntax information. Fields may also be provided in any order.

Note that the order of linedef definitions in ExtraData is not important. The '''recordnum''' field serves to identify linedef records.

==Creating ExtraData Linedefs ==

Linedef records in ExtraData are associated either with lines which bear the ExtraData Control Line Special (270), or with any linedef in a DOOM-format map which uses a parameterized line special. You can place the 270 special, as well as parameterized special numbers, into the normal "special" field of a line using virtually any map editor. Editors with Eternity-specific configurations should support these specials natively.

Each control linedef (or directly-used parameterized special) specifies its corresponding ExtraData linedef record number as an integer value in its linedef tag field. If your editor does not allow entering arbitrary values up to 32767 into the tag field of linedefs, you will need to use the BOOM command-line editor, CLED. As of the initial writing time of this document, both DETH and Doom Builder support entering arbitrary integer values for the tag field. Check your editor's documentation or user interface to verify if it supports this.

The flags, sidedefs, textures, and location of the ExtraData control linedef are used normally by the line and cannot be altered from within ExtraData. The true special (if 270 is used) and tag fields of the linedef, along with any extended fields, are specified in the ExtraData record which the control linedef references.

Any number of linedefs can reference the same ExtraData record. In the event that a control linedef references a non-existent ExtraData record or the ExtraData script for a level is missing, the special and tag of the ExtraData control linedef will both be set to zero.

==Linedef Syntax and Fields ==

The syntax of the ExtraData linedef record is as follows. Remember that all fields except the '''recordnum''' field are optional and can be specified in any order.
linedef
{
recordnum <unique number>

// These fields are normal linedef fields
special <number> OR <special name>
tag <number>

// These fields are ExtraData extensions
extflags <extended line flags list>
args { <special field>, ... }
id <number>
alpha <number>

portalid <number>
}
===Explanation of fields: ===
====recordnum====
The recordnum serves to identify this record, and is the number which ExtraData control linedefs must use to associate themselves with a linedef record. Every ExtraData linedef record must have a unique record number. If a duplicate record number is detected, the engine will currently exit with an error message. The record number is limited to values between 0 and 32767 inclusive. Some editors may only allow input of numbers up to 255 in the linedef tag field. Beware of this.

====special====
:''Default: 0 ''

The special field determines what [[Linedef_types|type of action]] may be taken when a line is crossed, used, shot, etc. There are three types of linedef specials in Eternity: normal, generalized, and parameterized. Parameterized specials use the '''args''' field documented below to provide complete customization of line actions.

This field can accept numbers for any special type, including generalized and parameterized, but it can also accept special names for parameterized line types. See the [[Detailed parameterized linedef specification]] for a complete list of the available names.

====tag====
:''Default: 0 ''

The tag of the linedef, used by DOOM-style line specials and sector effects.

====extflags====
:''Default: No flags are set by default. ''

This field specifies extended linedef flag values which impact the functionality of parameterized linedef specials. This field uses the same syntax as BEX/EDF flag strings, but the syntax will be reviewed here for completeness.

A BEX flag list is a string of flag names separated by whitespace, pipe characters, commas, or plus characters. In ExtraData, if a flag list contains whitespace, commas, or plus signs, it must be enclosed in double or single quotations. Flags are combined using bitwise-OR logic, so a flag name can be specified more than once. Specifying a flag name causes that flag to be turned on. The default state of all flags is off.

These are the flag values which are available for this field:
Flag name Meaning
---------------------------------------------------------------------------------------
CROSS Linedef can be activated by being crossed.
USE Linedef can be activated by being used.
IMPACT Linedef can be activated by being shot.
PUSH Linedef can be activated by being pushed.
PLAYER Linedef can be activated by players.
MONSTER Linedef can be activated by objects with SPACMONSTER flag.
MISSILE Linedef can be activated by objects with SPACMISSILE flag.
POLYOBJECT Linedef can be activated by polyobjects (only works with CROSS)
REPEAT Linedef action is repeatable.
1SONLY Linedef can only be activated from first side.
ADDITIVE Linedef's midtexture is drawn with additive blending.
BLOCKALL Linedef will block everything that can be clipped.
ZONEBOUNDARY Linedef will work as a reverb effect boundary. Not needed for one-sided lines.
CLIPMIDTEX Linedef middle texture will not "bleed" on floor and ceiling.
WRAPMIDTEX Linedef middle texture of two-sided is repeated vertically instead of being drawn only once.
LOWERPORTAL Linedef copies floor portal from its backside to its lower visible edge
UPPERPORTAL Linedef copies ceiling portal from its backside to its upper visible edge
---------------------------------------------------------------------------------------

Notes: IMPACT is currently only implemented for bullet weapons.

LOWERPORTAL and UPPERPORTAL are used to enable portals on the front side's upper and/or lower edges of a linedef, if the sector in front of the linedef is tall enough compared to the back sector to expose them. It is the only way to enable such portals, which will copy the sector portal(s) from the backside, if any.

Example flags fields -- All of these are equivalent:
// This is the only syntax that does not require quotations.

linedef { extflags CROSS|PLAYER|MISSILE|REPEAT }

// All of these syntaxes must be quoted, because unquoted strings in
// ExtraData cannot contain spaces, commas, or plus signs.

linedef { extflags "CROSS PLAYER MISSILE REPEAT" }
linedef { extflags "CROSS | PLAYER | MISSILE | REPEAT" }
linedef { extflags "CROSS+PLAYER+MISSILE+REPEAT" }
linedef { extflags "CROSS + PLAYER + MISSILE + REPEAT" }
linedef { extflags "CROSS,PLAYER,MISSILE,REPEAT" }
linedef { extflags "CROSS, PLAYER, MISSILE, REPEAT" }

====args====
:''Default: All args values default to zero. ''

The args field is a list of up to five special values which can have a broad range of meanings. Any values not provided in the args list will default, and if more than five values are provided, only the first five will be used. Currently, all args values are interpreted as integers (a non-number string evaluates to zero). This may change in the future. The args list is used by parameterized linedef specials.

Example args list:
linedef { args { 0, 1, 2, 3, 4 } }

====id====
:''Default: 0''
This field is equivalent to '''tag'''. It will only have effect if '''tag''' is not already set.

====alpha====
:''Default: Alpha defaults to 1.0.''

The alpha field takes a value from 0.0 to 1.0 to set the opacity at which this linedef's midtexture is drawn. When combined with the ADDITIVE extflag, this can be used for additive-blended translucency as well.

====portalid====
:''Default: none''

Portal ID to apply on front side middle part, as defined from [[Portal_Define]].

=Sectors=

Sectors define distinct areas of the map that are bordered by linedefs, with floor and ceiling properties, lighting data, and specials.

Each field in the sector definition, with the exception of the '''recordnum''' field, is optional. If a field is not provided, it takes on the default value indicated below the syntax information. Fields may also be provided in any order.

Note that the order of sector definitions in ExtraData is not important. The '''recordnum''' field serves to identify sector records.

==Creating ExtraData Sectors==

Sector records in ExtraData are associated with lines which bear the ExtraData Sector Control Special (401). The linedef's front side sector is the map sector that will receive properties from the ExtraData record which is specified by number in the linedef's tag.

Since ExtraData is attached to sectors via linedefs and not through overriding any of the sectors' native fields, you specify all of the normal data for a sector in the map itself, and overriding that data through ExtraData sector records is not supported.

Any number of linedefs can reference the same ExtraData sector record. In the event that a control linedef references a non-existent ExtraData record or the ExtraData script for a level is missing, the tag of the ExtraData sector control linedef will be set to zero and will otherwise be ignored.

==Sector Syntax and Fields ==

The syntax of the ExtraData sector record is as follows. Remember that all fields except the '''recordnum''' field are optional and can be specified in any order.
sector
{
recordnum <unique number>

// These fields are ExtraData extensions to sector data
flags <sector flag list>
flags.add <sector flag list>
flags.remove <sector flag list>
damage <integer>
damagemask <integer>
damagemod <method of damage type>
damageflags <sector damage flags list>
damageflags.add <sector damage flags list>
damageflags.remove <sector damage flags list>
floorterrain <terrain name>
floorangle <float>
flooroffsetx <float>
flooroffsety <float>
floorscalex <float>
floorscaley <float>
ceilingterrain <terrain name>
ceilingangle <float>
ceilingoffsetx <float>
ceilingoffsety <float>
ceilingscalex <float>
ceilingscaley <float>
colormaptop <lump name>
colormapmid <lump name>
colormapbottom <lump name>
portalflags.floor <portal flags list>
portalflags.ceiling <portal flags list>
overlayalpha.floor <percentage or value from 0 to 255>
overlayalpha.ceiling <percentage or value from 0 to 255>
portalid.floor <number>
portalid.ceiling <number>
}
===Explanation of fields: ===
====recordnum====
The recordnum serves to identify this record, and is the number which ExtraData sector control linedefs must use to associate themselves with a sector record. Every ExtraData sector record must have a unique record number. If a duplicate record number is detected, the engine will currently exit with an error message. The record number is limited to values between 0 and 32767 inclusive. Some editors may only allow input of numbers up to 255 in the linedef tag field. Beware of this.

====flags====
:''Default: No flags are set by default. ''

This field specifies sector flag values which specify various properties of sectors. This field uses the same syntax as BEX/EDF flag strings.

These are the flag values which are available for this field:

Flag name Meaning
---------------------------------------------------------------------------------------
SECRET Sector is secret
FRICTION Sector has friction enabled, if targeted by a BOOM friction transfer line
PUSH Sector has BOOM push effects enabled
KILLSOUND Objects in sector cannot make sounds.
KILLMOVESOUND Sector makes no movement sounds, even if it has a special sound sequence
PHASEDLIGHT Sector is phased light sequence start
LIGHTSEQUENCE Sector is phased light sequence step (alternates with below flag)
LIGHTSEQALT Sector is phased light sequence alternate step (alternates with above flag)
---------------------------------------------------------------------------------------

Example flags fields -- All of these are equivalent:
// This is the only syntax that does not require quotations.

sector { flags SECRET|FRICTION|KILLMOVESOUND }

// All of these syntaxes must be quoted, because unquoted strings in
// ExtraData cannot contain spaces, commas, or plus signs.

sector { flags "SECRET FRICTION KILLMOVESOUND" }
sector { flags "SECRET | FRICTION | KILLMOVESOUND" }
sector { flags "SECRET+FRICTION+KILLMOVESOUND" }
sector { flags "SECRET + FRICTION + KILLMOVESOUND" }
sector { flags "SECRET,FRICTION,KILLMOVESOUND" }
sector { flags "SECRET, FRICTION, KILLMOVESOUND" }

====flags.add====
:''Default: No flags are set by default. ''

This is a list of sector flags to add to the sector. This is supported because some sector specials (such as sector special 9, "Secret") imply that certain sector flags will be set on the sector before ExtraData is applied. If you wish to only add flags and not override any that may have been set by sector specials, use this field to specify only the flags that you wish to be added to the sector.

====flags.remove====
:''Default: No flags are set by default. ''

This is a list of sector flags to remove from the sector. If you wish to only remove flags and not override any that may have been set by sector specials, use this field to specify only the flags that you wish to be removed from the sector.

====damage====
:''Default: 0''

Specifies the amount of damage this sector does to players if the players are standing inside the sector and do not meet any special exemption criteria, such as wearing a Radiation Suit. This amount is done at each damage opportunity, which is determined by the '''damagemask''' field.

====damagemask====
:''Default: 0''

Specifies the interval in gametics between damage opportunities for a player standing in this sector. The default value of 0 will cause the sector to do constant and instantaneous damage every gametic. Setting this value to an integer greater than 0 will cause damage to be done every Nth gametic, with N being the value of this field. The default DOOM nukage types all use a damagemask of 32, which is roughly once per in-game second (there are 35 gametics per second).

====damagemod====
:''Default: "Unknown"''

Specifies the type of damage done by this sector. If "Unknown" is specified, the damage done is generic. The value specified should be a valid EDF damagetype mnemonic. If it is not, "Unknown" will be used. This can be used to have a sector type trigger special pain and death states when it deals damage. For example, you can use '''slime''' or '''lava''' damagemod.

====damageflags====
:''Default: No flags are set by default.''

This field specifies sector damage flag values which affect the manner in which a sector does damage. This field uses the same syntax as BEX/EDF flag strings.

These are the flag values which are available for this field:

Flag name Meaning
---------------------------------------------------------------------------------------
LEAKYSUIT The player may take damage at random even if he has the radsuit powerup
IGNORESUIT Radiation suit powerups are ignored entirely
ENDGODMODE God mode will be disabled when the player enters this sector
EXITLEVEL The player will exit if has < 11 health and this sector tries to do damage
TERRAINHIT A TerrainTypes hit will occur when this sector does damage
---------------------------------------------------------------------------------------

====damageflags.add====
:''Default: No flags are set by default.''

Because some sector types imply the activation of various sector damageflags (for example, DOOM sector type 11 sets sector damageflags ENDGODMODE and EXITLEVEL), this field is supported to add additional damageflags to any that may have been set by the map itself. Simply specify whatever flags you wish to have added to those that are already set.

====damageflags.remove====
:''Default: No flags are set by default.''

As with damageflags.add, it may be desirable to turn off some flags that were set by sector specials or other portions of the map data. Use this field to specify any sector damage flags you want to remove from sectors.

====floorterrain====
:''Default: "@flat"''

Specifies an EDF TerrainTypes mnemonic for the type of terrain this sector should exhibit on its floor. If left to default or specified with an invalid name, the terrain of the sector will be determined by its floorpic as usual.

====floorangle====
:''Default: 0 (East, or upper edge to the north)''

Specifies the angle of the floor flat in floating-point degrees from 0 to 359. Note that for compatibility with ZDoom, the angle specified advances in a '''clockwise''' fashion, contrary to most other angles in the DOOM engine.

====flooroffsetx/flooroffsety====
:''Default: 0''

Specifies the x and y offsets of the floor flat, relative to the normal floor grid, in floating point units.

====floorscalex/floorscaley====
:''Default: 1.0''

Specifies the x and y offsets of the floor flat. A higher number means a smaller texture.

====ceilingterrain====
:''Default: "@flat"''

Specifies an EDF TerrainTypes mnemonic for the type of terrain this sector should exhibit on its ceiling. If left to default or specified with an invalid name, the terrain of the sector will be determined by its floorpic as usual. This currently only affects the behavior of bullet puffs when particles are enabled.

====ceilingangle====
:''Default: 0 (East, or upper edge to the north)''

Specifies the angle of the ceiling flat in floating-point degrees from 0 to 359. Note that for compatibility with ZDoom, the angle specified advances in a '''clockwise''' fashion, contrary to most other angles in the DOOM engine.

====ceilingoffsetx/ceilingoffsety====
:''Default: 0''

Specifies the x and y offsets of the ceiling flat, relative to the normal ceiling grid, in floating point units.

====ceilingscalex/ceilingscaley====
:''Default: 1.0''

Specifies the x and y offsets of the ceiling flat. A higher number means a smaller texture.

====colormaptop====
:''Default: "@default"''

Specifies the colormap lump to use when a player's viewpoint is above the fake ceiling of a BOOM 242 "deep water" effect applying to this sector. If left to default, the global colormap from MapInfo will be used as normal, unless one is specified by the 242 effect.

====colormapmid====
:''Default: "@default"''

Specifies the colormap lump to use when a player's viewpoint is between the normal floor and ceiling for an ordinary sector, or between the fake floor and ceiling for a BOOM 242 "deep water" sector. If left to default, the global colormap from MapInfo will be used as normal, unless one is specified by a 242 effect.

====colormapbottom====
:''Default: "@default"''

Specifies the colormap lump to use when a player's viewpoint is below the fake floor of a BOOM 242 "deep water" effect applying to this sector. If left to default, the global colormap from MapInfo will be used as normal, unless one is specified by the 242 effect.

====portalflags.floor/portalflags.ceiling====
:''Default: No flags are set by default.''

These two fields (portalflags.floor and portalflags.ceiling) specify portal property flag values which affect the rendering and behavior of portals attached to this sector's surfaces. These fields use the same syntax as BEX/EDF flag strings.

These are the flag values which are available for this field:

Flag name Meaning
---------------------------------------------------------------------------------------
DISABLED Portal is completely disabled
NORENDER Portal will not be rendered, but may still be interactive
NOPASS Objects cannot pass through the portal even if it is a linked portal
BLOCKSOUND Sound will not traverse through a linked portal
OVERLAY The portal will render the sector's flat as a blended overlay
ADDITIVE If OVERLAY is also specified, the overlay will use additive blending
USEGLOBALTEX Reserved for future per-portal texture specification
ATTACHEDPORTAL If a linked portal is on the respective floor or ceiling, move it along
with the surface. Useful for vertically moving platforms.
---------------------------------------------------------------------------------------

====overlayalpha.floor/overlayalpha.ceiling====
:''Default'': 100%

These two fields (overlayalpha.floor and overlayalpha.ceiling) specify the opacity of the corresponding portal overlay, if any exists. You can specify either a percentage value from 0% to 100%, or a plain integer number from 0 to 255. 100%/255 are completely solid, while 0% is invisible.

====portalid.floor/portalid.ceiling====
:''Default'': 0

These two fields control the placement of portals defined by [[Portal_Define]] on the floor or ceiling of this sector. Values can be positive (in which case the direct portal will be used) or negative (in which case the opposite direction portal will be used, ''if'' applicable).

3DMidTex tutorial

2026-06-14T13:54:55Z

Printz:

[[Eternity]] provides the possibility of using the middle textures of linedefs as solid objects that can be walked over or under, and can block map object passage. Monsters can walk across them, and they can even be moved (with the assistance of some linedef specials) to create lifts, doors, anything you like. They are quite useful and easy to implement.

This feature is called [[3DMidTex]], and this tutorial covers the basics of how to use it. Once you are finished with here, you may want to read [[3DMidTex advanced topics]] to learn about the use of 3DMidTex lines with switches, doors, and lifts.

== Your first 3D bridge ==

For the purposes of this tutorial, I'll assume you are familiar with Doom editing and your level editor, and with the use of middle textures. You will need to use an editor that either has support for Eternity features (e.g. [[Doom wiki:Doom Builder|Doom Builder]]) or an editor that allows you to manually change the flags value for linedefs.

First, open up a new Doom 2 level for editing, and create a simple room with a pit running through it.

[[Image:3dmidtex_tut1.jpg]]

(I added cool, ultra-hurty lava to mine)

Now you need to create the structure the player will eventually be able to cross to get to safety. Again, I assume you know how to create two sided lines and place and align middle textures in them.

[[Image:3dmidtex_tut2.jpg]]

If you run this map, the player obviously falls down through your middle texture bridge. So we perform the final step: setting the lindef flag. The flag is 1024 (0x400 in HEX), so if you are editing the flags yourself, just add 1024 to your flag value; if you are using Doom Builder, and you don't see the lindef flag called "3dMidTex", press F2 and make sure you are editing your map as an Eternity map. Once your flags are set for your linedefs, run the map, and the player should now be able to cross the bridge as if the middle textures were solid objects.

== Some things to watch out for ==

=== Holes in your structures ===

Each structure needs to be closed enough to support the objects running over it. That is, the lines need to be close enough together so that an object can't slip through the gaps.

[[Image:3dmidtex_tut3.jpg]]

=== Clipping ===

It is important to note that clipping is determined by the '''front side''' offset and texture height, so if both sides of the 3DMidTex aren't aligned to be in the same spot or the textures are different heights, the solid part of the line will be where the front side texture is. 3DMidTex lines will only block objects and not bullets. So a 3DMidTex will stop a rocket but not a shotgun blast.

Also, please note that the entire height of the texture is considered solid regardless of the transparency of the texture. So the player can't pass through a 64x32 unit hole in a texture.

=== Monsters crossing ===

Because of the way monster AI in Doom works, it can be VERY tricky to get monsters to cross a 3D bridge. When a monster contacts a line in a map with a drop that's too far for it, the monster will not cross that line, because the engine assumes there is nothing on the other side for the monster to step on. Here are some tips to help you overcome this.

When a monster comes in contact with a 3DMidTex line that it can stand on (i.e., is not under or high above) the monster will ignore all lines with big drop-offs that it would otherwise not cross. The easiest way is to ensure that the monster will not cross any big dropoff lines before stepping on a 3DMidTex line. One way to do this is to create stair steps on either side of your bridge that drop 16 units down, and place a 3DMidTex line inside the niche you just created.

[[Image:3dmidtex_tut4.jpg]]

Now monsters are much more likely to cross your bridge. Another thing to note is that monsters have no idea which line is the edge of the 3D bridge, and will hang off the edges. They won't fall down, so don't worry, but it just looks bad. One remedy is to make the outer edges monster impassible. When the 3DMidTex flag and this are used in conjunction, monsters will be blocked when they try to cross on top of that 3DMidTex; however, they won't be blocked by going under it.

Now that you've mastered the art of the 3D bridge, you should give [[3DMidTex advanced topics]] a try.

=== Wrap-midtex ===
If the UDMF '''wrapmidtex''' or ExtraData '''WRAPMIDTEX''' flag is set, the texture will visually continue by the entire height of the area, and as such, the 3DMidTex blocking will also cover the entire area.

==See also==
*[[3DMidTex advanced topics]]
*[[Linked portal]] (see also "Edge portals" and "Attached portals" for solid-looking 3D bridges).

[[Category:Tutorials]]

3DMidTex advanced topics

2026-06-14T13:52:57Z

Printz:

[[3DMidTex]] are useful for more than just bridges. This tutorial will walk you through the process of making a door, a lift, and a floating switch. If you have not read the first tutorial, you may want to read [[3DMidTex tutorial]].

== 3DMidTex switches ==
When a 3DMidTex line has a linedef switch special, the 3DMidTex acts as the switch, and is height restrictive. This means the player has to be touching the switch (on the Z axis, as well as X and Y) to trigger it.

== Linking a 3DMidTex to sector movement ==
[[Eternity]] provides linedef specials which allow you to link sector movement (either floor or ceiling) to 3DMidTex lines. Using these specials you can create any kind of moving structure.

:On [[UDMF]] or [[ExtraData]]: [[Sector_Attach3dMidtex]]
:On the classic Doom format:
::Special 281 - Link linedef front sector floor movement to all tagged 3DMidTex lines.
::Special 282 - Link linedef front sector ceiling movement to all tagged 3DMidTex lines.

(Note: In [[Doom wiki:Doom Builder|Doom Builder]]'s current Eternity configuration, these specials can be found in the "Sector" category.)

=== Making a 3D door ===
Making a 3DMidTex door is very simple. First, create the door.

[[Image:3dmidtex_tut5.jpg]]

Here, the example door is in the middle of a bridge that crosses a large expanse, and a fence has been built on either side of the bridge to prevent the player from running around the door. Notice the door is made into two lines, both lines having their front sides facing out. Set the special of both these lines to [[Door_Raise]] (or on Doom format: 63, "SR Open door wait close") and set their tags to 1 (if on [[UDMF]], also set the first argument of [[Door_Raise]] to 1). If you run the map right now, nothing will happen because these two lines comprise the door that the player will interact with. The actual movement is going to be caused off screen.

Create a small sector out of the way. Set the floor height to 0, the ceiling height to 0 (so it's closed) and set the tag to 1. This sector will become the sector that moves the 3DMidTex door, and this door will be triggered when the player presses on the 3DMidTex door. Next, create another sector attached to your first one. Set the floor to 0, the ceiling to 64 and set the tag to 0. This sector will give the door sector you just created a height to raise up to.

Last, set one of the linedefs of the door sector (make sure it's one that faces in the door sector) to have a [[Sector_Attach3dMidtex]] special with ''do_ceiling'' set to 1 (or give it linedef special 282 on the Doom format), and the ''line_id'' (or tag on the Doom format) of 1. This links the movement of the sector's ceiling to the 3DMidTex door (which you will remember also has a tag of 1).

[[Image:3dmidtex_tut6.jpg]]

Now simply run the map and press on the 3DMidTex door. The door should now raise up, wait for 3 seconds, and close. If the player is caught under the door, it will now close (just like if the player was caught under a sector ceiling closing) because the link is two way. This also means that crushing ceilings will cause 3DMidTex lines to do damage to things when they are caught.

==Making a polyobject 3DMidTex moving platform==
A polyobject may be made of two-sided lines, not just one-sided walls. Such two-sided lines can be marked as 3DMidTex. Objects currently standing on top of such 3DMidTex lines will be transported when the polyobject moves. Pushing and crushing will only happen if the touched objects stand in the way of the 3dmidtex lines of the polyobject. It is also possible to move the lines vertically using the sector linking mechanism.

==See also==
*[[3DMidTex]]
*[[Linked portal]] (see also "Edge portals" and "Attached portals" for solid-looking 3D bridges).

[[Category:Tutorials]]

UDMF

2026-06-14T13:50:11Z

Printz: /* Linedefs */

UDMF is the extensible format that replaces the classic Doom format and [[ExtraData]]. Each level, instead of being defined by the classic lumps (THINGS, LINEDEFS, SIDEDEFS etc.) is defined by a human-readable lump named TEXTMAP, and can have associated lumps (e.g. ZNODES, BLOCKMAP, REJECT if needed) and other lumps, until a marker lump named ENDMAP.

TEXTMAP has a well-defined language. Check the UDMF article at doomwiki.org. Each game and port has its own namespace(s), for example we have these namespaces: "doom", "heretic", "hexen", "strife", "zdoom" and others. Eternity has the "eternity" namespace.

At its core, UDMF is made of many blocks, each titled "vertex", "sector", "sidedef", "linedef", "thing" and containing several properties, some mandatory, others optional. Each game or port namespace can define its own set, which is typically hard-coded, though it's also possible for the user to add their own fields (which have to be preceded by a safe prefix, to avoid conflicts with the standard).

Maps designed in UDMF no longer need ExtraData.

The standard was defined by James "Quasar" Haley and has also been successfully implemented in Vavoom, ZDoom and the ZDoom-derivative ports.

* See also the [https://www.doomworld.com/eternity/engine/stuff/udmf11.txt base UDMF specifications]

==Basics==

Eternity supports the "doom" and "eternity" namespaces. In the rest of this article, we'll detail the "eternity" namespace. See the [https://www.doomworld.com/eternity/engine/stuff/udmf11.txt base UDMF specifications] for the options not detailed in this document.

A TEXTMAP for Eternity must start with this:
namespace = "eternity";

===Eternity compatibility===
You can also add the following field in UDMF TEXTMAP:
ee_compat = true;
which, no matter the namespace used (e.g. "zdoom"), assumes the map is going to work in Eternity. In other words, it is equivalent to setting namespace as "eternity". Any fields not supported by Eternity, however, may make the mod fail.

===Node format===

Nodes for UDMF use the uncompressed GL-nodes format under the ZNODES name. Tools such as ZDBSP should build such a lump upon detecting a TEXTMAP lump.

==Linedefs==
linedef
{
blocklandmonsters = <boolean>;
blockplayers = <boolean>;

polycross = <boolean>;
monstershoot = <boolean>;

midtex3d = <boolean>;
firstsideonly = <boolean>;
blockeverything = <boolean>;
zoneboundary = <boolean>;
clipmidtex = <boolean>;
wrapmidtex = <boolean>;
midtex3dimpassible = <boolean>;
lowerportal = <boolean>;
upperportal = <boolean>;

portal = <integer>;

alpha = <floating-point>; // default 1.0
renderstyle = <string>;
tranmap = <string>;
}
===Explanation of fields===
*'''blocklandmonsters'''
:If true, linedef blocks walking monsters but allows fliers to pass. Players can pass anyway.
*'''blockplayers'''
:If true, linedef blocks players but allows monsters and projectiles to pass.
*'''polycross'''
:If true, linedef is activated when a polyobject's center point crosses it.
*'''monstershoot'''
:If true, linedef is activated when a monster fires hitscan on it.
*'''midtex3d'''
:If true, this linedef's middle texture uses [[3DMidTex_tutorial|3dmidtex]] physics.
*'''firstsideonly'''
:Linedef can only be activated from front side.
*'''blockeverything'''
:Linedef blocks all objects, acting like an external solid wall
*'''zoneboundary'''
:Linedef acts like a boundary for [[EDF_sound_reference#Sound_environments|reverb]] effects.
*'''clipmidtex'''
:Middle texture of two-sided line is clipped against the floor or ceiling as if a light change took place.
*'''wrapmidtex'''
:Middle texture of two-sided is repeated vertically instead of being drawn only once. This will make '''midtex3d''' lines also physically occupy the whole vertical space.
*'''midtex3dimpassible'''
:Treat the 3dmidtex line as a classic impassable middle texture, with regards to projectiles (i.e. they will pass through, just like hitscans).
*'''lowerportal''', '''upperportal'''
:Apply [[edge portals|edge portal]] on the lower or upper part of this linedef, copying back sector's floor or ceiling portal into it.
*'''portal'''
:The ID of the portal to apply on this linedef, as defined from [[Portal_Define]]
*'''alpha''' (default: 1.0)
:Opacity of this line.
*'''renderstyle'''
:Either "translucent" or "add". Default is "".
*'''tranmap'''
:Boom [[translucency map]]. Mutually exclusive with alpha and renderstyle.

==Sidedefs==
sidedef
{
offsetx = <floating-point>;
offsety = <floating-point>;
offsetx_top = <floating-point>;
offsety_top = <floating-point>;
offsetx_mid = <floating-point>;
offsety_mid = <floating-point>;
offsetx_bottom = <floating-point>;
offsety_bottom = <floating-point>;

scalex_top = <floating-point>;
scaley_top = <floating-point>;
scalex_mid = <floating-point>;
scaley_mid = <floating-point>;
scalex_bottom = <floating-point>;
scaley_bottom = <floating-point>;

light = <integer>;
lightabsolute = <boolean>;
light_top = <integer>;
lightabsolute_top = <boolean>;
light_mid = <integer>;
lightabsolute_mid = <boolean>;
light_bottom = <integer>;
lightabsolute_bottom = <boolean>;

skew_top_type = <string>;
skew_middle_type = <string>;
skew_bottom_type = <string>;
}

===Explanation of fields===
*'''offsetx''', '''offsety'''
:Overall horizontal and vertical offsets for the top, middle, and bottom textures of this sidedef.
*'''offsetx_top''', '''offsety_top''', '''offsetx_mid''', '''offsety_mid''', '''offsetx_bottom''', '''offsety_bottom'''
:Horizontal and vertical offsets for the individual top, middle, and bottom portions of this sidedef.
*'''scalex_top''', '''scaley_top''', '''scalex_mid''', '''scaley_mid''', '''scalex_bottom''', '''scaley_bottom'''
:Horizontal and vertical scaling of parts of the sidedef.
*'''light''', '''light_top''', '''light_mid''', '''light_bottom''', '''lightabsolute''', '''lightabsolute_top''', '''lightabsolute_mid''', '''lightabsolute_bottom'''
:Brightness for the whole, and the individual top, middle, and bottom portions of this sidedef. By default the values are additive to the inherited brightness. If the "absolute" properties are set to "true" the values are not additive anymore, but absolute.
*'''skew_top_type''', '''skew_bottom_type''', '''skew_middle_type'''
:The type of skewing that the a given texture of this sidedef has. This skew starts at the left side of the sidedef (if viewing the sidedef straight-on) and conforms to either the slope on the front or back side of the line the sidedef is on. Either the floor or ceiling slope can be picked as the slope for the skewing to conform to. Values are "none", "front_floor", "front_ceiling", "back_floor", and "back_ceiling", with "none" being the default.

==Vertices==
No change yet from the base "doom" namespace.
==Sectors==
sector
{
heightfloor = <floating-point>;
heightceiling = <floating-point>;

xpanningfloor = <floating-point>;
ypanningfloor = <floating-point>;
xpanningceiling = <floating-point>;
ypanningceiling = <floating-point>;

xscalefloor = <floating-point>;
yscalefloor = <floating-point>;
xscaleceiling = <floating-point>;
yscaleceiling = <floating-point>;
rotationfloor = <floating-point>;
rotationceiling = <floating-point>;

secret = <boolean>;
friction = <integer>;

leakiness = <integer>;
damageamount = <integer>;
damageinterval = <integer>;
damage_endgodmode = <boolean>;
damage_exitlevel = <boolean>;
damageterraineffect = <boolean>;
damagetype = <string>;

floorterrain = <string>;
ceilingterrain = <string>;

lightfloor = <integer>;
lightceiling = <integer>;
lightfloorabsolute = <boolean>;
lightceilingabsolute = <boolean>;

phasedlight = <boolean>;
lightsequence = <boolean>;
lightseqalt = <boolean>;

colormaptop = <string>;
colormapmid = <string>;
colormapbottom = <string>;

scroll_ceil_x = <floating-point>;
scroll_ceil_y = <floating-point>;
scroll_ceil_type = <string>;
scroll_floor_x = <floating-point>;
scroll_floor_y = <floating-point>;
scroll_floor_type = <string>;

floorid = <integer>;
ceilingid = <integer>;
attachfloor = <integer>;
attachceiling = <integer>;

soundsequence = <string>;

portalfloor = <integer>;
portalceiling = <integer>;

portal_floor_disabled = <boolean>;
portal_floor_norender = <boolean>;
portal_floor_nopass = <boolean>;
portal_floor_blocksound = <boolean>;
portal_floor_useglobaltex = <boolean>;
portal_floor_overlaytype = <string>;
alphafloor = <floating-point>;
portal_floor_attached = <boolean>;

portal_ceil_disabled = <boolean>;
portal_ceil_norender = <boolean>;
portal_ceil_nopass = <boolean>;
portal_ceil_blocksound = <boolean>;
portal_ceil_useglobaltex = <boolean>;
portal_ceil_overlaytype = <string>;
alphaceiling = <floating-point>;
portal_ceil_attached = <boolean>;
}

=== Explanation of fields ===
*'''heightfloor''', '''heightceiling''' (mandatory)
:Unlike the base field from the core specs, these ones allow floating-point values.
*'''xpanningfloor''', '''ypanningfloor''', '''xpanningceiling''', '''ypanningceiling'''
:These properties control the panning of the floor or ceiling flat.
*'''xscalefloor''', '''yscalefloor''', '''xscaleceiling''', '''yscaleceiling''' (default: 1.0)
:These properties control the scaling of the floor or ceiling flat. Greater values result in smaller textures.
*'''rotationfloor''', '''rotationceiling'''
:These properties control the clockwise rotation of the floor or ceiling flat, in degrees.
*'''secret'''
:If true, the sector counts as a secret when visited by player.
*'''friction''' (default: -1)
:This one controls the friction of movement on the floor. The value of this field is equivalent to the length of a horizontal linedef with the classic Boom friction special. Default value: -1 (use usual Doom friction).
*'''leakiness'''
:This one controls the probability that, if this sector is also damaging, it will leak damage through the radiation suit. As reference, the classic Doom 20% sector has 5 leakiness. For damage which always goes through the suit, use 256.
*'''damageamount'''
:Damage per hit for players on the floor.
*'''damageinterval'''
:Time between hits. The classic Doom damaging floors use a 32 period.
*'''damage_endgodmode'''
:If true, it will cause the damaging floor to disable the godmode cheat.
*'''damage_exitlevel'''
:If true, it will cause the damaging floor to exit the level in victory if the player has too little health.
*'''damageterraineffect'''
:If true, then each damage hit will produce a splash, like the Heretic lava.
*'''damagetype''' (default: "Unknown")
:The [[damagetype|damage type]] of the floor. For Doom damaging floors you can use "Slime".
*'''floorterrain''' (default: "@flat")
:The [[terrain]] effect of the floor.
*'''ceilingterrain''' (default: "@flat")
:The [[terrain]] effect of the ceiling. Currently used for particle recolouring.
*'''lightfloor''', '''lightceiling'''
:The light amount to add to the floor or ceiling, relative to the designated light level.
*'''lightfloorabsolute''', '''lightceilingabsolute'''
:If true, then '''lightfloor''' or '''lightceiling''' just overrides the light.
* phasedlight = <boolean>;
:Equivalent to ExtraData flag.
* lightsequence = <boolean>;
:Equivalent to ExtraData flag.
* lightseqalt = <boolean>;
:Equivalent to ExtraData flag.
*'''colormaptop''', '''colormapmid''', '''colormapbottom''' (default: "@default")
:The colormap to set for the top, normal or bottom part of a Boom sector with fake flats. Or for any normal part, if it's '''colormapmid'''. Use a lump from between '''C_START''' and '''C_END'''. "WATERMAP" and "LAVAMAP" are provided by Eternity.
*'''scroll_ceil_x''', '''scroll_ceil_y''', '''scroll_floor_x''', '''scroll_floor_y'''
:These fields make the sector ceiling or floor scroll at startup. The values you input there are the equivalents of a Boom trigger linedef length divided by 10. So to emulate a linedef pointing east of length 64 having a scroll trigger, set value 6.4 on '''scroll_ceil_x''' or '''scroll_floor_x'''.
*'''scroll_ceil_type''', '''scroll_floor_type''' (default: "none")
:These fields control the kind of scrolling for each surface and can be: "none" (no scrolling enabled), "visual" (only scroll the texture), "physical" (only carry the things), "both" (both scroll and carry). For now, '''scroll_ceil_type''' only supports "none" or "visual".
*'''floorid''', '''ceilingid'''
:ID of the floor or ceiling of this sector to use for [[attached surfaces]]. Use this id in '''attachfloor''' and '''attachceiling'''.
*'''attachfloor''', '''attachceiling'''
:Makes the floor or ceiling of this sector move whenever sectors with '''floorid''' or '''ceilingid''' with the same number move their respective surfaces. If you want this sector's floor or ceiling to move in opposite direction, use the negative value.
*'''soundsequence'''
:Name of the [[soundsequence]] to use for the movement of this sector. It will only work if said soundsequence has an '''id'''. It can also be a number (the sound sequence '''id''') surrounded by quotes.
*'''portalfloor''', '''portalceiling'''
:Portal ID to use on the floor or ceiling of this sector, using the same value as the one set in [[Portal_Define]]. For two-way portals, use the negative number for the opposite portal (i.e. one way uses portal ''n'', and the other way uses -''n'').
*'''portal_floor_disabled''', '''portal_ceil_disabled'''
:If true, the portal is disabled (has no effect).
*'''portal_floor_norender''', '''portal_ceil_norended'''
:If true, the portal is not rendered but may have effects.
*'''portal_floor_nopass''', '''portal_ceil_nopass'''
:If true, it disables any linked portals interaction.
*'''portal_floor_blocksound''', '''portal_ceil_blocksound'''
:If true, it blocks sounds from monsters listening for alerts.
*'''portal_floor_useglobaltex''', '''portal_ceil_useglobaltex'''
:Reserved.
*'''portal_floor_overlaytype''', '''portal_ceil_overlaytype''' (default: "none")
:Can be "none", "translucent" or "additive". Controls the rendering of portal overlays.
*'''alphafloor''', '''alphaceiling''' (default: 1.0)
:Alpha of the portal overlay. 1.0 makes it fully visible, 0.0 is invisible.
*'''portal_floor_attached''', '''portal_ceil_attached'''
:If true, and the sector has a linked portal on the floor or ceiling, the portal will move along with the floor or ceiling surface, instead of remaining at the same height as default. This is useful for easily moving platforms vertically.

==Things==
thing
{
health = <floating-point>;
}
===Explanation of fields===
*'''health'''
:Health modifier. Works like in ZDoom: 0 means no change from [[EDF]], positive values multiply the initial spawn health, and negative values change the absolute spawn health.

UDMF

2026-06-14T13:48:16Z

Printz: /* Sidedefs */

UDMF is the extensible format that replaces the classic Doom format and [[ExtraData]]. Each level, instead of being defined by the classic lumps (THINGS, LINEDEFS, SIDEDEFS etc.) is defined by a human-readable lump named TEXTMAP, and can have associated lumps (e.g. ZNODES, BLOCKMAP, REJECT if needed) and other lumps, until a marker lump named ENDMAP.

TEXTMAP has a well-defined language. Check the UDMF article at doomwiki.org. Each game and port has its own namespace(s), for example we have these namespaces: "doom", "heretic", "hexen", "strife", "zdoom" and others. Eternity has the "eternity" namespace.

At its core, UDMF is made of many blocks, each titled "vertex", "sector", "sidedef", "linedef", "thing" and containing several properties, some mandatory, others optional. Each game or port namespace can define its own set, which is typically hard-coded, though it's also possible for the user to add their own fields (which have to be preceded by a safe prefix, to avoid conflicts with the standard).

Maps designed in UDMF no longer need ExtraData.

The standard was defined by James "Quasar" Haley and has also been successfully implemented in Vavoom, ZDoom and the ZDoom-derivative ports.

* See also the [https://www.doomworld.com/eternity/engine/stuff/udmf11.txt base UDMF specifications]

==Basics==

Eternity supports the "doom" and "eternity" namespaces. In the rest of this article, we'll detail the "eternity" namespace. See the [https://www.doomworld.com/eternity/engine/stuff/udmf11.txt base UDMF specifications] for the options not detailed in this document.

A TEXTMAP for Eternity must start with this:
namespace = "eternity";

===Eternity compatibility===
You can also add the following field in UDMF TEXTMAP:
ee_compat = true;
which, no matter the namespace used (e.g. "zdoom"), assumes the map is going to work in Eternity. In other words, it is equivalent to setting namespace as "eternity". Any fields not supported by Eternity, however, may make the mod fail.

===Node format===

Nodes for UDMF use the uncompressed GL-nodes format under the ZNODES name. Tools such as ZDBSP should build such a lump upon detecting a TEXTMAP lump.

==Linedefs==
linedef
{
blocklandmonsters = <boolean>;
blockplayers = <boolean>;

polycross = <boolean>;
monstershoot = <boolean>;

midtex3d = <boolean>;
firstsideonly = <boolean>;
blockeverything = <boolean>;
zoneboundary = <boolean>;
clipmidtex = <boolean>;
midtex3dimpassible = <boolean>;
lowerportal = <boolean>;
upperportal = <boolean>;

portal = <integer>;

alpha = <floating-point>; // default 1.0
renderstyle = <string>;
tranmap = <string>;
}
===Explanation of fields===
*'''blocklandmonsters'''
:If true, linedef blocks walking monsters but allows fliers to pass. Players can pass anyway.
*'''blockplayers'''
:If true, linedef blocks players but allows monsters and projectiles to pass.
*'''polycross'''
:If true, linedef is activated when a polyobject's center point crosses it.
*'''monstershoot'''
:If true, linedef is activated when a monster fires hitscan on it.
*'''midtex3d'''
:If true, this linedef's middle texture uses [[3DMidTex_tutorial|3dmidtex]] physics.
*'''firstsideonly'''
:Linedef can only be activated from front side.
*'''blockeverything'''
:Linedef blocks all objects, acting like an external solid wall
*'''zoneboundary'''
:Linedef acts like a boundary for [[EDF_sound_reference#Sound_environments|reverb]] effects.
*'''clipmidtex'''
:Middle texture is clipped against the floor or ceiling as if a light change took place.
*'''midtex3dimpassible'''
:Treat the 3dmidtex line as a classic impassable middle texture, with regards to projectiles (i.e. they will pass through, just like hitscans).
*'''lowerportal''', '''upperportal'''
:Apply [[edge portals|edge portal]] on the lower or upper part of this linedef, copying back sector's floor or ceiling portal into it.
*'''portal'''
:The ID of the portal to apply on this linedef, as defined from [[Portal_Define]]
*'''alpha''' (default: 1.0)
:Opacity of this line.
*'''renderstyle'''
:Either "translucent" or "add". Default is "".
*'''tranmap'''
:Boom [[translucency map]]. Mutually exclusive with alpha and renderstyle.

==Sidedefs==
sidedef
{
offsetx = <floating-point>;
offsety = <floating-point>;
offsetx_top = <floating-point>;
offsety_top = <floating-point>;
offsetx_mid = <floating-point>;
offsety_mid = <floating-point>;
offsetx_bottom = <floating-point>;
offsety_bottom = <floating-point>;

scalex_top = <floating-point>;
scaley_top = <floating-point>;
scalex_mid = <floating-point>;
scaley_mid = <floating-point>;
scalex_bottom = <floating-point>;
scaley_bottom = <floating-point>;

light = <integer>;
lightabsolute = <boolean>;
light_top = <integer>;
lightabsolute_top = <boolean>;
light_mid = <integer>;
lightabsolute_mid = <boolean>;
light_bottom = <integer>;
lightabsolute_bottom = <boolean>;

skew_top_type = <string>;
skew_middle_type = <string>;
skew_bottom_type = <string>;
}

===Explanation of fields===
*'''offsetx''', '''offsety'''
:Overall horizontal and vertical offsets for the top, middle, and bottom textures of this sidedef.
*'''offsetx_top''', '''offsety_top''', '''offsetx_mid''', '''offsety_mid''', '''offsetx_bottom''', '''offsety_bottom'''
:Horizontal and vertical offsets for the individual top, middle, and bottom portions of this sidedef.
*'''scalex_top''', '''scaley_top''', '''scalex_mid''', '''scaley_mid''', '''scalex_bottom''', '''scaley_bottom'''
:Horizontal and vertical scaling of parts of the sidedef.
*'''light''', '''light_top''', '''light_mid''', '''light_bottom''', '''lightabsolute''', '''lightabsolute_top''', '''lightabsolute_mid''', '''lightabsolute_bottom'''
:Brightness for the whole, and the individual top, middle, and bottom portions of this sidedef. By default the values are additive to the inherited brightness. If the "absolute" properties are set to "true" the values are not additive anymore, but absolute.
*'''skew_top_type''', '''skew_bottom_type''', '''skew_middle_type'''
:The type of skewing that the a given texture of this sidedef has. This skew starts at the left side of the sidedef (if viewing the sidedef straight-on) and conforms to either the slope on the front or back side of the line the sidedef is on. Either the floor or ceiling slope can be picked as the slope for the skewing to conform to. Values are "none", "front_floor", "front_ceiling", "back_floor", and "back_ceiling", with "none" being the default.

==Vertices==
No change yet from the base "doom" namespace.
==Sectors==
sector
{
heightfloor = <floating-point>;
heightceiling = <floating-point>;

xpanningfloor = <floating-point>;
ypanningfloor = <floating-point>;
xpanningceiling = <floating-point>;
ypanningceiling = <floating-point>;

xscalefloor = <floating-point>;
yscalefloor = <floating-point>;
xscaleceiling = <floating-point>;
yscaleceiling = <floating-point>;
rotationfloor = <floating-point>;
rotationceiling = <floating-point>;

secret = <boolean>;
friction = <integer>;

leakiness = <integer>;
damageamount = <integer>;
damageinterval = <integer>;
damage_endgodmode = <boolean>;
damage_exitlevel = <boolean>;
damageterraineffect = <boolean>;
damagetype = <string>;

floorterrain = <string>;
ceilingterrain = <string>;

lightfloor = <integer>;
lightceiling = <integer>;
lightfloorabsolute = <boolean>;
lightceilingabsolute = <boolean>;

phasedlight = <boolean>;
lightsequence = <boolean>;
lightseqalt = <boolean>;

colormaptop = <string>;
colormapmid = <string>;
colormapbottom = <string>;

scroll_ceil_x = <floating-point>;
scroll_ceil_y = <floating-point>;
scroll_ceil_type = <string>;
scroll_floor_x = <floating-point>;
scroll_floor_y = <floating-point>;
scroll_floor_type = <string>;

floorid = <integer>;
ceilingid = <integer>;
attachfloor = <integer>;
attachceiling = <integer>;

soundsequence = <string>;

portalfloor = <integer>;
portalceiling = <integer>;

portal_floor_disabled = <boolean>;
portal_floor_norender = <boolean>;
portal_floor_nopass = <boolean>;
portal_floor_blocksound = <boolean>;
portal_floor_useglobaltex = <boolean>;
portal_floor_overlaytype = <string>;
alphafloor = <floating-point>;
portal_floor_attached = <boolean>;

portal_ceil_disabled = <boolean>;
portal_ceil_norender = <boolean>;
portal_ceil_nopass = <boolean>;
portal_ceil_blocksound = <boolean>;
portal_ceil_useglobaltex = <boolean>;
portal_ceil_overlaytype = <string>;
alphaceiling = <floating-point>;
portal_ceil_attached = <boolean>;
}

=== Explanation of fields ===
*'''heightfloor''', '''heightceiling''' (mandatory)
:Unlike the base field from the core specs, these ones allow floating-point values.
*'''xpanningfloor''', '''ypanningfloor''', '''xpanningceiling''', '''ypanningceiling'''
:These properties control the panning of the floor or ceiling flat.
*'''xscalefloor''', '''yscalefloor''', '''xscaleceiling''', '''yscaleceiling''' (default: 1.0)
:These properties control the scaling of the floor or ceiling flat. Greater values result in smaller textures.
*'''rotationfloor''', '''rotationceiling'''
:These properties control the clockwise rotation of the floor or ceiling flat, in degrees.
*'''secret'''
:If true, the sector counts as a secret when visited by player.
*'''friction''' (default: -1)
:This one controls the friction of movement on the floor. The value of this field is equivalent to the length of a horizontal linedef with the classic Boom friction special. Default value: -1 (use usual Doom friction).
*'''leakiness'''
:This one controls the probability that, if this sector is also damaging, it will leak damage through the radiation suit. As reference, the classic Doom 20% sector has 5 leakiness. For damage which always goes through the suit, use 256.
*'''damageamount'''
:Damage per hit for players on the floor.
*'''damageinterval'''
:Time between hits. The classic Doom damaging floors use a 32 period.
*'''damage_endgodmode'''
:If true, it will cause the damaging floor to disable the godmode cheat.
*'''damage_exitlevel'''
:If true, it will cause the damaging floor to exit the level in victory if the player has too little health.
*'''damageterraineffect'''
:If true, then each damage hit will produce a splash, like the Heretic lava.
*'''damagetype''' (default: "Unknown")
:The [[damagetype|damage type]] of the floor. For Doom damaging floors you can use "Slime".
*'''floorterrain''' (default: "@flat")
:The [[terrain]] effect of the floor.
*'''ceilingterrain''' (default: "@flat")
:The [[terrain]] effect of the ceiling. Currently used for particle recolouring.
*'''lightfloor''', '''lightceiling'''
:The light amount to add to the floor or ceiling, relative to the designated light level.
*'''lightfloorabsolute''', '''lightceilingabsolute'''
:If true, then '''lightfloor''' or '''lightceiling''' just overrides the light.
* phasedlight = <boolean>;
:Equivalent to ExtraData flag.
* lightsequence = <boolean>;
:Equivalent to ExtraData flag.
* lightseqalt = <boolean>;
:Equivalent to ExtraData flag.
*'''colormaptop''', '''colormapmid''', '''colormapbottom''' (default: "@default")
:The colormap to set for the top, normal or bottom part of a Boom sector with fake flats. Or for any normal part, if it's '''colormapmid'''. Use a lump from between '''C_START''' and '''C_END'''. "WATERMAP" and "LAVAMAP" are provided by Eternity.
*'''scroll_ceil_x''', '''scroll_ceil_y''', '''scroll_floor_x''', '''scroll_floor_y'''
:These fields make the sector ceiling or floor scroll at startup. The values you input there are the equivalents of a Boom trigger linedef length divided by 10. So to emulate a linedef pointing east of length 64 having a scroll trigger, set value 6.4 on '''scroll_ceil_x''' or '''scroll_floor_x'''.
*'''scroll_ceil_type''', '''scroll_floor_type''' (default: "none")
:These fields control the kind of scrolling for each surface and can be: "none" (no scrolling enabled), "visual" (only scroll the texture), "physical" (only carry the things), "both" (both scroll and carry). For now, '''scroll_ceil_type''' only supports "none" or "visual".
*'''floorid''', '''ceilingid'''
:ID of the floor or ceiling of this sector to use for [[attached surfaces]]. Use this id in '''attachfloor''' and '''attachceiling'''.
*'''attachfloor''', '''attachceiling'''
:Makes the floor or ceiling of this sector move whenever sectors with '''floorid''' or '''ceilingid''' with the same number move their respective surfaces. If you want this sector's floor or ceiling to move in opposite direction, use the negative value.
*'''soundsequence'''
:Name of the [[soundsequence]] to use for the movement of this sector. It will only work if said soundsequence has an '''id'''. It can also be a number (the sound sequence '''id''') surrounded by quotes.
*'''portalfloor''', '''portalceiling'''
:Portal ID to use on the floor or ceiling of this sector, using the same value as the one set in [[Portal_Define]]. For two-way portals, use the negative number for the opposite portal (i.e. one way uses portal ''n'', and the other way uses -''n'').
*'''portal_floor_disabled''', '''portal_ceil_disabled'''
:If true, the portal is disabled (has no effect).
*'''portal_floor_norender''', '''portal_ceil_norended'''
:If true, the portal is not rendered but may have effects.
*'''portal_floor_nopass''', '''portal_ceil_nopass'''
:If true, it disables any linked portals interaction.
*'''portal_floor_blocksound''', '''portal_ceil_blocksound'''
:If true, it blocks sounds from monsters listening for alerts.
*'''portal_floor_useglobaltex''', '''portal_ceil_useglobaltex'''
:Reserved.
*'''portal_floor_overlaytype''', '''portal_ceil_overlaytype''' (default: "none")
:Can be "none", "translucent" or "additive". Controls the rendering of portal overlays.
*'''alphafloor''', '''alphaceiling''' (default: 1.0)
:Alpha of the portal overlay. 1.0 makes it fully visible, 0.0 is invisible.
*'''portal_floor_attached''', '''portal_ceil_attached'''
:If true, and the sector has a linked portal on the floor or ceiling, the portal will move along with the floor or ceiling surface, instead of remaining at the same height as default. This is useful for easily moving platforms vertically.

==Things==
thing
{
health = <floating-point>;
}
===Explanation of fields===
*'''health'''
:Health modifier. Works like in ZDoom: 0 means no change from [[EDF]], positive values multiply the initial spawn health, and negative values change the absolute spawn health.

OPTIONS

2026-06-14T13:44:51Z

Printz: /* OPTIONS full listing */

New to MBF, the OPTIONS lump allows wads to set game options, such as Doom Compatibility options, chat strings, and enemies options.

The OPTIONS lump has the same format as eternity.cfg: A text file listing option names and values, optionally separated by blank or comment lines. Eternity.cfg indicates options which are allowed to be set in wads, with asterisks (*).

Wad authors are urged to use these options responsibly, because they should not be used to limit players, but to enhance the game. Many options such as automap colors are allowed to be set from wads, but they should only be done so if there are strong reasons to do so. More recommended to enforce are the compatibility (comp_) settings, because certain map effects (such as moving floor combinations) may depend on them to work properly. [[Linked portals]] for example require the setting "comp_overunder 0" in order to work (and in fact enforce it as such, even if set otherwise by user), and in addition, due to Doom's default definition of solid static decorations, it is recommended to also set "comp_theights 0" (which itself is not enforced by portals).

If a wad with OPTIONS lump is loaded, it will not overwrite the user configuration file.
{{backto|Eternity Engine}}
{{mbfref}}
==Options settable using the lump==
The Eternity.cfg file provides user-friendly explanation on each flag and if it's allowed to be set in wads. At the end of this document there is an excerpt from the default Eternity.cfg, with only the wad-settable options. Note that the lines beginning with semicolons or brackets are treated as comments and do nothing.

===Common options which are set in other lumps===

There may be other options you may be looking for, which for now aren't set here, but in other wad lumps:
*To disable jumping, set '''disable-jump''' in [[EMAPINFO]] for each needed level.
*See also [[EDF game properties]], which are for customizing global game-specific options.

==OPTIONS full listing==
[0-1(0)] 1 to enable variable pitch in sound effects (from id's original code) *
pitched_sounds 0

[0-1(1)] 1 to enable translucency for some things *
translucency 1

[0-100(66)] set percentage of foreground/background translucency mix *
tran_filter_pct 66

[0-1(0)] 1 to enable recoil from weapon fire *
weapon_recoil 0

[0-1(0)] 0 - don't center weapon when firing, 1 - center weapon when firing
r_centerfire 0

[0-4(0)] 0 - normal, 1 - classic, 2 - 11k, 3 - bouncing!, 4 - burst *
bfgtype 0

[0-3(0)] 0 - none, 1 - cross, 2 - angle *
crosshair 0

[0-1(0)] 0 - no highlighting, 1 - aim highlighting enabled *
crosshair_hilite 0

[0-1(1)] 0 - scale crosshair, 1 - draw crosshair unscaled *
crosshair_scale 1

[0-1(0)] show scores in deathmatch *
show_scores 0

[0-1(0)] 0 - right handed, 1 - left handed *
lefthanded 0

[0-1(0)] 1 to keep switching weapon while holding hotkey
weapon_hotkey_holding 0

[0-1(1)] 1 to enable player bobbing (view moving up/down slightly) *
player_bobbing 1

[0-1(0)] 1 to enable monsters remembering enemies after killing others *
monsters_remember 0

[0-1(1)] 1 to enable monsters fighting against each other when provoked *
monster_infighting 1

[0-1(0)] 1 to enable monsters backing away from targets *
monster_backing 0

[0-1(0)] 1 to enable monsters to intelligently avoid hazards *
monster_avoid_hazards 0

[0-1(0)] 1 to enable monsters to move up/down steep stairs *
monkeys 0

[0-1(1)] 1 to enable monsters to be affected by friction *
monster_friction 1

[0-1(1)] 1 to enable monsters to help dying friends *
help_friends 1

[0-3(0)] number of single-player helpers *
player_helpers 0

[0-999(128)] distance friends stay away *
friend_distance 128

[0-1(1)] 1 to enable dogs to jump *
dog_jumping 1

[0-1(1)] 1 to enable monster roaring when last enemy is remembered *
p_lastenemyroar 1

[0-1(1)] 1 to enable flying in the direction you are looking *
p_pitchedflight 1

[0-1(1)] 1 to disable use of color on status bar *
sts_always_red 1

[0-1(0)] 1 to make percent signs on status bar always gray *
sts_pct_always_gray 0

[0-1(0)] 1 to disable doubled card and skull key display on status bar *
sts_traditional_keys 0

[0-1(1)] Zombie players can exit levels *
comp_zombie 1

[0-1(1)] Powerup cheats are not infinite duration *
comp_infcheat 1

[0-1(1)] Build stairs exactly the same way that Doom does *
comp_stairs 1

[0-1(0)] Monsters can telefrag on MAP30 *
comp_telefrag 0

[0-1(0)] Some objects never move over tall ledges *
comp_dropoff 0

[0-1(0)] Objects don't fall off ledges under their own weight *
comp_falloff 0

[0-1(0)] Monsters randomly walk off of moving lifts *
comp_staylift 0

[0-1(0)] Monsters get stuck on doortracks *
comp_doorstuck 0

[0-1(0)] Monsters don't give up pursuit of targets *
comp_pursuit 0

[0-1(1)] Arch-Vile resurrects invincible ghosts *
comp_vile 1

[0-1(0)] Pain Elemental limited to 20 lost souls *
comp_pain 0

[0-1(1)] Lost souls get stuck behind walls *
comp_skull 1

[0-1(0)] Blazing doors make double closing sounds *
comp_blazing 0

[0-1(0)] Tagged doors don't trigger special lighting *
comp_doorlight 0

[0-1(1)] God mode isn't absolute *
comp_god 1

[0-1(1)] Sky is unaffected by invulnerability *
comp_skymap 1

[0-1(0)] Use exactly Doom's floor motion behavior *
comp_floors 0

[0-1(0)] Use exactly Doom's linedef trigger model *
comp_model 0

[0-1(0)] Linedef effects work with sector tag = 0 *
comp_zerotags 0

[0-1(1)] Terrain effects not activated on floor contact *
comp_terrain 1

[0-1(0)] Creatures with no spawnpoint respawn at (0,0) *
comp_respawnfix 0

[0-1(1)] Players do not take falling damage *
comp_fallingdmg 1

[0-1(0)] Lost souls do not bounce on floors *
comp_soul 0

[0-1(0)] Things not fully clipped with respect to z coord *
comp_overunder 0

[0-1(0)] DOOM thingtypes use inaccurate height information *
comp_theights 0

[0-1(0)] Tracer shots cannot hit the floor or ceiling *
comp_planeshoot 0

[0-1(0)] One-time line specials are cleared on failure *
comp_special 0

[0-1(0)] Silent spawns at W/SW/S-facing DM spots *
comp_ninja 0

[0-1(1)] Disable jumping for DOOM/Heretic *
comp_aircontrol 1

[0-1(0)] MObjs are lit by transfered light *
comp_thingsectorlight 0

[("No")] chat string associated with 0 key *
chatmacro0 "No"

[("I'm ready to kick butt!")] chat string associated with 1 key *
chatmacro1 "I'm ready to kick butt!"

[("I'm OK.")] chat string associated with 2 key *
chatmacro2 "I'm OK."

[("I'm not looking too good!")] chat string associated with 3 key *
chatmacro3 "I'm not looking too good!"

[("Help!")] chat string associated with 4 key *
chatmacro4 "Help!"

[("You suck!")] chat string associated with 5 key *
chatmacro5 "You suck!"

[("Next time, scumbag...")] chat string associated with 6 key *
chatmacro6 "Next time, scumbag..."

[("Come here!")] chat string associated with 7 key *
chatmacro7 "Come here!"

[("I'll take care of it.")] chat string associated with 8 key *
chatmacro8 "I'll take care of it."

[("Yes")] chat string associated with 9 key *
chatmacro9 "Yes"

[0-255(247)] color used as background for automap *
mapcolor_back 247

[0-255(104)] color used for automap grid lines *
mapcolor_grid 104

[0-255(181)] color used for one side walls on automap *
mapcolor_wall 181

[0-255(166)] color used for lines floor height changes across *
mapcolor_fchg 166

[0-255(231)] color used for lines ceiling height changes across *
mapcolor_cchg 231

[0-255(231)] color used for lines denoting closed doors, objects *
mapcolor_clsd 231

[0-255(175)] color used for red key sprites *
mapcolor_rkey 175

[0-255(204)] color used for blue key sprites *
mapcolor_bkey 204

[0-255(231)] color used for yellow key sprites *
mapcolor_ykey 231

[0-255(175)] color used for closed red doors *
mapcolor_rdor 175

[0-255(204)] color used for closed blue doors *
mapcolor_bdor 204

[0-255(231)] color used for closed yellow doors *
mapcolor_ydor 231

[0-255(119)] color used for teleporter lines *
mapcolor_tele 119

[0-255(176)] color used for lines around secret sectors *
mapcolor_secr 176

[0-255(0)] color used for exit lines *
mapcolor_exit 0

[0-255(96)] color used for lines not seen without computer map *
mapcolor_unsn 96

[0-255(88)] color used for lines with no height changes *
mapcolor_flat 88

[0-255(112)] color used as things *
mapcolor_sprt 112

[0-255(208)] color used for dot crosshair denoting center of map *
mapcolor_hair 208

[0-255(208)] color used for the single player arrow *
mapcolor_sngl 208

[0-255(112)] color used for the green player arrow *
mapcolor_ply1 112

[0-255(88)] color used for the gray player arrow *
mapcolor_ply2 88

[0-255(64)] color used for the brown player arrow *
mapcolor_ply3 64

[0-255(176)] color used for the red player arrow *
mapcolor_ply4 176

[0-255(252)] color used for friends *
mapcolor_frnd 252

[0-255(109)] color for lines not in the player's portal area *
mapcolor_prtl 109

[0-1(1)] 1 to overlay different linked portal areas in the automap *
mapportal_overlay 1

[0-1(1)] 1 to show automap pointer coordinates in non-follow mode *
map_point_coord 1

[0-1(1)] 1 to not show secret sectors till after entered *
map_secret_after 1

[0-1(1)] enable secret notification *
secret_notification 1

[1-16(1)] number of lines in review display *
hud_msg_lines 1

[0-1(1)] 1 enables message review list scrolling upward *
hud_msg_scrollup 1

[0-4(2)] fullscreen hud layout *
hud_overlaylayout 2

[0-1(1)] fullscreen hud enabled *
hud_enabled 1

[0-1(0)] hide kills/items/secrets info on fullscreen hud *
hud_hidestatus 0

[0-1(1)] display current level time on automap *
hu_showtime 1

[0-1(1)] display player/pointer coordinates on automap *
hu_showcoords 1

[0-9(6)] color of automap level time widget *
hu_timecolor 6

[0-9(6)] color of automap level name widget *
hu_levelnamecolor 6

[0-9(6)] color of automap coordinates widget *
hu_coordscolor 6

[0-200(25)] amount of health for red to yellow transition *
health_red 25

[0-200(50)] amount of health for yellow to green transition *
health_yellow 50

[0-200(100)] amount of health for green to blue transition *
health_green 100

[0-200(25)] amount of armor for red to yellow transition *
armor_red 25

[0-200(50)] amount of armor for yellow to green transition *
armor_yellow 50

[0-200(100)] amount of armor for green to blue transition *
armor_green 100

[0-1(1)] reflect armor class using blue or green color *
armor_byclass 1

[0-100(25)] percent of ammo for red to yellow transition *
ammo_red 25

[0-100(50)] percent of ammo for yellow to green transition *
ammo_yellow 50

[0-100(100)] fullscreen HUD translucency level *
st_fsalpha 100

[0-1(0)] obituaries on/off *
obituaries 0

[0-1(0)] toggle particle effects on or off *
draw_particles 0

[0-2(1)] particle translucency (0 = none, 1 = smooth, 2 = general) *
particle_trans 1

[0-2(0)] use sprites, particles, or both for blood (sprites = 0) *
blood_particles 0

[0-2(0)] use sprites, particles, or both for bullet puffs (sprites = 0) *
bullet_particles 0

[0-1(0)] draw particle rocket trails *
rocket_trails 0

[0-1(0)] draw particle grenade trails *
grenade_trails 0

[0-1(0)] draw particle bfg cloud *
bfg_cloud 0

[0-1(0)] draw particle rocket explosions *
pevent_rexpl 0

[0-1(0)] draw particle bfg explosions *
pevent_bfgexpl 0

[0-1(1)] 1 to show ENDOOM at exit *
showendoom 1

[0-1(1)] 1 to enable autoaiming *
autoaim 1

[0-1(0)] 1 to allow players to look up/down *
allowmlook 0

[0-1(0)] 1 to enable use of full classic menu emulation *
mn_classic_menus 0

[("default")] menu background *
mn_background "default"

[0-2(1)] Doom object translucency style (0 = none, 1 = Boom, 2 = new) *
r_tlstyle 1

[0-2(1)] 0 = none, 1 = melt, 2 = fade *
wipetype 1

[1-6(1)] preamp volume factor for SPC music *
snd_spcpreamp 1

[1-31(8)] bass boost for SPC music (logarithmic scale, 8 = normal) *
snd_spcbassboost 8

[-1-0(-1)] device used for MIDI playback *
snd_mididevice -1

[1-8(2)] TODO: adlmidi_numcards description *
snd_numchips 2

[0-75(72)] TODO: adlmidi_bank description *
snd_bank 72

List of cheat codes

2026-06-14T13:42:33Z

Printz: /* Eternity Cheats */

The Eternity Engine supports several cheat codes besides what vanilla Doom has. The list follows.
{{Backto|Eternity Engine}}
{{editref}}
==Classic Doom cheats==
These cheats are available in Doom and Doom 2, and function mostly if not identically the same.
===IDMUS===
IDMUS allows the music to be changed to any other internally defined music. Type IDMUS and then the level number to hear the song that plays on that map (in DOOM and Heretic, use the episode and then map; in DOOM II, use the 2-digit map number). Typing numbers beyond the number of levels in the game will allow you to hear other songs such as intermission, title, and ending music. This cheat won't crash on bad numbers like DOOM originally could.
===IDCHOPPERS===
IDCHOPPERS gives you the chainsaw. It is named after a game entered in a state programming contest, and the message it gives is related to it.
===IDDQD===
IDDQD sets the player's health to 100 and toggles god mode. DQD stands for Delta-Q-Delta, a supposed fraternity for programmers where the requirement for entry was at least one Q (a mark given in college for a class withdrawal) on your transcript.
===IDK, IDKFA, IDFA===
These cheats give the following:
*IDK: All six DOOM keys
*IDKFA: All six keys, full ammo and weapons, and armor
*IDFA: Full ammo, weapons, and armor, but no keys
IDK is new as of the BOOM engine. According to the Linux DOOM source, KFA either stands for killer fraggin' arsenal (although a less kosher word is used for fraggin'), or Keys and Full Ammo. You can take your pick.
===IDCLIP, IDSPISPOPD===
These two cheats have identical functionality, which is turning off the game's clipping code for the player. This allows you to walk through walls and solid things, and even completely out of the map. SPISPOPD stands for "Smashing Pumpkins Into Small Piles Of Putrid Debris," and has its origins in the pre-DOOM-release Usenet mayhem.
===IDBEHOLD===
Typing IDBEHOLD will bring up a small menu where you can choose to enable one of various powerup effects. To choose a powerup, use the following keys:
*R: Toggles radiation suit
*I: Toggles partial invisibility
*V: Toggles invulnerability (with inverse colormap)
*A: Toggles all-map cheat (reveals the automap)
*L: Toggles lite-amp goggles
*S: Toggles berserk strength
In DOOM, some of these effects would wear off after the normal amount of time. By default, Eternity allows them to stay on forever until you explicitly turn them off by typing the cheat again.
===IDCLEV===
This cheat allows you to change levels. In DOOM or Heretic, type the episode number and then the map number after the cheat. In DOOM II, type the two-digit level number. You can only warp to levels which are normally in the game, even if other map numbers are available in the wad (to warp to oddly-named or higher-numbered levels, use Eternity's map console command).
===IDMYPOS===
This cheat prints detailed information about your current location. The format of its output has been improved over that which was used in DOOM; however, this cheat's function is mostly obsoleted by the automap coordinates widget.
===IDDT===
To activate this cheat, go to the automap and type IDDT. Doing this once will allow you to see all lines in the map. Doing it again will allow you to also see all things in the map. Type it a third time to return the automap to normal. You can see some areas of the map with IDDT that you cannot see with the all-map powerup.
==Classic Heretic cheats==
These cheats are available in Heretic,.
===QUICKEN===
Toggles god mode (invulnerability).
===PONCE===
Restores health (to the initial player class health).
===IDDQD===
Fake bait cheat, actually kills the player.
===SKEL===
Gives all keys.
===MASSACRE===
Kills all monsters.
===KITTY===
Toggles no-clipping mode (walking through walls).
===ENGAGE===
Followed by the episode and level number, changes the current level. All equipment is reset to wand start.
===RAVMAP===
Usable in automap mode, toggles between normal display, displaying the entire map and also displaying things.
===RAVPOWER===
Followed by any of the following initials, gives or takes player one of the following powers:
*v: invulnerability
*g: shadowsphere
*a: map scroll
*t: torch
*f: wings of wrath
*r: damaging floor protection (no such powerup in Heretic)
===GIMME===
Followed by any of the following letters, then by amount, it gives the player an inventory item of the following type:
*a: ring of invulnerability
*b: shadowsphere
*c: quartz flask
*d: mystic urn
*e: tome of power
*f: torch
*g: time bomb of the ancients
*h: morph ovum
*i: wings of wrath
*j: chaos device
===RAMBO===
Gives all weapons, bag of holding and armour.
===COCKADOODLEDOO===
Toggles player morphing into a chicken.
==BOOM and MBF Cheats==
These cheats were added in BOOM and MBF. Some of them have been changed slightly (in BOOM, many of them had a TNT prefix, which was removed in MBF).
===COMP===
This cheat toggles all of the compatibility vector variables at once, turning them on or off.
===KILLEM===
This cheat kills all monsters on the map, keeping count (it counts monsters which do not normally count for kills, such as Lost Souls, so the number may be higher than the kill count for the map). If there are no enemy monsters on the map and you type this, it will kill all friends on the map (not including the player, of course).

Same as the "nuke" console command.
===HOM===
This cheat toggles the BOOM HOM detection feature. Depending on your settings, HOM will appear either as solid red or as a red flashing area when this cheat is enabled.

Same as the "r_showhom /" console command.
===KEY===
Type KEY to bring up a menu, then type R, Y, or B to choose a key color (red, yellow, or blue). Then, type C or S to select card or skull. Once you make the final selection, the key will either be given to you if you don't have it, or it will be taken away. This lets you select the key you need (especially useful in maps with missing keys).
===WEAP===
Type WEAP, then type a number (1-9 in DOOM II, 1-8 in DOOM). The selected weapon which is associated with that slot will either be added or removed, depending on whether you have it or not (note the Super Shotgun is weapon #9 in DOOM II). You can remove the fist, chainsaw, and pistol with this code, but cannot get them back unless you type it again.
===AMMO===
Type AMMO, then either type a number from 1 to 4, or B for Backpack. The selected ammo will be added or taken away (yes, you can remove the backpack if you already have it). Ammo types are bullets, shells, rockets, and cells.
===TRAN===
This code toggles translucency rendering effects (both BOOM-style and DosDOOM-style). Sometimes turning this off can help the framerate a bit, especially on really old machines.
===ICE===
Type this cheat to toggle BOOM friction effects.
===PUSH===
Type this cheat to toggle BOOM pusher effects.

Same as the "pushers /" console command.
===NUKE===
Type this cheat to toggle the effects of damaging sectors.

==Eternity Cheats==
These cheat codes are new to Eternity.
===HIDEME ===

This cheat toggles the new total invisibility powerup effect. When totally invisible, enemies will not awaken by seeing you. Deaf enemies cannot awaken at all, since they can neither see nor hear you. However, if a normal enemy hears you, this cheat will only become as good as partial invisibility, as the demons have a sense for where you are even when you are invisible.

===GHOST===

This cheat toggles the Heretic shadowsphere effect. You will become translucent, and if you move slowly and keep at a distance, enemies may fail to see you. They also cannot aim at you well even when they do see you, just as with partial and total invisibility.

Same as the "r_trans /" console command.

===INFSHOTS ===

This cheat toggles infinite ammo. When turned on, none of your weapons will use any ammo whatsoever.

===SILENCE ===

This cheat toggles the new silencer powerup effect. When active, your weapons' sounds will not cause enemies to awaken. When combined with HIDEME, enemies will never wake up unless you hurt them.

===IAMTHEONE ===

This is a master cheat which will make you all-powerful. It will turn on god mode, infinite ammo, total invisibility, and silencer effects if they are not on (it will not deactivate them if you type it again). It also gives full ammo, weapons, and armor.

===IDDKT, IDDIT, IDDST===
These cheat codes work when automap is active, and move the cursor to the next remaining monster, item or secret which counts for the final score.

==See also==
* [[List of console commands]]

BFGSpray

2026-06-14T13:38:41Z

Printz:

{{codepointer|description=BFGSpray is a codepointer which causes a BFG explosion effect.|usage='''BFGSpray'''(''sprayType'', ''numRays'', ''damageCount'', ''fov'', ''maxDist'', ''damageMOD'')
|parameters=
*''sprayType'': name of thing type to spawn on hit targets. Default is the thingtype with dehackednum 43, which in Doom is BFGFlash.
*''numRays'': number of rays. Default: 40.
*''damageCount'': how many times to add the random 1-8 damage for each ray. Default: 15.
*''fov'': angle in degrees of the spread. Default: 90.
*''maxDist'': range of each ray. Default: 1024.
*''damageMOD'': means-of-death (damage type). Default: BFG_Splash.
|notes=
The effect differs depending on the player's selected type of BFG:

*Normal BFG: ''numRays'' tracers will emanate from the object which fired the projectile in the general direction in which the projectile was fired, each doing damage that is the sum of ''damageCount'' rolls of an 8-sided die.
*BFG11K: Control is transferred to the [[BFG11KHit]] codepointer.
*Bouncing BFG: Control is transferred to the [[BouncingBFG]] codepointer.
*Plasma Burst BFG: Control is transferred to the [[BFGBurst]] codepointer.

Note: this will not trigger the Doom beta BFG attack if its gameplay setting is enabled. There is a separate set of frames for the classic BFG that replace the normal BFG9000.|seealso=
*[[BFG11KHit]]
*[[BFGBurst]]
*[[BouncingBFG]]|examples=
{{example|description=From base\doom\frames.edf:|code=<nowiki>frame S_BFGLAND3 { cmp = "BFE1|2|T|8|BFGSpray|@next"; dehackednum = 119 }</nowiki>}}}}

VileAttack

2026-06-14T13:37:30Z

Printz:

Type: Monster attack, normal

Purpose: If the object's target is valid and can currently be seen by the object, an Archvile explosion attack will occur. The object will face its target, emit the "barexp" sound, and damage the object directly for 20 points of damage. This attack will also impart an upward velocity to the target of (1000 / mass) units per tic. If the object has a currently spawned VileFire object, that object will emit a blast radius of 70 units, with maximum damage of 70 at the center of the explosion. This explosion can damage the attacking object if it is not immune to blast radius damage.

Thunk: Yes.

==Optional parameters==
Even though VileAttack is a classic Doom codepointer, it accepts the following optional arguments:
# name of sound to play (default "barexp")
# direct damage (default 20)
# blast damage (default 70)
# blast radius (default 70)
# thrust factor (default 1.0)
# damage type of direct hit (default: actor's MOD)
# damage type of blast hit (default: actor's MOD)
==See also==
*[[VileTarget]]

VileTarget

2026-06-14T13:34:42Z

Printz:

Type: Monster attack, normal

Purpose: Causes the object to [[FaceTarget|face]] its target, and spawns a VileFire object at the target's location. The [[Fire]] codepointer will be called on the VileFire object after it is spawned.

==Optional parameter==
VileTarget accepts an optional parameter: thing type to spawn. If omitted, it will be the VileFire (dehackednum 5) type.
==See also==
*[[VileAttack]]

VileTarget

2026-06-14T13:34:23Z

Printz:

DEMOLOOP

2026-06-14T13:07:47Z

Printz: /* Explanation of fields */

DEMOLOOP

2026-06-14T13:07:27Z

Printz:

Eternity supports the DEMOLOOP lump, which is part of the id24 specifications. This lump lets you define the startup sequence, when the game typically shows you various screens and game demos (replays) in sequence, repeating in a loop. Previously you would need to replace various lumps (like TITLEPIC and credits for the art screens, or the DEMOx lumps, possibly emptying them to remove demos) or set EDF [[gameproperties]], but the DEMOLOOP lump gives you complete control over this sequence.

DEMOLOOP must contain a JSON text data. The content of DEMOLOOP must be of the form:

{
"type": "demoloop",
"version": "1.0.0",
"metadata": {
"author": "...",
"timestamp": "...",
"application": "...
},

"data": {
"entries": [
{
"type": 0,
"primarylump": "IMAGE1",
"secondarylump": "MUSIC1",
"duration": 5.5,
"outrowipe": 1
},
{
"type": 1,
"primarylump: "DEMO5",
"outrowipe": 0
}
]
}
}

==Explanation of fields==
*"type": must be "demoloop".
*"version": must be "1.0.0" maximum.
*"metadata": required id24 information. Eternity does not consume them, but they should be provided.
*"data": must contain a single "entries" array of one or more elements (the example above shows two entries). Each element is described below:
:*"type": can be 0 or 1. 0 means art screen, 1 means demo (game replay). Caution: demos will only replay reliably in Eternity if the they are recorded in MBF-compatible or below (Boom or vanilla Doom) ports. Do not rely on Eternity-recorded demos to stay in sync with any Eternity update.
:*"primarylump": if "type" is 0 (art screen), this is the name of the graphics lump to display as the art screen. Eternity tolerates a missing "primarylump", in which case it will show the Eternity credits screen, but this is nonstandard and not portable. If "type" is 1 (demo), this is the name of the demo lump, and it's required.
:*"outrowipe": can be 0 or 1. 0 means no screen wipe effect (e.g. melt) will occur after the end of the current stage. 1 means to apply the wipe effect.
:*"secondarylump": only applies if "type" is 0 (art screen). This is optional and will be the lump name of the music to play during the display of the art screen. Eternity allows omitting the game-specific prefix such as "D_" on Doom; for example both "runnin" and "D_RUNNIN" are valid for Doom 2. The name is case insensitive. Completely omitting "secondarylump" will just keep playing the music from the previous stage. Demos don't use this option because the levels they replay have their own music.
:*"duration": only applies when "type" is 0 (art screen). This is time in seconds that the art screen will display before going to the next stage. It can be expressed in decimal quantities. It should be set for every entry of "type" 0.

DEMOLOOP

2026-06-14T13:07:11Z

Printz: /* Example */

DEMOLOOP

2026-06-14T13:04:37Z

Printz: /* Explanation of fields */

EDF game properties reference

2026-06-14T13:03:16Z

Printz: /* Demo control */

This unique block changes global game properties from established hardcoded defaults.
==Usage==
Simply add a block named <code>gameproperties { }</code> in your EDF lump, and set the items you want to change from the base game. If you have multiple such blocks in your EDF code, the last one will be considered.

The descriptions of the available fields are below.
==Structure==
gameproperties
{
flags.add <string>
flags.remove <string>
missionflags.add <string>
missionflags.remove <string>
demo.titletics <integer>
demo.advisortics <integer>
demo.pagetics <integer>
menu.background <string>
menu.transframe <string>
menu.skvattacksound <string>
menu.offset <integer>
menu.pointer1 <string>
menu.pointer2 <string>
menu.startmap <string>
border.flat <string>
border.topleft <string>
border.top <string>
border.topright <string>
border.left <string>
border.right <string>
border.bottomleft <string>
border.bottom <string>
border.bottomright <string>
console.charsperline <integer>
console.bellsound <string>
console.chatsound <string>
console.backdrop <string>
hud.pausepatch <string>
game.autoflightartifact <string>
game.pufftype <string>
game.telefogtype <string>
game.telefogheight <integer>
game.telesound <string>
game.thrustfactor <integer>
game.defpclass <string>
game.endgamefinaletype <string>
game.skillammomultiplier <floating-point>
game.monstermeleerange <value>
game.itemheight <floating-point>
game.skillammomultiplier <number>
game.lookpitchup <integer>
game.lookpitchdown <integer>
finale.text.x <integer>
finale.text.y <integer>
castcall.title.y <integer>
castcall.name.y <integer>
intermission.pic <string>
sound.defaultmusname <string>
sound.defaultsndname <string>
credit.background <string>
credit.y <integer>
credit.titlestep <integer>
exit.endtextname <string>
blood.defaultnormal <string>
blood.defaultrip <string>
blood.defaultcrush <string>
}

==Description==
===Flags===
'''flags.add''' and '''flags.remove'''

Adds or removes general gameplay flags from the default set. Group them using the usual syntax, separating them by | (vertical bar), + or "," (comma). For plus and comma, you need to surround all flags in quotes.
====List of flags====
You can use the flags from the following categories:
=====Gameplay=====
These flags control gameplay physics:
:*'''CHASEFAST''': accelerates all the [[Chase]] states of monsters on skill 5 and '''-fast''' like in Heretic.
:*'''HASMADMELEE''': causes all monsters to fight each other when player dies in single player (like in Heretic).
:*'''LOSTSOULBOUNCE''': for demo compatibility, decide whether lost souls should bounce on floors (normally it's a user or [[OPTIONS]] gameplay setting).
:*'''SKILL5RESPAWN''': make monsters respawn on skill 5.
=====Game flow control=====
These flags don't control gameplay per se, but are important for player control and progression:
:*'''DOOMWEAPONOFFSET''': setup weapon frame '''offset()''' attributes to render like in Doom. Necessary for Dehacked compatibility.
:*'''INVALWAYSOPEN''': Inventory is always open (like Strife, but not Heretic).
:*'''MAPXY''': use ''MAPxy'' map names by default. This implies that the '''-warp''' command-line parameter will expect one value, and any legacy features which depended on the ''ExMy'' vs. ''MAPxy'' arrangements will favour ''MAPxy''.
:*'''NODIEHI''': avoid playing the '''pdiehi''' (high) death sound.
:*'''SETENDOFGAME''': [[Teleport_EndGame]] enables the cast finale.
=====Cosmetic=====
These flags control minor display differences between the games. Usually they're of limited use for mod authors, only relevant for the base game differences. Check this list if you have particular issues to solve in your mod:
:*'''CENTERHUDMSG''': make messages always show in center. Typical with Heretic.
:*'''CHEATSOUND''': make the menu sound when cheating.
:*'''HASADVISORY''': display the advisory popup in the title screen. This means drawing an "ADVISOR" lump image at coordinates (4, 160) of a virtual 320x200 screen space, soon as the title screen appears.
:*'''HUDSTARTBARNAME''': displays the automap level name and time relative to the status bar instead of at a hardcoded position.
:*'''IMPACTBLOOD''': '''(unused)'''. Projectiles causing blood on impact is a [[thingtype]] flag now.
:*'''MNBIGFONT''': use big font for menu titles.
:*'''SAVESOUND''': make a sound in save and load menus. This is a small interface detail.
:*'''SHADOWTITLES''': adds shadows font effects to the titles in menus.
:*'''SKILL5WARNING''': warn player if they want to start a new game on skill 5.
:*'''WOLFHACK''': is subject to German-edition restriction on secret levels. Typical for Doom 2.

====Internally preset flags====
The games supported by Eternity start with the following flags preset:
=====Doom=====
Common to all variants: '''DOOMWEAPONOFFSET''', '''HUDSTATBARNAME''', '''SKILL5RESPAWN''', '''SKILL5WARNING'''.

In addition, the following variants of Doom have extra flags:
*shareware: '''NODIEHI'''
*retail (Ultimate Doom): '''LOSTSOULBOUNCE'''
*commercial (Doom II): '''MAPXY''', '''SETENDOFGAME''', '''WOLFHACK'''
:Final Doom, the Xbox and the BFG edition versions also have '''LOSTSOULBOUNCE'''.
=====Heretic=====
For Heretic, the preset flags are: '''CENTERHUDMSG''', '''CHASEFAST''', '''CHEATSOUND''', '''HASADVISORY''', '''HASMADMELEE''', '''MNBIGFONT''', '''SAVESOUND''', '''SHADOWTITLES'''.

===Mission flags===
'''missionflags.add''' and '''missionflags.remove'''

Adds or removes mission-specific flags. A mission is a variant of a game, such as how we have Ultimate Doom, Doom II, Final Doom etc. The available mission flags are:
====List of flags====
*'''ALLOWEXITTAG''': mission allows tagged normal exit lines.
*'''ALLOWSECRETTAG''': mission allows tagged secret exit lines.
*'''CONBACKTITLE''': use '''console.backdrop''' (settable here) instead of TITLEPIC for the console background.
*'''DEMOIFDEMO4''': fine control for DEMO4 lump's existence.
*'''DOOM2MISSIONS''': supports the Doom II mission packs.
*'''HASBETRAY''': has the "Betray" secret MAP33 level.
*'''NOGDHIGH''': BFG edition setup flag.
*'''NOTELEPORTZ''': preserves Z coordinate when teleporting, like in Final Doom. Only acts like this in vanilla/demo compatibility.
*'''WOLFNAMEHACKS''': override Wolfenstein secret level names.
====Mission-preset flags====
Those missions have the following flags set:
*Doom II: '''DOOM2MISSIONS'''
*Final Doom: '''DEMOIFDEMO4''', '''NOTELEPORTZ'''
*Xbox and BFG edition: '''DOOM2MISSIONS''', '''HASBETRAY''', '''NOGDHIGH''', '''WOLFNAMEHACKS'''
All other missions have 0 flags.
===Demo control===
NOTE: for finer control of the title and demo sequence, you can instead use a [[DEMOLOOP]] lump.
*'''demo.titletics'''
:Time to show the title screen. Defaults: 170 (Doom I), 385 (Doom II), 210 (Heretic).
*'''demo.advisortics'''
:Time to show the advisory banner over the title screen. This adds up to the whole time the title pic is shown. Only nonzero default is 140 in Heretic.
*'''demo.pagetics'''
:Time to show the page between demos. Defaults: 385 (Doom), 200 (Heretic).

===Menu customization===
*'''menu.background'''
:The default menu background flat. Defaults: FLOOR4_6 (Doom), FLOOR16 (Heretic), CONS1_5 (HacX mission).
*'''menu.transframe'''
:Name of [[frame]] to use in the video menu translucency preview. Defaults: S_TBALL1 (Doom), S_MUMMYFX1_1 (Heretic).
*'''menu.skvattacksound'''
:Name of [[sound]] to play when simulating attacking in the skin viewer. Defaults: shotgn (Doom), gldhit (Heretic).
*'''menu.offset'''
:Vertical offset upwards to draw the menu. Defaults: 0 (Doom), 4 (Heretic).
*'''menu.pointer1''' and '''menu.pointer2'''
:Graphic patches to use for the menu selector. Defaults: M_SKULL1 and M_SKULL2 (Doom), M_SLCTR1 and M_SLCTR2 (Heretic).
*'''menu.startmap'''
:Map lump name to load when the new game menu item is selected. This will skip the menus for episode and skill level selection. Default: No default

===Border customization===
*'''border.flat'''
:The flat to use for the background around the status bar and when the view window is reduced. Defaults: FLOOR7_2 (Doom I), GRNROCK (Doom II), FLOOR04 (Heretic shareware), FLAT513 (Heretic full).
*'''border.topleft''', '''.top''', '''.topright''', '''.left''', '''.right''', '''.bottomleft''', '''.bottom''' and '''.bottomright'''
:Pictures to use for the border. Defaults: BRDR_TL, BRDR_T, BRDR_TR, BRDR_L, BRDR_R, BRDR_BL, BRDR_B and BRDR_BR (Doom); BORD** (Heretic), same suffixes.
===Console customization===
*'''console.charsperline'''
:Number of characters per line to display in console. Default: 40.
*'''console.bellsound'''
:The beep error sound to use from the console, such as when errors occur. Defaults: tink (Doom), ht_chat (Heretic).
*'''console.chatsound'''
:The sound to play when receiving messages from other players. Defaults: tink (Doom I), radio (Doom II), ht_chat (Heretic).
*'''console.backdrop'''
:The name of the graphics lump to display for the console. Defaults: TITLEPIC (Doom), TITLE (Heretic).
===Heads-up display===
*'''hud.pausepatch'''
:The name of the graphics lump to display for the pause banner. Defaults: M_PAUSE (Doom), PAUSED (Heretic).
===Gameplay===
These options are relevant for gameplay physics. See also the similar gameplay flags.
{|class="wikitable sortable"
! Name
! Description
! Doom default
! Heretic default
|-
||'''game.autoflightartifact'''||The artifact to use when commanding the player to fly up.||(none)||ArtiFly
|-
||'''game.lookpitchup'''<br>
'''game.lookpitchdown'''
||Set the player view pitch limits up and down respectively, in degrees. Valid values are between 0 and 45 inclusive, integer only.||45||32
|-
||'''game.pufftype'''||The default hitscan puff when no EDF [[pufftype]] is specified.||BulletPuff||HereticStaffPuff
|-
||'''game.telefogtype'''||The teleportation fog thing type.||DoomTeleFog||HereticTeleFog
|-
||'''game.telefogheight'''||The distance of the telefog from the ground.||0||32
|-
||'''game.telesound'''||The teleportation sound.||telept||htelept
|-
||'''game.thrustfactor'''||The percentage of how much to thrust things based on damage.||100||150
|-
||'''game.defpclass'''||The default player class when starting a new game.||DoomMarine||Corvus
|-
||'''game.endgamefinaletype'''||Default behavior for [[Teleport_EndGame]]. Supported options are:
:*text
:*doom_credits
:*doom_deimos
:*doom_bunny
:*doom_marine
:*htic_credits
:*htic_water
:*htic_demon
:*psx_udoom
:*psx_doom2
||doom_credits (Doom I), text (Doom II)||htic_credits
|-
||'''game.skillammomultiplier'''||Floating-point value for skill 1 and 5 ammo multiplier.||2||1.5
|-
||'''game.monstermeleerange'''||Mode to calculate melee range. Supported options are:
:*doom: range is 44 + radius(enemy)
:*raven: range is 64
||doom||raven
|-
||'''game.itemheight'''||Item pick-up height. Unlike expectations, the height is not thingtype's height, but this value.||8.0||32.0
|}

===Finale and intermission===
*'''finale.text.x''' and '''finale.text.y'''
:Finale text coordinates. Defaults: 10, 10 (Doom); 20, 5 (Heretic)
*'''castcall.title.y'''
:Cast call title Y. Default: 20
*'''castcall.name.y'''
:Cast call name Y. Default: 180
*'''intermission.pic'''
:Intermission backdrop. Default: INTERPIC
===Sound===
*'''sound.defaultmusname'''
:Default music to play if none specified. Defaults: e1m1 (Doom I and Heretic), runnin (Doom II)
*'''sound.defaultsndname'''
:Sound to play when the one specified in EDF is unavailable. Defaults: pistol (Doom), gldhit (Heretic)
*'''sound.titlemusic'''
:Title screen music. No default.
===Credits===
*'''credit.background'''
:Swirling flat to use in the Eternity credits background. Defaults: NUKAGE1 (Doom I), SLIME05 (Doom II), SLIME01 (Hacx mission), FLTWAWA1 (Heretic)
*'''credit.y'''
:Credits Y coordinate. Defaults: 20 (Doom), 8 (Heretic)
*'''credit.titlestep'''
:Y step for each line. Defaults: 12 (Doom), 8 (Heretic)
===ENDOOM===
*'''exit.endtextname'''
:Exit text lump. Defaults: ENDOOM (Doom), ENDTEXT (Heretic)
===Blood===
*'''blood.defaultnormal'''
:Thing type for the default blood splat. Defaults: DoomBlood (Doom), HereticBloodSplatter (Heretic)
*'''blood.defaultrip'''
:Thing type for the piercing RIP projectiles. Defaults: DoomBlood (Doom), HereticBlood (Heretic)
*'''blood.defaultcrush'''
:Thing type for the crushing ceiling blood. Defaults: DoomBlood (Doom), HereticBlood (Heretic)

DEMOLOOP

2026-06-14T13:01:49Z

Printz:

Eternity supports the DEMOLOOP lump, which is part of the id24 specifications. This lump lets you define the startup sequence, when the game typically shows you various screens and game demos (replays) in sequence, repeating in a loop. Previously you would need to replace various lumps (like TITLEPIC and credits for the art screens, or the DEMOx lumps, possibly emptying them to remove demos) or set EDF [[gameproperties]], but the DEMOLOOP lump gives you complete control over this sequence.

DEMOLOOP must contain a JSON text data. The content of DEMOLOOP must be of the form:

{
"type": "demoloop",
"version": "1.0.0",
"metadata": {
"author": "...",
"timestamp": "...",
"application": "...
},

"data": {
"entries": [
{
"type": 0,
"primarylump": "IMAGE1",
"secondarylump": "MUSIC1",
"duration": 5.5,
"outrowipe": 1
},
{
"type": 1,
"primarylump: "DEMO5",
"outrowipe": 0
}
]
}
}

==Explanation of fields==
*"type": must be "demoloop".
*"version": must be "1.0.0" maximum.
*"metadata": required id24 information. Eternity does not consume them, but they should be provided.
*"data": must contain a single "entries" array of one or more elements (the example above shows two entries). Each element is described below:
:*"type": can be 0 or 1. 0 means art screen, 1 means demo (game replay).
:*"primarylump": if "type" is 0 (art screen), this is the name of the graphics lump to display as the art screen. Eternity tolerates a missing "primarylump", in which case it will show the Eternity credits screen, but this is nonstandard and not portable. If "type" is 1 (demo), this is the name of the demo lump, and it's required.
:*"outrowipe": can be 0 or 1. 0 means no screen wipe effect (e.g. melt) will occur after the end of the current stage. 1 means to apply the wipe effect.
:*"secondarylump": only applies if "type" is 0 (art screen). This is optional and will be the lump name of the music to play during the display of the art screen. Eternity allows omitting the game-specific prefix such as "D_" on Doom; for example both "runnin" and "D_RUNNIN" are valid for Doom 2. The name is case insensitive. Completely omitting "secondarylump" will just keep playing the music from the previous stage. Demos don't use this option because the levels they replay have their own music.
:*"duration": only applies when "type" is 0 (art screen). This is time in seconds that the art screen will display before going to the next stage. It can be expressed in decimal quantities. It should be set for every entry of "type" 0.

==Example==
Below is how the sequence in Ultimate Doom would be defined. Keep in mind that Eternity by default has it hardcoded, but a representation in the DEMOLOOP would look like the following. Important: only the value of "entries" is shown below, but remember to adhere to the complete format to make it valid:

[
{
"type": 0,
"primarylump": "TITLEPIC",
"secondarylump": "intro",
"outrowipe": 1,
"duration": 4.85714285714285714286
},
{
"type": 1,
"primarylump": "DEMO1",
"outrowipe": 1
},
{
"type": 0,
"outrowipe": 1,
"duration": 11
},
{
"type": 1,
"primarylump": "DEMO2",
"outrowipe": 1
},
{
"type": 0,
"primarylump": "CREDIT",
"outrowipe": 1,
"duration": 11
},
{
"type": 1,
"primarylump": "DEMO3",
"outrowipe": 1
},
{
"type": 1,
"primarylump": "DEMO4",
"outrowipe": 1
}
]

DEMOLOOP

2026-06-14T12:59:07Z

Printz: /* Explanation of fields */

Eternity supports the DEMOLOOP lump, which is part of the id24 specifications. This lump lets you define the startup sequence, when the game typically shows you various screens and game demos (replays) in sequence, repeating in a loop. Previously you would need to replace various lumps (like TITLEPIC and credits for the art screens, or the DEMOx lumps, possibly emptying them to remove demos), but the DEMOLOOP lump gives you complete control over this sequence.

DEMOLOOP must contain a JSON text data. The content of DEMOLOOP must be of the form:

{
"type": "demoloop",
"version": "1.0.0",
"metadata": {
"author": "...",
"timestamp": "...",
"application": "...
},

"data": {
"entries": [
{
"type": 0,
"primarylump": "IMAGE1",
"secondarylump": "MUSIC1",
"duration": 5.5,
"outrowipe": 1
},
{
"type": 1,
"primarylump: "DEMO5",
"outrowipe": 0
}
]
}
}

==Explanation of fields==
*"type": must be "demoloop".
*"version": must be "1.0.0" maximum.
*"metadata": required id24 information. Eternity does not consume them, but they should be provided.
*"data": must contain a single "entries" array of one or more elements (the example above shows two entries). Each element is described below:
:*"type": can be 0 or 1. 0 means art screen, 1 means demo (game replay).
:*"primarylump": if "type" is 0 (art screen), this is the name of the graphics lump to display as the art screen. Eternity tolerates a missing "primarylump", in which case it will show the Eternity credits screen, but this is nonstandard and not portable. If "type" is 1 (demo), this is the name of the demo lump, and it's required.
:*"outrowipe": can be 0 or 1. 0 means no screen wipe effect (e.g. melt) will occur after the end of the current stage. 1 means to apply the wipe effect.
:*"secondarylump": only applies if "type" is 0 (art screen). This is optional and will be the lump name of the music to play during the display of the art screen. Eternity allows omitting the game-specific prefix such as "D_" on Doom; for example both "runnin" and "D_RUNNIN" are valid for Doom 2. The name is case insensitive. Completely omitting "secondarylump" will just keep playing the music from the previous stage. Demos don't use this option because the levels they replay have their own music.
:*"duration": only applies when "type" is 0 (art screen). This is time in seconds that the art screen will display before going to the next stage. It can be expressed in decimal quantities. It should be set for every entry of "type" 0.

==Example==
Below is how the sequence in Ultimate Doom would be defined. Keep in mind that Eternity by default has it hardcoded, but a representation in the DEMOLOOP would look like the following. Important: only the value of "entries" is shown below, but remember to adhere to the complete format to make it valid:

[
{
"type": 0,
"primarylump": "TITLEPIC",
"secondarylump": "intro",
"outrowipe": 1,
"duration": 4.85714285714285714286
},
{
"type": 1,
"primarylump": "DEMO1",
"outrowipe": 1
},
{
"type": 0,
"outrowipe": 1,
"duration": 11
},
{
"type": 1,
"primarylump": "DEMO2",
"outrowipe": 1
},
{
"type": 0,
"primarylump": "CREDIT",
"outrowipe": 1,
"duration": 11
},
{
"type": 1,
"primarylump": "DEMO3",
"outrowipe": 1
},
{
"type": 1,
"primarylump": "DEMO4",
"outrowipe": 1
}
]

DEMOLOOP

2026-06-14T12:58:50Z

Printz:

Eternity supports the DEMOLOOP lump, which is part of the id24 specifications. This lump lets you define the startup sequence, when the game typically shows you various screens and game demos (replays) in sequence, repeating in a loop. Previously you would need to replace various lumps (like TITLEPIC and credits for the art screens, or the DEMOx lumps, possibly emptying them to remove demos), but the DEMOLOOP lump gives you complete control over this sequence.

DEMOLOOP must contain a JSON text data. The content of DEMOLOOP must be of the form:

{
"type": "demoloop",
"version": "1.0.0",
"metadata": {
"author": "...",
"timestamp": "...",
"application": "...
},

"data": {
"entries": [
{
"type": 0,
"primarylump": "IMAGE1",
"secondarylump": "MUSIC1",
"duration": 5.5,
"outrowipe": 1
},
{
"type": 1,
"primarylump: "DEMO5",
"outrowipe": 0
}
]
}
}

==Explanation of fields==
*"type": must be "demoloop".
*"version": must be "1.0.0" maximum.
*"metadata": required id24 information. Eternity does not consume them, but they should be provided.
*"data": must contain a single "entries" array of one or more elements (the example above shows two entries). Each element is described below:
:*"type": can be 0 or 1. 0 means art screen, 1 means demo (game replay).
:*"primarylump": if "type" is 0 (art screen), this is the name of the graphics lump to display as the art screen. Eternity tolerates a missing "primarylump", in which case it will show the Eternity credits screen, but this is nonstandard and not portable. If "type" is 1 (demo), this is the name of the demo lump, and it's required.
:*"outrowipe": can be 0 or 1. 0 means no screen wipe effect (e.g. melt) will occur after the end of the current stage. 1 means to apply the wipe effect.
:*"secondarylump": only applies if "type" is 0 (art screen). This is optional and will be the lump name of the music to play during the display of the art screen. Eternity allows omitting the game-specific prefix such as "D_" on Doom; for example both "runnin" and "D_RUNNIN" are valid for Doom 2. The name is case insensitive. Completely omitting "secondarylump" will just keep playing the music from the previous stage. Demos don't use this option because the levels they replay have their own music.
:*"duration": only applies when "type" is 0 (art screen). This is time in seconds that the art screen will display before going to the next stage. It can be expressed in decimal quantities. It should be set for every entry.

==Example==
Below is how the sequence in Ultimate Doom would be defined. Keep in mind that Eternity by default has it hardcoded, but a representation in the DEMOLOOP would look like the following. Important: only the value of "entries" is shown below, but remember to adhere to the complete format to make it valid:

[
{
"type": 0,
"primarylump": "TITLEPIC",
"secondarylump": "intro",
"outrowipe": 1,
"duration": 4.85714285714285714286
},
{
"type": 1,
"primarylump": "DEMO1",
"outrowipe": 1
},
{
"type": 0,
"outrowipe": 1,
"duration": 11
},
{
"type": 1,
"primarylump": "DEMO2",
"outrowipe": 1
},
{
"type": 0,
"primarylump": "CREDIT",
"outrowipe": 1,
"duration": 11
},
{
"type": 1,
"primarylump": "DEMO3",
"outrowipe": 1
},
{
"type": 1,
"primarylump": "DEMO4",
"outrowipe": 1
}
]

DEMOLOOP

2026-06-14T12:54:28Z

Printz:

Eternity supports the DEMOLOOP lump, which is part of the id24 specifications. This lump lets you define the startup sequence, when the game typically shows you various screens and game demos (replays) in sequence, repeating in a loop. Previously you would need to replace various lumps (like TITLEPIC and credits for the art screens, or the DEMOx lumps, possibly emptying them to remove demos), but the DEMOLOOP lump gives you complete control over this sequence.

DEMOLOOP must contain a JSON text data. The content of DEMOLOOP must be of the form:

{
"type": "demoloop",
"version": "1.0.0",
"metadata": {
"author": "...",
"timestamp": "...",
"application": "...
},

"data": {
"entries": [
{
"type": 0,
"primarylump": "IMAGE1",
"secondarylump": "MUSIC1",
"duration": 5.5,
"outrowipe": 1
},
{
"type": 1,
"primarylump: "DEMO5",
"outrowipe": 0
}
]
}
}

==Explanation of fields==
*"type": must be "demoloop".
*"version": must be "1.0.0" maximum.
*"metadata": required id24 information. Eternity does not consume them, but they should be provided.
*"data": must contain a single "entries" array of one or more elements (the example above shows two entries). Each element is described below:
:*"type": can be 0 or 1. 0 means art screen, 1 means demo (game replay).
:*"primarylump": if "type" is 0 (art screen), this is the name of the graphics lump to display as the art screen. Eternity tolerates a missing "primarylump", in which case it will show the Eternity credits screen, but this is nonstandard and not portable. If "type" is 1 (demo), this is the name of the demo lump, and it's required.
:*"outrowipe": can be 0 or 1. 0 means no screen wipe effect (e.g. melt) will occur after the end of the current stage. 1 means to apply the wipe effect.
:*"secondarylump": only applies if "type" is 0 (art screen). This is optional and will be the lump name of the music to play during the display of the art screen. Eternity allows omitting the game-specific prefix such as "D_" on Doom; for example both "runnin" and "D_RUNNIN" are valid for Doom 2. The name is case insensitive. Completely omitting "secondarylump" will just keep playing the music from the previous stage. Demos don't use this option because the levels they replay have their own music.
:*"duration": only applies when "type" is 0 (art screen). This is time in seconds that the art screen will display before going to the next stage. It can be expressed in decimal quantities.
==Example==
Below is how the sequence in Ultimate Doom would be defined. Keep in mind that Eternity by default has it hardcoded, but a representation in the DEMOLOOP would look like the following. Important: only the value of "entries" is shown below, but remember to adhere to the complete format to make it valid:

[
{
"type": 0,
"primarylump": "TITLEPIC",
"secondarylump": "intro",
"outrowipe": 1,
"duration": 4.85714285714285714286
},
{
"type": 1,
"primarylump": "DEMO1",
"outrowipe": 1
},
{
"type": 0,
"outrowipe": 1,
"duration": 11
},
{
"type": 1,
"primarylump": "DEMO2",
"outrowipe": 1
},
{
"type": 0,
"primarylump": "CREDIT",
"outrowipe": 1,
"duration": 11
},
{
"type": 1,
"primarylump": "DEMO3",
"outrowipe": 1
},
{
"type": 1,
"primarylump": "DEMO4",
"outrowipe": 1
}
]

DEMOLOOP

2026-06-14T12:38:11Z

Printz:

DEMOLOOP

2026-06-14T12:34:30Z

Printz: /* Explanation of fields */

Eternity supports the DEMOLOOP lump, which is part of the id24 specifications.

DEMOLOOP must contain a JSON text data. The content of DEMOLOOP must be of the form:

{
"type": "demoloop",
"version": "1.0.0",
"metadata": {
"author": "...",
"timestamp": "...",
"application": "...
},

"data": {
"entries": [
{
"type": 0,
"primarylump": "IMAGE1",
"secondarylump": "MUSIC1",
"duration": 5.5,
"outrowipe": 1
},
{
"type": 1,
"primarylump: "DEMO5",
"outrowipe": 0
}
]
}
}

==Explanation of fields==
*"type": must be "demoloop".
*"version": must be "1.0.0" maximum.
*"metadata": required id24 information. Eternity does not consume them, but they should be provided.
*"data": must contain a single "entries" array of one or more elements. Each element is described below:
:*"type": can be 0 or 1. 0 means art screen, 1 means demo (game replay).
:*"primarylump": if "type" is 0 (art screen), this is the name of the graphics lump to display as the art screen. Eternity tolerates a missing "primarylump", in which case it will show the credits screen, but this is nonstandard and not portable. If "type" is 1 (demo), this is the name of the demo lump, and it's required.
:*"outrowipe": can be 0 or 1. 0 means no screen wipe effect (e.g. melt) will occur after the end of the current stage. 1 means to apply the wipe effect.
:*"secondarylump": only applies if "type" is 0 (art screen). This is optional and will be the lump name of the music to play during the display of the art screen. Eternity allows omitting the game-specific prefix such as "D_" on Doom; for example both "runnin" and "D_RUNNIN" are valid for Doom 2. The name is case insensitive. Demos don't use this option because the levels they replay have their own music.
:*"duration": only applies when "type" is 0 (art screen). This is time in seconds that the art screen will display before going to the next stage. It can be expressed in decimal quantities.

DEMOLOOP

2026-06-14T12:34:03Z

Printz: /* Explanation of fields */

Eternity supports the DEMOLOOP lump, which is part of the id24 specifications.

DEMOLOOP must contain a JSON text data. The content of DEMOLOOP must be of the form:

{
"type": "demoloop",
"version": "1.0.0",
"metadata": {
"author": "...",
"timestamp": "...",
"application": "...
},

"data": {
"entries": [
{
"type": 0,
"primarylump": "IMAGE1",
"secondarylump": "MUSIC1",
"duration": 5.5,
"outrowipe": 1
},
{
"type": 1,
"primarylump: "DEMO5",
"outrowipe": 0
}
]
}
}

==Explanation of fields==
*"type": must be "demoloop".
*"version": must be "1.0.0" maximum.
*"metadata": required id24 information. Eternity does not consume them, but they should be provided.
*"data": must contain a single "entries" array of one or more elements. Each element is described below:
:*"type": can be 0 or 1. 0 means art screen, 1 means demo (game replay).
:*"primarylump": if "type" is 0 (art screen), this is the name of the graphics lump to display as the art screen. Eternity tolerates a missing "primarylump", in which case it will show the credits screen, but this is nonstandard and not portable. If "type" is 1 (demo), this is the name of the demo lump, and it's required.
:*"outrowipe": can be 0 or 1. 0 means no screen wipe effect (e.g. melt) will occur after the end of the current stage. 1 means to apply the wipe effect.
:*"secondarylump": only applies if "type" is 0 (art screen). This is optional and will be the lump name of the music to play during the display of the art screen. Eternity allows omitting the game-specific prefix such as "D_" on Doom. The name is case insensitive. Demos don't use this option because the levels they replay have their own music.
:*"duration": only applies when "type" is 0 (art screen). This is time in seconds that the art screen will display before going to the next stage. It can be expressed in decimal quantities.

DEMOLOOP

2026-06-14T12:30:05Z

Printz:

Eternity supports the DEMOLOOP lump, which is part of the id24 specifications.

DEMOLOOP must contain a JSON text data. The content of DEMOLOOP must be of the form:

{
"type": "demoloop",
"version": "1.0.0",
"metadata": {
"author": "...",
"timestamp": "...",
"application": "...
},

"data": {
"entries": [
{
"type": 0,
"primarylump": "IMAGE1",
"secondarylump": "MUSIC1",
"duration": 5.5,
"outrowipe": 1
},
{
"type": 1,
"primarylump: "DEMO5",
"outrowipe": 0
}
]
}
}

==Explanation of fields==
*"type": must be "demoloop".
*"version": must be "1.0.0" maximum.
*"metadata": required id24 information. Eternity does not consume them, but they should be provided.
*"data": must contain a single "entries" array of one or more elements. Each element is described below:
:*"type": can be 0 or 1. 0 means art screen, 1 means demo (game replay).
:*"primarylump": if "type" is 0 (art screen), this is the name of the graphics lump to display as the art screen. Eternity tolerates a missing "primarylump", in which case it will show the credits screen, but this is nonstandard and not portable. If "type" is 1 (demo), this is the name of the demo lump, and it's required.
:*"outrowipe": can be 0 or 1. 0 means no screen wipe effect (e.g. melt) will occur after the end of the current stage. 1 means to apply the wipe effect.
:*"secondarylump": only applies if "type" is 0 (art screen). This is optional and will be the lump name of the music to play during the display of the art screen. Demos don't use this option because the levels they replay have their own music.
:*"duration": only applies when "type" is 0 (art screen). This is time in seconds that the art screen will display before going to the next stage. It can be expressed in decimal quantities.

DEMOLOOP

2026-06-14T10:13:18Z

Printz: Created page with "Eternity supports the DEMOLOOP lump, which is part of the id24 specifications. DEMOLOOP must contain a JSON text data. The content of DEMOLOOP must be of the form: { "type": "demoloop", "version": "1.0.0", "metadata": { "author": "...", "timestamp": "...", "application": "... }, "data": { "entries: [ { "type": 0, "primarylump": "IMAGE1",..."

Predefined lumps

2026-06-14T09:58:00Z

Printz:

Most predefined lumps used in BOOM and MBF are still present in Eternity, although not all are used. These lumps can be found in eternity.pke and are no longer stored inside the executable, primarily for reasons of code size and compile time.
{{Backto|Editing reference}}

== New lump list ==
Menu text
---------
M_KEYBND Key Bindings entry in setup menu
M_AUTO Automap entry in setup menu
M_CHATM Chat strings entry in setup menu (Replaces M_CHAT, New to SMMU)
M_ENEM Enemies options entry in setup menu
M_STAT Status bar and Hud entry in setup menu
M_WEAP Weapons entry in setup menu
M_COLORS Palette color picker diagram
M_PALNO Xed-out symbol for unused automap features
M_BUTT1 Setup reset button off state (currently unused)
M_BUTT2 Setup reset button on state (currently unused)
M_LDSV Load/Save menu graphic (new to SMMU)
M_FEAT Features menu graphic (new to SMMU)
M_MULTI Multiplayer options menu graphic (new to SMMU)
M_ABOUT About menu graphic (new to SMMU)
M_DEMOS Demos menu graphic (new to SMMU)
M_WAD Wad loading menu graphic (new to SMMU)
M_SOUND Sound options menu graphic (new to SMMU)
M_VIDEO Video options menu graphic (new to SMMU)
M_MOUSE Mouse options menu graphic (new to SMMU)
M_HUD Heads-up options menu graphic (new to SMMU)
M_TCPIP TCP/IP connect menu graphic (new to SMMU)
M_SERIAL Serial connect menu graphic (new to SMMU)
M_PLAYER Player options menu graphic (new to SMMU)
M_COMPAT Compatibility options menu graphic (new to MBF)
M_SLIDEM Small slider gfx, middle segment (new to SMMU)
M_SLIDEL Small slider gfx, left end (new to SMMU)
M_SLIDEO Small slider gfx, caret (new to SMMU)
M_SLIDER Small slider gfx, right end (new to SMMU)
MBFTEXT Marine's Best Friend menu graphic (new to MBF, currently unused)
M_ETCOPT Eternity options menu graphic (new to Eternity)

Font chars
----------
STCFN096 ` character for standard DOOM font
STCFN123 left end of console horizontal divider bar (new to SMMU)
STCFN124 center of console horizontal divider bar (new to SMMU)
STCFN125 right end of console horizontal divider bar (new to SMMU)

STBR123 HUD font bargraph char, full, 4 vertical bars
STBR124 HUD font bargraph char, partial, 3 vertical bars
STBR125 HUD font bargraph char, partial, 2 vertical bars
STBR126 HUD font bargraph char, partial, 1 vertical bars
STBR127 HUD font bargraph char, empty, 0 vertical bars

DIG0 HUD font 0 char
DIG1 HUD font 1 char
DIG2 HUD font 2 char
DIG3 HUD font 3 char
DIG4 HUD font 4 char
DIG5 HUD font 5 char
DIG6 HUD font 6 char
DIG7 HUD font 7 char
DIG8 HUD font 8 char
DIG9 HUD font 9 char
DIGA HUD font A char
DIGB HUD font B char
DIGC HUD font C char
DIGD HUD font D char
DIGE HUD font E char
DIGF HUD font F char
DIGG HUD font G char
DIGH HUD font H char
DIGI HUD font I char
DIGJ HUD font J char
DIGK HUD font K char
DIGL HUD font L char
DIGM HUD font M char
DIGN HUD font N char
DIGO HUD font O char
DIGP HUD font P char
DIGQ HUD font Q char
DIGR HUD font R char
DIGS HUD font S char
DIGT HUD font T char
DIGU HUD font U char
DIGV HUD font V char
DIGW HUD font W char
DIGX HUD font X char
DIGY HUD font Y char
DIGZ HUD font Z char
DIG45 HUD font - char
DIG47 HUD font / char
DIG58 HUD font : char
DIG91 HUD font [ char
DIG93 HUD font ] char

Status bar
----------
STKEYS6 Both blue keys graphic
STKEYS7 Both yellow keys graphic
STKEYS8 Both red keys graphic

Box chars
---------
BOXUL Upper left corner of box
BOXUC Center of upper border of box
BOXUR Upper right corner of box
BOXCL Center of left border of box
BOXCC Center of box
BOXCR Center of right border of box
BOXLL Lower left corner of box
BOXLC Center of lower border of box
BOXLR Lower right corner of box

Misc HUD Graphics
-----------------
HU_FRAGS Frags display header graphic (new to SMMU)
HU_FRAGBX Frags display name plate graphic (new to SMMU)
CROSS1 + crosshair graphic (new to SMMU)
CROSS2 Angle crosshair graphic (new to SMMU)
VPO Visplane overflow indicator (new to SMMU)
OPENSOCK Network connection error indicator (new to SMMU)

Misc Graphics
-------------
UDTTL00 Hires Ultimate DOOM title screen, upper left (new to SMMU)
UDTTL01 Hires Ultimate DOOM title screen, lower left (new to SMMU)
UDTTL10 Hires Ultimate DOOM title screen, upper rght (new to SMMU)
UDTTL11 Hires Ultimate DOOM title screen, lower rght (new to SMMU)
D2TTL00 Hires DOOM II title screen, upper left (new to SMMU)
D2TTL01 Hires DOOM II title screen, lower left (new to SMMU)
D2TTL10 Hires DOOM II title screen, upper rght (new to SMMU)
D2TTL11 Hires DOOM II title screen, lower rght (new to SMMU)
DLGBACK Default dialog background graphic (new to Eternity)

Lumps missing in v1.1
---------------------
STTMINUS minus sign for neg frags in status bar
WIMINUS minus sign for neg frags on end screen
M_NMARE nightmare skill menu string
STBAR status bar background
DSGETPOW sound for obtaining power-up

Sprites
-------
TNT1A0 Invisible sprite for push/pull controller things
DOGS* MBF helper dog sprite (new to MBF)
PLS1* BFG 2704 plasma 1 sprite (new to MBF)
PLS2* BFG 2704 plasma 2 sprite (new to MBF)
SLDG* FLOOR_SLUDGE TerrainType fx sprite (new to Eternity)
LVAS* FLOOR_LAVA TerrainType fx sprite (new to Eternity)
SPSH* FLOOR_WATER TerrainType fx sprite (new to Eternity)

Misc Sounds
-----------
DSDGSIT MBF helper dog alert (new to MBF)
DSDGATK MBF helper dog attack (new to MBF)
DSDGACT MBF helper dog idle (new to MBF)
DSDGDTH MBF helper dog death (new to MBF)
DSDGPAIN MBF helper dog pain (new to MBF)
DSPLFEET Light player impact (new to Eternity)
DSFALLHT Falling damage impact death (new to Eternity)
DSPLFALL Falling damage player scream (new to Eternity)
DSTHUNDR MapInfo global thunder effect (new to Eternity)
DSMUCK FLOOR_SLUDGE TerrainType sound (new to Eternity)
DSBURN FLOOR_LAVA TerrainType sound (new to Eternity)
DSGLOOP FLOOR_WATER TerrainType sound (new to Eternity)

Flats
-----
METAL Complimentary brown metal flat (new to SMMU)
F_SKY2 Dummy flat for Hexen-style sky sectors (new to Eternity)

Switches and Animations
-----------------------
SWITCHES Definition of switch textures recognized
ANIMATED Definition of animated textures and flats recognized
==SWITCHES format==

The SWITCHES lump makes the names of the switch textures used in the game known to the engine. It consists of a list of records each 20 bytes long, terminated by an entry (not used) whose last 2 bytes are 0.

9 bytes Null terminated string naming "off" state texture for switch
9 bytes Null terminated string naming "off" state texture for switch
2 bytes Short integer for the IWADs switch will work in
1 = shareware
2 = registered/retail DOOM or shareware
3 = DOOM II, registered/retail DOOM, or shareware
0 = terminates list of known switches

'''NOTE''': for defining new switches, use [[EDF switch]], unless you need Boom compatibility. You can also use [[ANIMDEFS]] if you need GZDoom compatibility.

==ANIMATED format==

The ANIMATED lump makes the names of the animated flats and textures known to the engine. It consists of a list of records, each 23 bytes long, terminated by a record (not used) whose first byte is -1 (255).

1 byte -1 to terminate list, 0 if a flat, 1 if a texture
9 bytes Null terminated string naming last texture/flat in animation
9 bytes Null terminated string naming first texture/flat in animation
4 bytes Animation speed, number of frames between animation changes
The [http://www.doomworld.com/idgames/index.php?id=9463 BOOM utility package] contains a program, SWANTBLS.EXE that will generate both the SWITCHES and ANIMATED lumps from a text file. An example is provided, DEFSWANI.DAT that generates the standard set of switches and animations for DOOM.

'''NOTE''': for defining new animations, use [[EDF animation]], unless you need Boom compatibility. You can also use [[ANIMDEFS]] if you need GZDoom compatibility.

==OPTIONS lump==
New to MBF, this lump allows you to set certain game settings for when the wad is loaded. See the [[OPTIONS]] documentation for more information.

== New to SMMU ==

Setting the animation speed for a flat to a number higher than 65535 will
cause the flat to use the swirling liquid effect rather than animation.

===Colormaps===
WATERMAP Custom greenish colormap for underwater use
LAVAMAP Custom red colormap for lava (new to SMMU)
The WATERMAP lump has the same format as COLORMAP, 34 tables of 256 bytes each, see the [http://www.doomworld.com/idgames/index.php?id=1138 UDS] for details. Note that colormaps you add to a PWAD must be between C_START and C_END markers.

The BOOM utility package contains a program, CMAPTOOL.EXE, that will generate custom colormaps for use with Eternity. It also includes 7 premade colormaps, and an add-on wad containing them.

===Color translation tables===
CRBRICK Translates red range to brick red
CRTAN Translates red range to tan
CRGRAY Translates red range to gray
CRGREEN Translates red range to green
CRBROWN Translates red range to brown
CRGOLD Translates red range to dark yellow
CRRED Translates red range to red range (no change)
CRBLUE Translates red range to light blue
CRBLUE2 Translates red range to dark blue (status bar numerals)
CRORANGE Translates red range to orange
CRYELLOW Translates red range to light yellow
These tables are used to translate the red font characters to other colors. They are made replaceable in order to support custom palettes in TC's better. Note however that the font character graphics must be defined using the palette indices for the standard red range of the palette 176-191.

== Eternity Note ==

The default text translation range in Heretic is gray rather than red, and replacement fonts should use the gray range in the palette to support color translations.

Data Lumps and Scripts
----------------------
TXTRCONV DOOM -> DOOM II texture conversion table (new to SMMU)
KEYDEFS Default keybindings (new to Eternity)
==TXTRCONV format==

The TXTRCONV lump is used to translate DOOM textures to DOOM II textures, for the purpose of playing ExMy levels under DOOM II (accessed via the map command). The format of this lump is currently very strict. The pairs of texture names must be aligned precisely, with the first texture name (<= 8 character) starting in column 0, followed by spaces up to column 16, where the second DOOM II replacement texture name must start. Only one pair must be on a line, and lines must be terminated with a line break. This lump is ASCII text.

==KEYDEFS format==

KEYDEFS contains the engine's default key bindings. This lump is written to file as keys.csc when a file by that name cannot be found. Editing of this defaults lump is not generally desirable, but it is a simple console script, the syntax of which is expounded upon in the Eternity Engine Console Reference. This lump is ASCII text.

==Sprite colour translation tables==
[[Thingtype]] [[EDF]] definitions allow a sprite's colour range to be translated, similar to how the green range is changed with the TRANSLATION1 and TRANSLATION2 [[thing type flags]], but in this case, by using custom external tables. These lumps are 256 bytes large and must be included between T_START and T_END. Normally, they will consist of consecutive 8-bit numbers from 0 to 255 if there is no translation, but the indices which need to be changed will have the numbers of the target colours.

==Demo loop control==
See [[DEMOLOOP]].

[[Category:Editing reference]]

Eternity Engine

2026-06-14T09:56:56Z

Printz: /* Making mods for Eternity */

The Eternity Engine is [[Doom Wiki:Team Eternity|Team Eternity]]'s advanced [[Doom Wiki:Doom|Doom]] [[Doom Wiki:Source port|source port]] and the primary subject of this Wiki. It is meant as a versatile feature port which keeps gameplay compatibility with its roots (DOOM, [[BOOM]], [[MBF]] and so on) while advancing with powerful features such as new ways to design levels ([[linked portals]], [[3DMidTex]], [[polyobjects]] etc.) and modding capabilities (using the [[EDF]] definition language). Every new feature we add is tested not to affect anything that exists so far.

==History==
The Eternity Engine began in 1998 as a simple modification of [[Doom Wiki:Boom|Boom]] meant to power [[Doom Wiki:Eternity TC|Eternity TC]], which was at that time a new and active project. When [[Doom Wiki:Lee Killough|Lee Killough]] began the [[MBF]] project, [[Doom Wiki:James_Haley_(Quasar)|James "Quasar" Haley]] became a beta tester after emailing Lee with questions about the early Doom alpha versions. The Eternity project moved to an MBF code base after that port's first release.

In late 1999, [[Doom Wiki:Simon "Fraggle" Howard|Fraggle]] released v3.10 of his MBF-based source port [[SMMU]], which contained support for the new [[Doom Wiki:FraggleScript|FraggleScript]] scripting language. Although activity in the Eternity TC project by editors had steadily dropped to almost nothing, Quasar was still interested in developing the code associated with it. Needing features such as scripting and the [[console]], he then moved the Eternity project's code into SMMU.

Despite this long history of jumping between Boom-based ports, no public release of Eternity based on any port other than SMMU was ever made. The first private alpha, released to a select few beta testers, was derived from SMMU 3.21 with selected modifications from 3.30. Because of this, Eternity began at version 3.29.

After the release of the [[Doom Wiki:Caverns_of_Darkness|Caverns of Darkness]] project, which used a customized version of Eternity Engine v3.29 Development Beta 5, the project began to attract more attention. A second programmer, [[Doom Wiki:Stephen_McGranahan_(SoM)|Steven "SoM" McGranahan]], joined the project and immediately set to work porting the code to use [[Wikipedia:Simple_DirectMedia_Layer|SDL]], making it capable of running on many operating systems, including [[Wikipedia:Microsoft Windows|Windows]].

Now it has [[Universal Doom Map Format|UDMF]] support and a dynamic weapon and inventory system. It supports linked portals for full room-over-room gameplay. Current major goals for the engine include completing support for [[Doom Wiki:Heretic|Heretic]].

==Getting started==
You can download Eternity either from [https://www.doomworld.com/forum/25-eternity/ Doomworld] (as official releases) or from [https://devbuilds.drdteam.org/eternity/ DRDTeam] (as "beta quality" development builds, which in practice are generally stable, and may be needed for some modding features listed on this wiki).

Eternity's goal that makes it different from feature ports such as [[Doom Wiki:GZDoom|GZDoom]] is demo compatibility similar to that of [[Doom Wiki:PrBoom+|PrBoom+]], kept specifically to ensure that every new feature we add fits seamlessly with what exists so far, and that we don't stray from the bases made so far in the DOOM gameplay.

Support for [[Doom Wiki:Heretic|Heretic]] is growing, though still under way. While we don't support vanilla Heretic demos for playback yet, a possibility exists in the horizon.

===Playing Eternity===
When run directly, Eternity tries to find the DOOM, DOOM 2 or Final DOOM megawads in some standard locations. If it can't find them, it will let you know. If it finds several of them, it will start with a picker screen, letting you choose.

On [[Wikipedia:Windows|Windows]] you can use the drag-and-drop feature of Explorer by moving WADs and PKEs into Eternity's executable. Or you can use Powershell or Command Prompt in a manner similar to starting [[Doom Wiki:Vanilla Doom|vanilla DOOM]]. See [[list of command line parameters]]. For more advanced cases, you can use [[GFS]] files to quickly load multiple files and settings together.

The [[Wikipedia:macOS|macOS]] version of Eternity also comes with a visual dialog-box launcher, hiding the complexity behind starting a terminal.

For advanced technical stuff, cheating and testing maps, Eternity has a [[console]] similar to [[Wikipedia:Quake|Quake's]].

====Loading main game WADs====
Eternity looks for the main game WADs (IWADs), e.g. doom2.wad, at these locations:
* IWAD file paths in user/system.cfg;
* the -iwad command-line parameter;
* the [[Doom Wiki:Environment variables|'''DOOMWADDIR''' or '''DOOMWADPATH''' environment variables]];
* the IWAD in the working directory;
* the IWAD file under the appropriate game folder of the base directory, which can be found using the -game parameter.

====Loading Master Levels for DOOM II====
Eternity offers a menu for conveniently loading each WAD from the Master Levels. To start the Master Levels:
# Start Eternity with DOOM II;
# Go to the Options menu, under the Game Files section, select WAD Options;
# Under the Master Levels section, you may need to specify Master Levels Dir to the path with the WADs;
# Once the path is configured, enter Play Master Levels.
Once the Master Levels Dir is configured, entering New Game from the menu will give you the choice to start the Master Levels.

===Making mods for Eternity===
The editors [[Doom Wiki:Doom Builder X|Doom Builder X]], [[Doom Wiki:GZDoom Builder|GZDoom Builder]], [[Doom Wiki:Eureka|Eureka]] and [[Doom Wiki:SLADE|SLADE]] have Eternity level editing support of varying degrees. For [[UDMF]] (modern advanced format) you can use Doom Builder X, GZDoom Builder or SLADE. However, if you lack access to a UDMF-capable editor or don't want the complexity it brings, you can also use the classic DOOM format, combined with [[ExtraData]]

For general modding, Eternity relies on [[EDF]], its own content definition language. For level definitions in particular it uses [[EMAPINFO]]. Eternity also has growing support for some lumps from [[Doom Wiki:GZDoom|GZDoom]], [[Doom Wiki:Hexen|Hexen]] and recently the id24 standard such as [[ANIMDEFS]] or [[DEMOLOOP]], thus increasing the support for cross-port mods.

Eternity can load [[PKE]] archives, not just [[Doom Wiki:WAD|WADs]]. It can also load unarchived folders structured the same as PKE archives (you can use the -file command-line parameter on folders), facilitating project work. You can use powerful editors such as [[Wikipedia:Visual Studio Code|Visual Studio Code]] on such folders to edit your EDF modifications.

See [[Editing reference|all editing reference]] to get started on modding.

==Major Features==

===Cardboard engine===
[[Cardboard]] is a floating-point rendering engine created by [[Doom Wiki:Stephen_McGranahan_(SoM)|SoM]] that fixes several problems inherent with the classic fixed-point [[Doom Wiki:Doom rendering engine|Doom rendering engine]].

===EDF===
[[EDF]], which stands for Eternity Definition Files, is a textual input language that allows specification of almost all the static game data which was once contained inside the executable. This includes [[thingtype|thing types]], [[frame|frames]], sprites, terrain definitions, and more. EDF has a relaxed [[Wikipedia:C programming language|C]]-like syntax and can be used from both files and [[WAD]] lumps.

===ExtraData===
[[ExtraData]] is another EDF-like data specification language that allows the Doom map format to be extended with any kind of data. Use of special thing, line, and sector types within a map allows the editor to attach ExtraData records to those objects. Special data for the objects is then given inside the script.

===Linked portals===
[[Linked portals]] are surfaces that, like regular [[portals]], connect different areas of the map, but in addition can be walked through, thus allowing multistory maps to be designed in Doom.

===[[MapInfo]]===
Eternity expands SMMU's level info system significantly, allowing dozens of new properties to be specified, and allowing cascading global EMAPINFO lumps as an alternative to inserting MapInfo data into level headers. Among other things, MapInfo is used to tie ExtraData and ACS scripts to the maps that use them.

==Releases==
A complete list of Eternity's release history follows. You can find most of these releases on the [https://www.doomworld.com/forum/25-eternity/ Doomworld Eternity forum], on the [https://github.com/team-eternity/eternity/releases GitHub Eternity repository] and the older releases on the [http://eternity.mancubus.net/ee-old/ Eternity Mancubus website]. Most of the releases are Windows only, but the most recent ones are also available on macOS.

For finer grained non-official releases, see also the [[Eternity Engine#Development builds|development builds]] below.

===Version 3.29===
* 3.29 Private Alpha - September 14, 2000
* 3.29 Public Beta 1 - January 8, 2001
* 3.29 Public Beta 2 - January 9, 2001
* 3.29 Public Beta 3 - May 10, 2001
* 3.29 Public Beta 4 - June 30, 2001
* 3.29 Development Beta 5 - October 2, 2001
* 3.29 "Gamma" - July 4, 2002

===Version 3.31===
* 3.31 Public Beta 1 - September 11, 2002
* 3.31 Public Beta 2 - March 5, 2003
* 3.31 Public Beta 3 - August 8, 2003
* 3.31 Public Beta 4 - November 29, 2003
* 3.31 Public Beta 5 - December 17, 2003
* 3.31 Public Beta 6 - February 29, 2004
* 3.31 Public Beta 7 - April 11, 2004
* 3.31 "Delta" Pre-Release Alpha 1 - August 23, 2004
* 3.31 "Delta" Pre-Release Alpha 2 - November 11, 2004
* 3.31.10 "Delta" - January 19, 2005

===Version 3.33===
* 3.33.00 "Genesis" - May 26, 2005
* 3.33.01 "Outcast" - June 24, 2005
* 3.33.02 "Warrior" - October 1, 2005
* 3.33.33 "Paladin" - May 17, 2006
* 3.33.50 "Phoenix" - October 23, 2006

===Version 3.35===
* [http://www.doomworld.com/vb/eternity/45146-eternity-engine-v3-35-90-simorgh/ 3.35.90] "Simorgh" - January 11, 2009
* [http://www.doomworld.com/vb/eternity/45757-eternity-engine-3-35-92-nekhbet/ 3.35.92] "Nekhbet" - March 22, 2009

===Version 3.37===
* [http://www.doomworld.com/vb/eternity/49268-eternity-engine-3-37-00-sekhmet/ 3.37.00] "Sekhmet" - January 1, 2010

===Version 3.39===
* [http://www.doomworld.com/vb/eternity/52873-eternity-engine-v3-39-20-resheph/ 3.39.20] "Resheph" - October 10, 2010

===Version 3.40===
* [http://www.doomworld.com/vb/eternity/53944-eternity-engine-v3-40-00-rebirth/ 3.40.00] "Rebirth" - January 8, 2011
* [http://www.doomworld.com/vb/eternity/55219-announcing-the-blue-box-ee-3-40-11-and-vaporware-demo/ 3.40.11] "Aasgard" - May 2, 2011
* [http://www.doomworld.com/vb/eternity/55874-eternity-engine-3-40-15-wodanaz/ 3.40.15] "Wodanaz" - June 22, 2011
* [http://www.doomworld.com/vb/eternity/58281-eternity-engine-v3-40-20-mjolnir/ 3.40.20] "Mjolnir" - December 26, 2011
* [http://www.doomworld.com/vb/eternity/61245-eternity-engine-3-40-25-midgard/ 3.40.25] "Midgard" - August 27, 2012
* [http://www.doomworld.com/vb/eternity/62087-eternity-engine-3-40-30-alfheim/ 3.40.30] "Alfheim" - November 4, 2012
* [http://www.doomworld.com/vb/eternity/64382-eternity-engine-3-40-37-gungnir/ 3.40.37] "Gungnir" - May 27, 2013
* [http://www.doomworld.com/vb/eternity/67069-eternity-engine-3-40-46-bifrost/ 3.40.46] "Bifröst" - January 19, 2014 - ''first one with a macOS release''

===Version 3.42===
* [https://www.doomworld.com/forum/topic/94046-eternity-engine-34202-heimdal-files-documentation-buglist/ 3.42.02] "Heimdal" - May 7, 2017
* [https://www.doomworld.com/forum/topic/95351-eternity-engine-34203a-heimdal-release-2-hotfix/ 3.42.03a] "Heimdal" release 2 - August 2, 2017

===Version 4.00===
* [https://www.doomworld.com/forum/topic/99957-eternity-engine-40000-v%C3%B6lusp%C3%A1/ 4.00.00] "Völuspá" - March 17, 2018

===Version 4.01===
* [https://www.doomworld.com/forum/topic/117429-eternity-engine-40100-tyrfing/ 4.01.00] "Tyrfing" - October 13, 2020

===Version 4.02===
* [https://www.doomworld.com/forum/topic/119425-eternity-engine-40200-forseti/ 4.02.00] "Forseti" - January 27, 2021

===Version 4.04===
* [https://www.doomworld.com/forum/topic/148678-eternity-engine-40400-glitnir/ 4.04.00] "Glitnir" - October 12, 2024
* [https://www.doomworld.com/forum/topic/148678-eternity-engine-40401-glitnir-update-1/ 4.04.01] "Glitnir" Update 1 - October 20, 2024
* [https://www.doomworld.com/forum/topic/148678-eternity-engine-40402-glitnir-update-2/ 4.04.02] "Glitnir" Update 2 - November 18, 2024

===Version 4.05===
* [https://www.doomworld.com/forum/topic/154848-eternity-engine-40504-citadel/ 4.05.04] "Citadel" - August 23, 2025

===Version 4.06===
* [https://www.doomworld.com/forum/topic/158835-eternity-engine-40600-nidhogg/ 4.06.00] "Nidhogg" — June 13, 2026

==Cross-platform development==
Eternity is built by using the [[Wikipedia:CMake|CMake]] utility. You can download the Eternity [[Wikipedia:source code|source code]] from [[Wikipedia:GitHub|GitHub]] and execute CMake. Eternity's source code repository, as well as the latest releases, are located [https://github.com/team-eternity/eternity/ here].

==Development builds==
Development builds ("beta" releases) for Eternity are available for Windows and macOS at [http://devbuilds.drdteam.org/eternity/ DRDTeam's website]. They are recommended if you encounter serious bugs with any of the official releases, or if you want to test brand new features that didn't exist in the latest official releases. Due to their beta status, they may be untested and have other problems. However, due to the sometimes sporadic release cycles, it's often recommended to just try the development builds. The only problem is that by upgrading Eternity often, savegames tend to become unusable, so exercise caution before upgrading Eternity if you rely on games with saves.

==System features==
*[[Cardboard engine]]
*[[List of command line parameters]]
*[[Console]]
*[[List of cheat codes]]
*[[GFS|GFS files]]
*[[ZIP|ZIP mods]]

==Gameplay and modding features==
*[[DeHackEd / BEX Reference]]
*[[List of codepointers]]
*[[EDF|EDF files]]
*[[Editing reference]]
*[[OPTIONS|OPTIONS lump]]
*[[MapInfo]]
*[[SMMU|Features inherited from SMMU]]
*[[ExtraData]]
*[[Hexen format SNDINFO]]

[[Category:Source ports]]

Main Page

2026-06-14T09:55:50Z

Printz:

__NOTOC__
==Welcome to the Eternity Engine Wiki==

The [[Eternity Engine]] [[Wikipedia:Wiki|Wiki]] is a community-maintained documentation resource for the Eternity Engine [[Doom Wiki:Source port|source port]] and everything related to it. It is powered by [[Wikipedia:MediaWiki|MediaWiki]]. Feel free to edit and create articles to help make this a valuable source of knowledge. If you're not familiar with wiki markup, [[Wikipedia:Help:Wikitext|look here]] for some examples.

==About Eternity==
See general info about the port in the [[Eternity Engine]] page.

==Level editing==
See [[Editing reference]] for the full documentation. Below are some of the more popular features:
*[[EMAPINFO|Map info (EMAPINFO lump)]]
:*[[UMAPINFO]]
*[[ACS scripting]]
:*[[ACS built-in functions]]
*[[UDMF]]
*[[ExtraData]]
*[[Linedef types|Classic linedef specials]]
*[[Detailed parameterized linedef specification|Parameterized linedef specials]]
*[[Linedef flags|New linedef flags in Eternity]]
*[[Thing types|New Eternity thing types]]

==Wad storage==
*[[ZIP|PKE files or directory structure]]

==Tutorials==
*[[Polyobject]]
*[[3DMidTex tutorial]]
*[[3DMidTex advanced topics]]
*[[Portals]]
*[[Linked portals]]

==Gameplay editing==
===Eternity definition files===
*[[EDF|Full EDF reference]]
*[[Thingtype]]
*[[Thing type flags]]
*[[Frame]]
*[[List of codepointers]]
*[[Sound]]
*[[OPTIONS]]
===Cross-port definition lumps===
*[[ANIMDEFS]]
*[[Dehacked]]
*[[DEMOLOOP]]
*[[S_SKIN]]
===Base game data===
*Frames.edf: [https://github.com/team-eternity/eternity/blob/master/base/doom/frames.edf list of Doom thing frames (states)]
*Things.edf: [https://github.com/team-eternity/eternity/blob/master/base/doom/things.edf list of Doom thing types (classes)]

==Console and command line==
*[[List of command line parameters]]
:*[[Environment variables]]
*[[Console]]
:*[[List of console commands and variables|Console commands and variables]]

==Inherited stuff==
*[[SMMU]]
*[[MBF]]
*[[Boom]]

==Eternity maps and mods==
*[[List of maps and mods made for Eternity]]

==Latest version==
The latest version of the Eternity Engine is currently {{Latest}}.
*[[Eternity_Engine#Releases|List of Eternity releases]]
*[https://devbuilds.drdteam.org/eternity/ Daily unofficial development builds.]

[[Category:Eternity Wiki]]

EMAPINFO

2026-06-14T09:52:41Z

Printz: /* Level identification */

The '''EMAPINFO''' lump customizes the properties of maps. It is the main Eternity lump for this purpose.
{{Backto|Eternity Engine}}
{{editref}}

==Usage==
Level info data is stored in the global EMAPINFO lump, which is a plain-text lump containing information for all maps together. Variables for each level must be placed under a section header that has the same name as the map's header lump.

Do note that older Eternity and [[SMMU]] compatible releases had level info stored inside each map's header lump. This is deprecated however, kept only for backward compatibility.

==Syntax==
*Each map definition begins with a block header. This consists of the map's lump name in brackets, such as [MAP01], [E1M1], or [MYLEVEL].
*Variables are specified in the lines following the block header.
*All values are treated as text strings, and quotation marks are not required.
*Comments may start with '#', ';', or '//'. All three comments are single line only, and extend to the end of the line.
*An optional equal sign can be placed between a variable and the value it is given. It is not an error to omit it.

==EMAPINFO Variables==
===Level identification===
{|class="wikitable sortable"
! Variable
! Description
! Example
|-
||creator||The level author's name. As of Eternity 4.06.00, the creator name will show up in the intermission under the level name. This is adapted from the [[UMAPINFO]] specifications for "author". You can view the current creator in the console using the "creator" console command. If this value is not provided, the default value is "unknown", which will not show up in the intermission.||
creator = Edwin Chadwick 'chadders'
|-
||edf-intername||Boolean value which, if true, enables the use of [[EDF]]-defined intermission map name strings which will be drawn using the FONTB graphics (provided in eternity.wad for DOOM/DOOM II, and natively supported by Heretic). This feature is meant to obsolete the levelpic variable and to remove the need for authors to create title graphics for their maps in DOOM/DOOM II. It also allows intermission map name replacement to work correctly for the next level and for Heretic without any hacks.
The EDF string which will be used as the intermission name for the current map should have the mnemonic _IN_NAME_<mapname>, where <mapname> is the exact name of the map's header lump (Example: _IN_NAME_MAP01).
In order for the name of the next map to display correctly, the current level must either define its nextlevel/nextsecret values explicitly, or it must be an ExMy or MAPxy level.
||
edf-intername = true
|-
||enterpic||Name of a 320x200 graphic lump to be displayed as the background of the statistics intermission during the ''entering'' of this map's stage. If omitted and previous map's '''interpic''' property is set, it will continue displaying that.||
enterpic = INTOCAVE
|-
||inter-levelname||Name of the map to display in the intermission score screen. This is separate from '''levelname''' which is for the automap display, and can be used as an alternative to '''levelpic''' which is a graphic lump for the intermission name. If both '''inter-levelname''' and '''levelpic''' are present, '''levelpic''' takes precedence. Unlike '''levelpic''', this one also works in Heretic.||
inter-levelname = Circle of death
|-
||interpic||Name of a 320x200 graphic lump to be displayed as the background of the statistics intermission.||
interpic = BOSSBACK
|-
||killstats||Boolean value that allows the statistics intermission between two maps to be disabled. If the map has a finale sequence to be displayed, it will start immediately, otherwise the next map will be loaded.||
killstats = true
|-
||levelname||This is the name of the level which will be displayed in the automap. This value overrides any string provided via DeHackEd. If you want to change the level name displayed in the intermission, change '''levelpic''' or '''inter-levelname'''.||
levelname = chadders' lair
|-
||levelnum||Integer value used to identify it for the [[Parameterized_linedef_specials#Exits|Teleport_NewMap]] special. When the map's lump name does not follow the format MAPxx or ExMy, a numeric value is required.||
[D2DM1]
levelnum = 1
|-
||levelpic||This is the name of a graphic lump which will be shown as the level name during the statistics intermission when this map is the previous map which was just beaten. This value is only used for DOOM and DOOM II maps. You can also use '''inter-levelname''' to set the intermission display level name, which will use the necessary font, already included in Eternity.||
levelpic = E1M1PIC
|-
||levelpicnext||The level pic to show for the next level, only when taking the normal exit. If omitted, it will try that level's '''levelpic''' or write the name of it using the font.||
|-
||levelpicsecret||Same as '''levelpicnext''', but for taking the secret exit instead.||
|-
||nextlevel||The exact header name of the next level to go to when a normal exit occurs on this map. This can specify *any* lump name, but the lump should be a valid level header or an error will occur.||
nextlevel = CHAD2
|-
||nextsecret||The exact header name of the next level to go to when a secret exit occurs on this map. This can specify *any* lump name, but the lump should be a valid level header or an error will occur. Note that except for maps which normally have secret exits, the default behavior is to repeat the same level. This MapInfo value allows you to avoid that and use a secret exit on any map.||
nextsecret = MAP34
|-
||allowexittags||If true, allows the exit linedef ''classic'' linedef specials to use their tags to specify the number of the level to go to. This doesn't apply to the parameterized specials||
allowexittags = true
|-
||allowsecrettags||Same as '''allowexittags''', but applies to the secret exit ''classic'' linedef specials.||
allowsecrettags = true
|-
||partime||Partime for the map in seconds. This value overrides any value provided via DeHackEd. Note that partimes are only supported in episodes 1-3 of DOOM and any map of DOOM II. Ultimate DOOM episode 4, Heretic, and non-standard maps currently never display par times.||
partime = 200
|}

===Scripting===
{|class="wikitable sortable"
! Variable
! Description
! Example
|-
||acsopendelay||Boolean value that determines whether or not scripts' execution within the first 35 tics after entering the map is delayed until 35 tics have passed.||
acsopendelay = true
|-
||acsscript||Name of the lump containing the compiled ACS script for this map. '''Not needed for UDMF, which uses the BEHAVIOR lump between TEXTMAP and ENDMAP, as added by the level editor.'''||
acsscript = SCRIPT01
|-
||extradata||Name of the ExtraData script lump for this map. See the ExtraData Reference for full information on ExtraData. There are no naming restrictions on ExtraData script lumps. '''Not needed for UDMF, only for the classic format.'''||
extradata = EXTRDT01
|-
||levelscript||Name of a compiled {{Deprecated}} Small script lump which will serve as the Levelscript for this map. NOTE: use '''acsscript''' for compiled ACS scripts.||
|}
===Physics===
{|class="wikitable sortable"
! Variable
! Description
! Example
|-
||aircontrol||How much control the player has when attempting to move while in mid-air. By default Doom and Heretic have it 0 (no control whatsoever) and Hexen and Strife have a tiny value, just enough to allow jumping on objects.

Default value is 0. Keep in mind you can set the '''comp_aircontrol''' property in the [[OPTIONS]] lump to "yes" or "no", which if enabled, will produce the Hexen effect. Maximum air control is 65536, so anything between 0 and 65536 is equivalent to air control between 0 and 100%.
||
|-
||airfriction||This is an optional field, useful if '''aircontrol''' is significant, in order to limit player's speed when moving in mid-air. ''Non-player objects, such as projectiles, are not affected by this''. Default value is 0 (no friction, like in the original games), and the maximum is 65536 (no acceleration whatsoever). In order to feel realistic, if it's needed, make sure to keep '''airfriction''' very low, or lower than the ground friction anyway, as it ''only'' applies while you're above ground.||
|-
||disable-jump||If set to '''true''', it will disable player jumping in current level. Default is '''false'''. See also [[playerclass]] in EDF, and comp_aircontrol in [[OPTIONS]].||
disable-jump = true
|-
||gravity||Global gravity factor for the current level. The default gravity value is 65536.||
# Enable 50% gravity
gravity = 32768
|}
===Ambience===
{|class="wikitable sortable"
! Variable
! Description
! Example
|-
||altskyname||Name of a texture to display instead of the normal sky texture during a lightning strike. This value is only used if lightning is enabled for this level. If this value is not provided, no sky animation will occur during lightning strikes.||
altskyname = LBOLTSKY
|-
||colormap||Name of a colormap lump to use as the global colormap for this level. This colormap is applied to any sectors which do not have their own colormaps specified either via use of 242 height transfer linedefs or scripting. This lump must be between C_START and C_END tags or the "colormaps" directory in the PKE.||
colormap = FOGMAP
|-
||outdoorfog||Name of a colormap lump to use as the outdoors colormap for this level. This lump must be between C_START and C_END tags or the "colormaps" directory in the PKE.||
outdoorfog = FOGMAP
|-
||defaultenvironment||Sets the default sound environment (reverb) effect to happen in the map. Use two identifiers, as defined in [[EDF]].||
defaultenvironment = 1 2
|-
||doublesky||Boolean value that determines whether or not this map uses double skies. When double skies are enabled, any F_SKY1 or F_SKY2 sectors *not* affected by MBF sky transfer lines will use both the primary and secondary sky textures together. The secondary texture will be drawn first, normally, then the primary texture will be drawn over it, omitting any pixels which use palette index zero (this is usually pure black). Any MapInfo sky delta values provided will be applied to their respective textures.||
doublesky = true
|-
||fullbright||Boolean value that determines whether fullbright can be used on this level. When fullbright is disabled, player gun flashes will not occur, and fullbright sprites and particles will be drawn normally. This should be used with most custom colormaps, since flashes and fullbright sprites usually look incorrect with them.||
fullbright = false
|-
||lightning||Boolean value that toggles the global lightning effect. When set to true, all sky sectors on the map will flash at randomly determined intervals along with a thunder sound and optional animation of the normal sky texture. Warning: sectors must currently have a sky ceiling at the beginning of the level in order to be affected by lightning. The only current method to make non-sky sectors flash during lightning strikes is via use of BOOM lighting transfer linedefs. This may be improved in the near future.||
lightning = true
|-
||music||Provides the name of a MUS or MIDI lump to use as music. In DOOM gamemodes, the string provided should be the lump name minus the "D_" prefix. In Heretic, the string provided should be the lump name minus the "MUS_" prefix. You are *not* limited to using only the built-in music lump names; Eternity automatically adds any new lump which matches the naming convention for the current gamemode to the internal music list.||
music = cheese
|-
||noautosequences||Determines the default assignment of sound sequences. If set to true, no sound sequences will be automatically assigned to sectors. The sequence of all sectors by default will be sequence number 0. If set to false, the default sound sequences defined in '''sounds.edf''' will be used. These sequences implement the normal, default behaviors for DOOM and Heretic, and can be easily overridden by the user if desired.||
noautosequences = true
|-
||sector-colormaps||This optional property can be used to enforce classic Boom or SMMU-style behaviour for sector colormap applications using either the [[Transfer_Heights]] linedef special or [[ExtraData]] or [[UDMF]] sector properties. Possible values are:
*''normal'': this is the default value. It makes the [[Transfer_Heights]] special apply the Boom behaviour, where the sector the player is in causes the entire view to change colour, while [[ExtraData]] and [[UDMF]] use the SMMU-introduced behaviour, where the sector colour is local to the sector, as if having local coloured light or fog effect. It's default because of required compatibility with past Boom and MBF wad releases, whereas the new SMMU introduced behaviour can be more useful for new maps with ExtraData or UDMF.
*''Boom'': the Boom sector colormap behaviour will apply to all kinds of colormap settings, like in Boom or MBF.
*''SMMU'': the SMMU sector colormap behaviour will apply to all kinds of colormap settings, like in previous Eternity versions.
||
sector-colormaps = normal
|-
||skydelta||Pixels per gametic that the primary sky texture should scroll. This effect will only be applied to double skies and to F_SKY1 sectors which are NOT affected by any MBF sky transfer linedefs.||
skydelta = 5
|-
||sky2delta||Pixels per gametic that the secondary sky texture should scroll. This effect will only be applied to double skies and to F_SKY2 sectors (which cannot be affected by MBF sky transfer linedefs).||
sky2delta = 7
|-
||skyname||Name of a texture to use as the primary sky for this map. This sky will appear in all sectors which use the F_SKY1 flat, and it will also appear as the top layer of Hexen-style double skies. The name provided for this lump must be a valid texture or an error will occur.||
skyname = SKY2
|-
||sky2name||Name of a texture to use as the secondary sky for this map. This sky will appear in all sectors which use the F_SKY2 flat, and it will also appear as the bottom layer of Hexen- style double skies. The name provided for this lump must be a valid texture or an error will occur. If no name is provided for the secondary sky, the primary sky name will be copied to it, so it is not an error to use F_SKY2 or double skies in a level where the sky2 texture is not explicitly defined.||
sky2name = SKY4
|-
||skyrowoffset||Set the vertical offset of the sky. This is useful to give you control from which height to draw the sky. Above this offset, the sky will appear as fading to a single colour. Usual values are:
*100: draw like in vanilla Doom, where it assumed that the player can't look up and down.
*200: draw like in Heretic, where the view pitch is ±32 degrees.
*260: draw for the view pitch of ±45 degrees, as set by default in Eternity Doom.
You can customize the player view pitch in [[EDF game properties]].

If unspecified, Eternity will autodetect based on sky height. If at least 200 units, tall, it will set to 200. If less, it will set to 100. Note that even 200 is insufficient for the default ±45 degree view pitch; you may want to set 260 for that. NOTE: for PrBoom wad compatibility, and only for DOOM wads, the same autodetection rule doesn't apply if the tall sky is purely specified via a texture replacement: those will always be drawn as vanilla, as long as no '''skyname''' replacement is set in EMAPINFO.

Also, beware that [[Static_Init (sky transfer)]] specials use their own sidedef Y offset to adjust the sky location, bypassing this setting.
||
|-
||sky2rowoffset||Same as '''skyrowoffset''', but for '''sky2name'''. If you use '''doublesky''' as in Hexen, you may want to set both these row offset fields.||
|-
||unevenlight||Boolean value that determines whether walls parallel to the x and y axes of the game world are given lighting values 1 level higher or lower than other walls. This can dramatically affect the perceived light level of an area, so only use it for maps that are designed specifically for it. Maps which use custom global colormaps should usually set this value to false, since it only generally looks appropriate with the normal colormap.||
unevenlight = false
|-
||sound-*||There are several sound-* commands which can be used to replace the default sounds in a map with sounds, using their mnemonics defined in [[EDF]].

Sounds available for replacement:
swtchx
swtchn
stnmov
pstop
pstart
bdcls
bdopn
dorcls
doropn
fcmove
||
sound-swtchx = newswtch
sound-doropn = dorcreak
|}

===Finale control===
{|class="wikitable sortable"
! Variable
! Description
! Example
|-
||'''boss-specials'''||A flags field that specifies what formerly level-specific boss "magic codepointer" actions are enabled for this level. This field takes a value in the same format as that used by [[EDF]], DeHackEd/BEX, and ExtraData flag fields, but the format will be reviewed here for completeness.

A BEX flag list is a string of flag names separated by whitespace, pipe characters, commas, or plus characters. Flags are combined using bitwise-OR logic, so a flag name can be specified more than once. Specifying a flag name causes that flag to be turned on. The default state of all flags is off.

These are the flag values which are available for this field:
Flag name Decimal Hex Meaning
-----------------------------------------------------------------
MAP07_1 1 0x0001 MAP07 Special 1 (BossDeath only)
MAP07_2 2 0x0002 MAP07 Special 2 (BossDeath only)
E1M8 4 0x0004 E1M8 Special
E2M8 8 0x0008 E2M8 Special
E3M8 16 0x0010 E3M8 Special
E4M6 32 0x0020 E4M6 Special (BossDeath only)
E4M8 64 0x0040 E4M8 Special
E5M8 128 0x0080 E5M8 Special (HticBossDeath Only)
-----------------------------------------------------------------

Notes: Actions differ depending on whether monsters use the [[BossDeath]] or [[HticBossDeath]] codepointers. See the documentation for those specific codepointers to see what actions they perform. The monsters which must be dead for a given special to activate are controlled by various [[EDF]]/BEX thingtype flags. Together, these features allow complete customization.
||
All of these are equivalent:
boss-specials = MAP07_1|MAP07_2
boss-specials = MAP07_1 | MAP07_2

boss-specials = MAP07_1+MAP07_2
boss-specials = MAP07_2 + MAP07_2

boss-specials = MAP07_1,MAP07_2
boss-specials = MAP07_1, MAP07_2

boss-specials = MAP07_1 MAP07_2
|-
||'''endofgame'''||Boolean value which, if true, causes a DOOM II cast call to occur when this map is exited. This value is currently only usable in DOOM II. A level must also have intermission text defined for a cast call to take place.||
endofgame = true
|-
||'''endpic'''||String value. If '''finaletype''' has been set to '''endpic''', this value specifies the picture lump to display for the finale.||
finaletype = endpic
endpic = FINALPIC // show a custom patch lump named FINALPIC
|-
||'''finale-early'''||Boolean value which, if true, indicates that a text intermission should occur after this map without displaying the usual score screen. If no intermission text is defined for this map, this variable has no effect.||
finale-early = true
|-
||'''finale-normal'''||Boolean value which, if true, indicates that a text intermission should only occur after this map if a normal exit was taken. If no intermission text is defined for this map, this variable has no effect.||
finale-normal = true
|-
||'''finale-secret'''||Boolean value which, if true, indicates that a text intermission should only occur after this map if a secret exit was taken. If no intermission text is defined for this map, this variable has no effect.||
finale-secret = true
|-
||'''finaletype'''||Specifies which finale image sequence to use. Possible values are:
*'''text''': Only the intertext will be displayed. Play will then continue to the next level normally.
*'''doom_credits''': The DOOM CREDITS screen will be displayed after the intertext. Play ends after this map.
*'''doom_deimos''': The DOOM picture of Deimos above Hell will be displayed after the intertext. Play ends after this map.
*'''doom_bunny''': The scrolling picture of Daisy's head on a pike will be displayed, accompanied by the words "THE END" which are shot up with several bullets. Play ends after this map.
*'''doom_marine''': The E4 ending picture of the Marine holding Daisy's head is displayed after the intertext. Play ends after this map.
*'''htic_credits''': The Heretic CREDITS screen will be displayed after the intertext. Play ends after this map.
*'''htic_water''': The Heretic underwater screen with special palette is displayed after the intertext. Play ends after this map.
*'''htic_demon''': The Heretic demon scroller is displayed after the intertext. Play ends after this map.
*'''psx_udoom''': PSX Ultimate DOOM finale
*'''psx_doom2''': PSX DOOM II finale
*'''endpic''': End the game with a custom static picture set by the '''endpic''' property (see its relevant row in this table). This is a generalization of the DOOM I and Heretic intermediary episode endings.
||
|-
||'''finalesecrettype'''||Like above, but for the secret exit.||
|-
||'''inter-backdrop'''||Name of a 64x64 flat OR a 320x200 graphic lump to be displayed as the background of a text intermission which occurs after this map. The flat namespace will be searched first, so if both a flat and a 320x200 picture of the same name exist, the flat will be chosen.||
inter-backdrop = FLATHUH1
|-
||'''intermusic'''||Name of a MUS or MIDI lump to use as music during a text intermission which occurs after this map. If no intertext is defined for the map, this value will not be used. In DOOM gamemodes, the string provided should be the lump name minus the "D_" prefix. In Heretic, the string provided should be the lump name minus the "MUS_" prefix. You are *not* limited to using only the built-in music lump names; Eternity automatically adds any new lump which matches the naming convention for the current gamemode to the internal music list.||
intermusic = ROMERO
|-
||'''intertext'''||Lump name of a text lump to be loaded as intermission text for this level. If the level has an intermission by default, this will replace the default intermission text, even if it has been edited via DeHackEd. If there is not normally a text intermission after this map, the presence of this variable serves to enable it. If no intertext is defined, a text intermission will not occur after a map. The formatting of the text inside the indicated lump will be preserved exactly, with the exception of tabs, which are converted to spaces. There is no length limitation, but only one screen of text (40 columns, 17 rows) can be displayed. Any extra text will be drawn off the bottom of the screen.||
intertext = MAP04TXT
|-
||'''intertext-secret'''||Like '''intertext''', but for the secret exit.||
|-
||'''killfinale'''||Boolean value that allows built-in text intermission points to be disabled. For example, if you do not want text to appear after DOOM II MAP11, set this variable to true.||
killfinale = true
|-
||'''levelaction'''||Specifies what happens when certain species of monsters all die in the map. The syntax is such: ''thingtype'' ''special'' [''arg1'' [''arg2'' [''arg3'' [''arg4'' [''arg5'']]]]]. You can even have more than one per level.

NOTE: this does not depend on the presence of the [[BossDeath]] or [[HticBossDeath]] codepointer in a monster's death sequence. Instead, it triggers immediately when the last monster is killed. In fact, if used in a map without such monsters, it will activate from the start. Also, it can only be used for actual monsters ('''COUNTKILL''' or '''KILLABLE''' in '''cflags'''), not for picking up items. Use '''levelaction-bossdeath''' if you want triggering when said codepointers are run.
||
levelaction = BaronOfHell Floor_LowerToLowest 671 8
levelaction = Arachnotron Floor_RaiseByValue 667 8 24
|-
||'''levelaction-bossdeath'''||Like '''levelaction''', but activated only during [[BossDeath]] or [[HticBossDeath]] from a dead monster of the intended species. Same syntax as '''levelaction'''. Warning: this one is susceptible to unexpected effects if the monsters can respawn or resurrect, then die again, retriggering the action. Use with care.
|}

==Examples of EMAPINFO Definitions==
A basic EMAPINFO lump may be similar to this:

[MAP01]
levelname = Evil Hell Lab
creator = DooMGuy667

[E1M1]
levelname = Not Hangar
creator = Not Romero
skyname = SKY3
skydelta = 1

The first example would change the automap and intermission screen names for MAP01 to "Evil Hell Lab" and when the <tt>creator</tt> command is used in the console, output "DooMGuy667". The name in the brackets is the map the EMAPINFO applies to, so by changing <tt>[MAP01]</tt> to <tt>[MAP02]</tt>, the changes would apply to MAP02 instead.

The second example also sets a name and creator for the map (for the E1M1 mapslot, in this case), and also specifies that it will use SKY3 and scroll the sky slowly, using the skydelta variable.
==See also==
*[[UMAPINFO]]
[[Category:Editing]]

UMAPINFO

2026-06-14T09:51:18Z

Printz: /* UMAPINFO - EMAPINFO equivalence table */

Eternity supports the common UMAPINFO lump, a standard defined in PrBoom+um. See its [https://github.com/kraflab/umapinfo/blob/master/docs/spec.md specification]. Make sure to adhere to the strict standard if you want the maps to be playable on all implementing ports. Otherwise, if you make the mod for Eternity, [[EMAPINFO]] is more recommended, since it contains the entire feature set.

==UMAPINFO - EMAPINFO equivalence table==
{|class="wikitable sortable"
!UMAPINFO property
!EMAPINFO equivalent
|-
||'''author'''||'''creator'''
|-
||'''levelname''', '''label'''||Both of these influence '''levelname''' and '''inter-levelname'''
|-
||'''levelpic'''||'''levelpic'''
|-
||'''next'''||'''nextlevel'''. Beware that omitting '''next''' in UMAPINFO will reset '''nextlevel''' to the next numbered map (if following the ExMy/MAPxy format).
|-
||'''nextsecret'''||'''nextsecret'''. Same situations as with UMAPINFO '''next'''.
|-
||'''skytexture'''||'''skyname'''. For more advanced sky effects, you need EMAPINFO.
|-
||'''music'''||'''music'''. Beware that in UMAPINFO you must specify the entire lump length (including D_ or MUS_, based on game).
|-
||'''exitpic'''||'''interpic'''
|-
||'''enterpic'''||'''enterpic'''
|-
||'''partime'''||'''partime'''
|-
||'''endgame = false'''||
:'''finaletype text'''
:'''endofgame false'''
:'''finale-early false'''
|-
||'''endgame = true'''||Effect depends on the current episode (if map lump is named in a standard manner).
|-
||'''endpic'''||
:'''endofgame false'''
:'''finaletype endpic'''
:'''endpic''' ''lump''
It also enables the finale for both the normal and secret exits.
|-
||'''endbunny = true'''||
:'''endofgame false'''
:'''finaletype doom_bunny'''
It also enables the finale for both the normal and secret exits.
|-
||'''endcast = true'''||
:'''endofgame true'''
:'''finaletype text'''
|-
||'''nointermission'''||'''finale-early'''
|-
||'''intertext''', '''intertextsecret''''||Like '''intertext''' and '''intertext-secret''' but gets the text directly from UMAPINFO. It also sets or clears '''finale-normal''' and '''finale-secret'''.
|-
||'''interbackdrop'''||'''inter-backdrop'''
|-
||'''intermusic'''||'''intermusic'''
|-
||'''episode'''||[[EDF menu reference]]. See '''mn_episode''' in particular. If mod has this EDF menu defined, it takes priority over UMAPINFO.
|-
||'''bossaction'''||'''levelaction-bossdeath'''. However, the UMAPINFO always uses classic specials, whereas the EMAPINFO version uses UDMF parameterized specials. Clearing '''bossaction''' is like setting EMAPINFO '''boss-specials 0'''.
|}

==See also==
*[[EMAPINFO]]

Eternity Engine

2026-06-13T21:16:35Z

Printz: /* Releases */

The Eternity Engine is [[Doom Wiki:Team Eternity|Team Eternity]]'s advanced [[Doom Wiki:Doom|Doom]] [[Doom Wiki:Source port|source port]] and the primary subject of this Wiki. It is meant as a versatile feature port which keeps gameplay compatibility with its roots (DOOM, [[BOOM]], [[MBF]] and so on) while advancing with powerful features such as new ways to design levels ([[linked portals]], [[3DMidTex]], [[polyobjects]] etc.) and modding capabilities (using the [[EDF]] definition language). Every new feature we add is tested not to affect anything that exists so far.

==History==
The Eternity Engine began in 1998 as a simple modification of [[Doom Wiki:Boom|Boom]] meant to power [[Doom Wiki:Eternity TC|Eternity TC]], which was at that time a new and active project. When [[Doom Wiki:Lee Killough|Lee Killough]] began the [[MBF]] project, [[Doom Wiki:James_Haley_(Quasar)|James "Quasar" Haley]] became a beta tester after emailing Lee with questions about the early Doom alpha versions. The Eternity project moved to an MBF code base after that port's first release.

In late 1999, [[Doom Wiki:Simon "Fraggle" Howard|Fraggle]] released v3.10 of his MBF-based source port [[SMMU]], which contained support for the new [[Doom Wiki:FraggleScript|FraggleScript]] scripting language. Although activity in the Eternity TC project by editors had steadily dropped to almost nothing, Quasar was still interested in developing the code associated with it. Needing features such as scripting and the [[console]], he then moved the Eternity project's code into SMMU.

Despite this long history of jumping between Boom-based ports, no public release of Eternity based on any port other than SMMU was ever made. The first private alpha, released to a select few beta testers, was derived from SMMU 3.21 with selected modifications from 3.30. Because of this, Eternity began at version 3.29.

After the release of the [[Doom Wiki:Caverns_of_Darkness|Caverns of Darkness]] project, which used a customized version of Eternity Engine v3.29 Development Beta 5, the project began to attract more attention. A second programmer, [[Doom Wiki:Stephen_McGranahan_(SoM)|Steven "SoM" McGranahan]], joined the project and immediately set to work porting the code to use [[Wikipedia:Simple_DirectMedia_Layer|SDL]], making it capable of running on many operating systems, including [[Wikipedia:Microsoft Windows|Windows]].

Now it has [[Universal Doom Map Format|UDMF]] support and a dynamic weapon and inventory system. It supports linked portals for full room-over-room gameplay. Current major goals for the engine include completing support for [[Doom Wiki:Heretic|Heretic]].

==Getting started==
You can download Eternity either from [https://www.doomworld.com/forum/25-eternity/ Doomworld] (as official releases) or from [https://devbuilds.drdteam.org/eternity/ DRDTeam] (as "beta quality" development builds, which in practice are generally stable, and may be needed for some modding features listed on this wiki).

Eternity's goal that makes it different from feature ports such as [[Doom Wiki:GZDoom|GZDoom]] is demo compatibility similar to that of [[Doom Wiki:PrBoom+|PrBoom+]], kept specifically to ensure that every new feature we add fits seamlessly with what exists so far, and that we don't stray from the bases made so far in the DOOM gameplay.

Support for [[Doom Wiki:Heretic|Heretic]] is growing, though still under way. While we don't support vanilla Heretic demos for playback yet, a possibility exists in the horizon.

===Playing Eternity===
When run directly, Eternity tries to find the DOOM, DOOM 2 or Final DOOM megawads in some standard locations. If it can't find them, it will let you know. If it finds several of them, it will start with a picker screen, letting you choose.

On [[Wikipedia:Windows|Windows]] you can use the drag-and-drop feature of Explorer by moving WADs and PKEs into Eternity's executable. Or you can use Powershell or Command Prompt in a manner similar to starting [[Doom Wiki:Vanilla Doom|vanilla DOOM]]. See [[list of command line parameters]]. For more advanced cases, you can use [[GFS]] files to quickly load multiple files and settings together.

The [[Wikipedia:macOS|macOS]] version of Eternity also comes with a visual dialog-box launcher, hiding the complexity behind starting a terminal.

For advanced technical stuff, cheating and testing maps, Eternity has a [[console]] similar to [[Wikipedia:Quake|Quake's]].

====Loading main game WADs====
Eternity looks for the main game WADs (IWADs), e.g. doom2.wad, at these locations:
* IWAD file paths in user/system.cfg;
* the -iwad command-line parameter;
* the [[Doom Wiki:Environment variables|'''DOOMWADDIR''' or '''DOOMWADPATH''' environment variables]];
* the IWAD in the working directory;
* the IWAD file under the appropriate game folder of the base directory, which can be found using the -game parameter.

====Loading Master Levels for DOOM II====
Eternity offers a menu for conveniently loading each WAD from the Master Levels. To start the Master Levels:
# Start Eternity with DOOM II;
# Go to the Options menu, under the Game Files section, select WAD Options;
# Under the Master Levels section, you may need to specify Master Levels Dir to the path with the WADs;
# Once the path is configured, enter Play Master Levels.
Once the Master Levels Dir is configured, entering New Game from the menu will give you the choice to start the Master Levels.

===Making mods for Eternity===
The editors [[Doom Wiki:Doom Builder X|Doom Builder X]], [[Doom Wiki:GZDoom Builder|GZDoom Builder]], [[Doom Wiki:Eureka|Eureka]] and [[Doom Wiki:SLADE|SLADE]] have Eternity level editing support of varying degrees. For [[UDMF]] (modern advanced format) you can use Doom Builder X, GZDoom Builder or SLADE. However, if you lack access to a UDMF-capable editor or don't want the complexity it brings, you can also use the classic DOOM format, combined with [[ExtraData]]

For general modding, Eternity relies on [[EDF]], its own content definition language. For level definitions in particular it uses [[EMAPINFO]]. Eternity also has growing support for some lumps from [[Doom Wiki:GZDoom|GZDoom]] and [[Doom Wiki:Hexen|Hexen]] such as [[ANIMDEFS]], thus increasing the support for cross-port mods.

Eternity can load [[PKE]] archives, not just [[Doom Wiki:WAD|WADs]]. It can also load unarchived folders structured the same as PKE archives (you can use the -file command-line parameter on folders), facilitating project work. You can use powerful editors such as [[Wikipedia:Visual Studio Code|Visual Studio Code]] on such folders to edit your EDF modifications.

See [[Editing reference|all editing reference]] to get started on modding.

==Major Features==

===Cardboard engine===
[[Cardboard]] is a floating-point rendering engine created by [[Doom Wiki:Stephen_McGranahan_(SoM)|SoM]] that fixes several problems inherent with the classic fixed-point [[Doom Wiki:Doom rendering engine|Doom rendering engine]].

===EDF===
[[EDF]], which stands for Eternity Definition Files, is a textual input language that allows specification of almost all the static game data which was once contained inside the executable. This includes [[thingtype|thing types]], [[frame|frames]], sprites, terrain definitions, and more. EDF has a relaxed [[Wikipedia:C programming language|C]]-like syntax and can be used from both files and [[WAD]] lumps.

===ExtraData===
[[ExtraData]] is another EDF-like data specification language that allows the Doom map format to be extended with any kind of data. Use of special thing, line, and sector types within a map allows the editor to attach ExtraData records to those objects. Special data for the objects is then given inside the script.

===Linked portals===
[[Linked portals]] are surfaces that, like regular [[portals]], connect different areas of the map, but in addition can be walked through, thus allowing multistory maps to be designed in Doom.

===[[MapInfo]]===
Eternity expands SMMU's level info system significantly, allowing dozens of new properties to be specified, and allowing cascading global EMAPINFO lumps as an alternative to inserting MapInfo data into level headers. Among other things, MapInfo is used to tie ExtraData and ACS scripts to the maps that use them.

==Releases==
A complete list of Eternity's release history follows. You can find most of these releases on the [https://www.doomworld.com/forum/25-eternity/ Doomworld Eternity forum], on the [https://github.com/team-eternity/eternity/releases GitHub Eternity repository] and the older releases on the [http://eternity.mancubus.net/ee-old/ Eternity Mancubus website]. Most of the releases are Windows only, but the most recent ones are also available on macOS.

For finer grained non-official releases, see also the [[Eternity Engine#Development builds|development builds]] below.

===Version 3.29===
* 3.29 Private Alpha - September 14, 2000
* 3.29 Public Beta 1 - January 8, 2001
* 3.29 Public Beta 2 - January 9, 2001
* 3.29 Public Beta 3 - May 10, 2001
* 3.29 Public Beta 4 - June 30, 2001
* 3.29 Development Beta 5 - October 2, 2001
* 3.29 "Gamma" - July 4, 2002

===Version 3.31===
* 3.31 Public Beta 1 - September 11, 2002
* 3.31 Public Beta 2 - March 5, 2003
* 3.31 Public Beta 3 - August 8, 2003
* 3.31 Public Beta 4 - November 29, 2003
* 3.31 Public Beta 5 - December 17, 2003
* 3.31 Public Beta 6 - February 29, 2004
* 3.31 Public Beta 7 - April 11, 2004
* 3.31 "Delta" Pre-Release Alpha 1 - August 23, 2004
* 3.31 "Delta" Pre-Release Alpha 2 - November 11, 2004
* 3.31.10 "Delta" - January 19, 2005

===Version 3.33===
* 3.33.00 "Genesis" - May 26, 2005
* 3.33.01 "Outcast" - June 24, 2005
* 3.33.02 "Warrior" - October 1, 2005
* 3.33.33 "Paladin" - May 17, 2006
* 3.33.50 "Phoenix" - October 23, 2006

===Version 3.35===
* [http://www.doomworld.com/vb/eternity/45146-eternity-engine-v3-35-90-simorgh/ 3.35.90] "Simorgh" - January 11, 2009
* [http://www.doomworld.com/vb/eternity/45757-eternity-engine-3-35-92-nekhbet/ 3.35.92] "Nekhbet" - March 22, 2009

===Version 3.37===
* [http://www.doomworld.com/vb/eternity/49268-eternity-engine-3-37-00-sekhmet/ 3.37.00] "Sekhmet" - January 1, 2010

===Version 3.39===
* [http://www.doomworld.com/vb/eternity/52873-eternity-engine-v3-39-20-resheph/ 3.39.20] "Resheph" - October 10, 2010

===Version 3.40===
* [http://www.doomworld.com/vb/eternity/53944-eternity-engine-v3-40-00-rebirth/ 3.40.00] "Rebirth" - January 8, 2011
* [http://www.doomworld.com/vb/eternity/55219-announcing-the-blue-box-ee-3-40-11-and-vaporware-demo/ 3.40.11] "Aasgard" - May 2, 2011
* [http://www.doomworld.com/vb/eternity/55874-eternity-engine-3-40-15-wodanaz/ 3.40.15] "Wodanaz" - June 22, 2011
* [http://www.doomworld.com/vb/eternity/58281-eternity-engine-v3-40-20-mjolnir/ 3.40.20] "Mjolnir" - December 26, 2011
* [http://www.doomworld.com/vb/eternity/61245-eternity-engine-3-40-25-midgard/ 3.40.25] "Midgard" - August 27, 2012
* [http://www.doomworld.com/vb/eternity/62087-eternity-engine-3-40-30-alfheim/ 3.40.30] "Alfheim" - November 4, 2012
* [http://www.doomworld.com/vb/eternity/64382-eternity-engine-3-40-37-gungnir/ 3.40.37] "Gungnir" - May 27, 2013
* [http://www.doomworld.com/vb/eternity/67069-eternity-engine-3-40-46-bifrost/ 3.40.46] "Bifröst" - January 19, 2014 - ''first one with a macOS release''

===Version 3.42===
* [https://www.doomworld.com/forum/topic/94046-eternity-engine-34202-heimdal-files-documentation-buglist/ 3.42.02] "Heimdal" - May 7, 2017
* [https://www.doomworld.com/forum/topic/95351-eternity-engine-34203a-heimdal-release-2-hotfix/ 3.42.03a] "Heimdal" release 2 - August 2, 2017

===Version 4.00===
* [https://www.doomworld.com/forum/topic/99957-eternity-engine-40000-v%C3%B6lusp%C3%A1/ 4.00.00] "Völuspá" - March 17, 2018

===Version 4.01===
* [https://www.doomworld.com/forum/topic/117429-eternity-engine-40100-tyrfing/ 4.01.00] "Tyrfing" - October 13, 2020

===Version 4.02===
* [https://www.doomworld.com/forum/topic/119425-eternity-engine-40200-forseti/ 4.02.00] "Forseti" - January 27, 2021

===Version 4.04===
* [https://www.doomworld.com/forum/topic/148678-eternity-engine-40400-glitnir/ 4.04.00] "Glitnir" - October 12, 2024
* [https://www.doomworld.com/forum/topic/148678-eternity-engine-40401-glitnir-update-1/ 4.04.01] "Glitnir" Update 1 - October 20, 2024
* [https://www.doomworld.com/forum/topic/148678-eternity-engine-40402-glitnir-update-2/ 4.04.02] "Glitnir" Update 2 - November 18, 2024

===Version 4.05===
* [https://www.doomworld.com/forum/topic/154848-eternity-engine-40504-citadel/ 4.05.04] "Citadel" - August 23, 2025

===Version 4.06===
* [https://www.doomworld.com/forum/topic/158835-eternity-engine-40600-nidhogg/ 4.06.00] "Nidhogg" — June 13, 2026

==Cross-platform development==
Eternity is built by using the [[Wikipedia:CMake|CMake]] utility. You can download the Eternity [[Wikipedia:source code|source code]] from [[Wikipedia:GitHub|GitHub]] and execute CMake. Eternity's source code repository, as well as the latest releases, are located [https://github.com/team-eternity/eternity/ here].

==Development builds==
Development builds ("beta" releases) for Eternity are available for Windows and macOS at [http://devbuilds.drdteam.org/eternity/ DRDTeam's website]. They are recommended if you encounter serious bugs with any of the official releases, or if you want to test brand new features that didn't exist in the latest official releases. Due to their beta status, they may be untested and have other problems. However, due to the sometimes sporadic release cycles, it's often recommended to just try the development builds. The only problem is that by upgrading Eternity often, savegames tend to become unusable, so exercise caution before upgrading Eternity if you rely on games with saves.

==System features==
*[[Cardboard engine]]
*[[List of command line parameters]]
*[[Console]]
*[[List of cheat codes]]
*[[GFS|GFS files]]
*[[ZIP|ZIP mods]]

==Gameplay and modding features==
*[[DeHackEd / BEX Reference]]
*[[List of codepointers]]
*[[EDF|EDF files]]
*[[Editing reference]]
*[[OPTIONS|OPTIONS lump]]
*[[MapInfo]]
*[[SMMU|Features inherited from SMMU]]
*[[ExtraData]]
*[[Hexen format SNDINFO]]

[[Category:Source ports]]

Template:Latest

2026-06-13T21:03:16Z

Printz:

[https://www.doomworld.com/forum/topic/158835-eternity-engine-40600-nidhogg/ 4.06.00]

SectorSound

2026-05-31T15:05:36Z

Printz:

{{ACSFunction|description=Plays a sound at calling line's front sector.
|usage=''void'' '''SectorSound'''(''str sound'', ''int volume'')
|parameters=
* ''sound'': name of sound to play.
* ''volume'': volume of sound. Uses the same range as in other places sounds are used. The usual volume for Doom sounds is 127.
|notes=This function will only work if the script is called from a linedef.
|id=ACC internal
|seealso=
*[[ActivatorSound]]
*[[AmbientSound]]}}

IsTIDUsed

2026-05-10T10:20:00Z

Printz:

{{ACSFunction|description=Returns 1 if any thing with tag ''tid'' exists in the level.
|usage=''Boolean'' '''IsTIDUsed'''(''int'' ''tid'')
|parameters=
*''tid'': [[TID]] to check
|return=
'''TRUE''' if a thing with given TID exists.
|notes=It doesn't matter if such tagged things are dead or alive. This works for any special values for TID, so for example you can check if player 2 is present in the game by checking '''IsTIDUsed'''(-2). See the [[TID]] definition for details.
|id=-47
|seealso=
*[[UniqueTID]]}}

UniqueTID

2026-05-10T10:19:35Z

Printz:

{{ACSFunction|description=Returns a free TID to apply to new things.
|usage=''int'' '''UniqueTID'''([''int start''[, ''int limit'']])}
|parameters=
*''start'': optional start [[TID]] to count from
*''limit'': optional limit of retries
|return=New free TID to use, or 0 if it couldn't find one within limit.
|notes=If ''start'' is not provided, it will start by trying a random TID.

If attempted TID is currently in use, it will increment by up to ''limit'' tries, or keep looking if no limit. There's a limit of 32767 TIDs.
|id=-46
|seealso=
*[[IsTIDUsed]]}}

ACS built-in functions

2026-05-10T09:10:17Z

Printz: /* Scripts */

These are predefined ACS functions with no [[parameterized linedef specials|parameterized linedef special]] equivalents, accessible only through ACS scripts.

NOTE: most of these functions are meant to be compatible with those from ZDoom. For any ones not yet documented on this wiki, you can check the ZDoom wiki. A few of them may be incompletely implemented in Eternity. Don't hesitate to update the wiki in case of any mistakes.
==Special TID info==
For functions affecting things, some TIDs (thing tags) carry special meaning. TID 0 means the activator, and TIDs -1 ... -4 mean each of the four players in the game -- this is an Eternity extension
==Data type info==
You may see specifiers such as ''void'', ''str'', ''int'' and others in ACS function signatures. They act as a guide on what kinds of values are expected, but in ACS there really are only two types: '''str''' and '''int''' (and '''str''' internally is merely a string ID number). Most importantly:
*''void'' means that a function should be used as a procedure (command) without returning anything,
*''fixed'' means you can use the decimal point notation: 1.0 is equivalent to 65536, 1.5 to 98304 etc. In ACS, such values are still of '''int''' type, but whether you use the decimal point or not is quite relevant. A value such as 128.0 is ''not'' the same as 128: it's actually equal to 8388608 (no decimal point).
==Function list==
===Sound and music===
*[[ActivatorSound]]
*[[AmbientSound]]
*[[LocalAmbientSound]]
*[[PlayActorSound]]
*[[PlaySound]]
*[[SectorSound]]
*[[SetMusic]]
*[[LocalSetMusic]]
*[[SoundSequence]]
*[[SoundSequenceOnActor]]
*[[StopSound]]
*[[ThingSound]]

===Sectors===
{|class="wikitable sortable
! Name
! Description
|-
||[[ChangeCeiling]]||Changes the ceiling texture.
|-
||[[ChangeFloor]]||Changes the floor texture.
|-
||[[GetSectorCeilingZ]]||Gets the ceiling height.
|-
||[[GetSectorFloorZ]]||Gets the floor height.
|-
||[[GetSectorLightLevel]]||Gets the light level.
|-
||[[SectorDamage]]||Damages things in sector.
|-
||[[SetSectorDamage]]||Modifies the damaging floor status.
|-
||[[TagWait]]||Waits for sectors to stop movement.
|}

===Things===
*[[ActivatorTID]]
*[[ChangeActorAngle]]
*[[ChangeActorPitch]]
*[[CheckActorCeilingTexture]]
*[[CheckActorClass]]
*[[CheckActorFloorTexture]]
*[[CheckActorProperty]]
*bool [[CheckFlag]](int tid, str flag)
:Returns true if the first thing with the given tid has the given flag enabled.
*[[CheckProximity]]
*bool [[CheckSight]](int source, int dest, int flags)
:Returns true if there's a line of sight between at least one thing tagged as source and one thing tagged as dest. Currently flags is reserved and must be 0.
*int [[ClassifyActor]](int tid)
:Checks the kind of thing tagged tid. It returns a set of flags, possibly combined:
:*ACTOR_PLAYER (2): it's player-controlled
:*ACTOR_VOODOODOLL (8): it's a duplicate player start, not controlled by the player but still linked to it. Used in Boom maps for advanced mapping tricks
:*ACTOR_MONSTER (16): it's a monster (has COUNTKILL or KILLABLE thing type flag set)
:*ACTOR_MISSILE (128): it's a projectile in flight (has MISSILE thing type flag set)
:*ACTOR_GENERIC (256): neither a monster, nor a projectile
:*ACTOR_ALIVE (32): has positive health
:*ACTOR_DEAD (64): has health <= 0
:*ACTOR_NONE (0): no thing found with this TID
:*ACTOR_WORLD (1): TID is 0 but activator isn't a thing
*[[GetActorAngle]]
*[[GetActorCeilingZ]]
*[[GetActorFloorZ]]
*[[GetActorLightLevel]]
*[[GetActorPitch]]
*[[GetActorProperty]]
*[[GetActorVelX]]
*[[GetActorVelY]]
*[[GetActorVelZ]]
*[[GetActorX]]
*[[GetActorY]]
*[[GetActorZ]]
*[[IsTIDUsed]]
*[[SetActivator]]
*[[SetActivatorToTarget]]
*void [[SetActorAngle]] (int tid, fixed angle)
*[[SetActorVelocity]]
*void [[SetActorPitch]] (int tid, int pitch)
*[[SetActorPosition]]
*void [[SetThingSpecial]] (int tid, int special [, int arg0 [, int arg1 [, int arg2 [, int arg3 [, int arg4]]]]])
*int [[SetActorState]](int tid, str statename[, bool exact]);
*[[SetActorProperty]]
*int [[Spawn]] (str classname, fixed x, fixed y, fixed z [, int tid [, int angle]])
*int [[SpawnForced]] (str classname, fixed x, fixed y, fixed z [, int tid [, int angle]])
*[[SpawnProjectile]]
*[[SpawnSpot]]
*int [[SpawnSpotFacing]] (str classname, int spottid [, int tid])
*[[SpawnSpotFacingForced]]
*[[SpawnSpotForced]]
*int [[ThingCount]] (int type, int tid)
*int [[ThingCountName]] (str classname, int tid)
*int [[ThingCountSector]] (int type, int tid, int tag)
*int [[ThingCountNameSector]] (str classname, int tid, int tag)
*int [[Thing_Damage2]] (int tid, int amount, str type);
*void [[Thing_Projectile2]] (int tid, int type, int angle, int speed, int vspeed, int gravity, int newtid)
*int [[UniqueTID]] ([int tid[, int limit]])

===Player===
*[[CheckInventory]]
*[[CheckWeapon]]
*[[ClearInventory]]
*[[GetMaxInventory]]
*[[GetSigilPieces]]
*[[GetWeapon]]
*[[GiveInventory]]
*[[PlayerArmorPoints]]
*[[PlayerCount]]
*[[PlayerFrags]]
*[[PlayerHealth]]
*[[PlayerNumber]]
*[[SetWeapon]]
*[[TakeInventory]]
*[[UseInventory]]

===Linedefs and sidedefs===
{|class="wikitable sortable"
! zspecial.acs index
! Name
! Return type
! Parameters
! Description
|-
||internal|| [[ClearLineSpecial]] || nothing || nothing || Clears the trigger linedef's special.
|-
|| || [[GetLineRowOffset]] || || ||
|-
|| || [[GetLineX]] || || ||
|-
|| || [[GetLineY]] || || ||
|-
|| || [[LineSide]] || || ||
|-
|| || [[ReplaceTextures]] || nothing || str old_texture_name, str new_texture_name[, int flags] ||
|-
|| || [[SetLineBlocking]] || || ||
|-
||internal|| [[SetLineMonsterBlocking]] || || || Makes a linedef block or not block monsters.
|-
|| || [[SetLineActivation]] || nothing || int lineid, int activation[, int repeat] ||
|-
|| || [[SetLineSpecial]] || || ||
|-
|| || [[SetLineTexture]] || nothing || int line_id, int line_side, int sidedef_texture, str texture_name ||
|}

===Sky===
*[[SetSkyScrollSpeed]]

===Scripts===
Eternity allows referring to scripts by name. The following actions are available in Eternity:
*bool ACS_NamedExecuteAlways(str script, int map, int arg1, int arg2, int arg3)
:*Executes a named script, starting a new instance if one already exists. Returns true if successfully started.
*bool ACS_NamedExecute(str script, int map, int arg1, int arg2, int arg3)
:*Executes a named script. Returns true if successfully started.
*int ACS_NamedExecuteWithResult (string script, int s_arg1, int s_arg2, int s_arg3, int s_arg4)
*bool ACS_NamedSuspend (string script, int map)
*bool ACS_NamedTerminate (string script, int map)
They behave the same as the corresponding numbered linedef specials.

===Console===
*int [[GetCVar]] (str cvar)
*string [[GetCVarString]] (str cvar)
*int [[GetPlayerInput]] (int player, int input)

===Polyobjects===
*[[GetPolyobjX]]
*[[GetPolyobjY]]
*[[PolyWait]]
*[[SetPolyobjXY]]

===Quake===
*[[Radius_Quake2]]

===Math===
*[[Cos]]
*fixed [[FixedSqrt]] (fixed number)
*int [[Random]] (int min, int max)
*int [[Sqrt]] (int number)
*[[Sin]]
*[[VectorAngle]]
*int [[VectorLength]] (int x, int y)

===Strings===
*str StrLeft (str string, int length)
*str StrMid (str string, int start, int length)
*str StrRight (str string, int length)

===Level state===
*[[GameSkill]]
*[[GameType]]
*[[GetLevelInfo]]
*[[SetAirControl]]
*[[SetAirFriction]]
*[[SetGravity]]
*[[SinglePlayer]]
*[[Timer]]

==See also==
*[[Parameterized linedef specials]]

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

GetPlayerInput

2026-05-10T09:08:30Z

Printz: Created page with "{{ACSFunction|description=Gets information about a player's input. |usage=''int'' '''GetPlayerInput'''(''int player'', ''int type'') |parameters= *''player'': player index, from 0 to 3. Use -1 for activator. *''type'': one of the following: :*'''INPUT_OLDBUTTONS''' (0): unused, returns 0 :*'''INPUT_BUTTONS''' (1): will return a combination of the following flags: ::*'''BT_ATTACK''' (1): normal weapon attack ::*'''BT_USE''' (2): switch or door activation ::*'''BT_JUMP'''..."

{{ACSFunction|description=Gets information about a player's input.
|usage=''int'' '''GetPlayerInput'''(''int player'', ''int type'')
|parameters=
*''player'': player index, from 0 to 3. Use -1 for activator.
*''type'': one of the following:
:*'''INPUT_OLDBUTTONS''' (0): unused, returns 0
:*'''INPUT_BUTTONS''' (1): will return a combination of the following flags:
::*'''BT_ATTACK''' (1): normal weapon attack
::*'''BT_USE''' (2): switch or door activation
::*'''BT_JUMP''' (4): jump or attempting to jump
::*'''BT_ALTATTACK''' (32): secondary fire button
::*'''BT_RELOAD''' (64): weapon reload
::*'''BT_ZOOM''' (128): weapon view zoom
::*'''BT_USER1''' (2097152), '''BT_USER2''' (4194304), '''BT_USER3''' (8388608), '''BT_USER4''' (16777216): user-defined buttons
:*'''INPUT_PITCH''' (2): view pitch change (looking up or down)
:*'''INPUT_YAW''' (3): angle turn
:*'''INPUT_FORWARDMOVE''' (5): forward and backward move
:*'''INPUT_SIDEMOVE''' (6): strafing
:*'''INPUT_UPMOVE''' (7): flight (if available)
|return=The value for the given ''type''
|notes=In Eternity, there are also '''MODINPUT_...''' options, but they mean the same as the '''INPUT_...''' ones. Anything else will just return 0.
|id=ACC internal}}

ACS built-in functions

2026-05-10T09:00:56Z

Printz: /* Console */

These are predefined ACS functions with no [[parameterized linedef specials|parameterized linedef special]] equivalents, accessible only through ACS scripts.

NOTE: most of these functions are meant to be compatible with those from ZDoom. For any ones not yet documented on this wiki, you can check the ZDoom wiki. A few of them may be incompletely implemented in Eternity. Don't hesitate to update the wiki in case of any mistakes.
==Special TID info==
For functions affecting things, some TIDs (thing tags) carry special meaning. TID 0 means the activator, and TIDs -1 ... -4 mean each of the four players in the game -- this is an Eternity extension
==Data type info==
You may see specifiers such as ''void'', ''str'', ''int'' and others in ACS function signatures. They act as a guide on what kinds of values are expected, but in ACS there really are only two types: '''str''' and '''int''' (and '''str''' internally is merely a string ID number). Most importantly:
*''void'' means that a function should be used as a procedure (command) without returning anything,
*''fixed'' means you can use the decimal point notation: 1.0 is equivalent to 65536, 1.5 to 98304 etc. In ACS, such values are still of '''int''' type, but whether you use the decimal point or not is quite relevant. A value such as 128.0 is ''not'' the same as 128: it's actually equal to 8388608 (no decimal point).
==Function list==
===Sound and music===
*[[ActivatorSound]]
*[[AmbientSound]]
*[[LocalAmbientSound]]
*[[PlayActorSound]]
*[[PlaySound]]
*[[SectorSound]]
*[[SetMusic]]
*[[LocalSetMusic]]
*[[SoundSequence]]
*[[SoundSequenceOnActor]]
*[[StopSound]]
*[[ThingSound]]

===Sectors===
{|class="wikitable sortable
! Name
! Description
|-
||[[ChangeCeiling]]||Changes the ceiling texture.
|-
||[[ChangeFloor]]||Changes the floor texture.
|-
||[[GetSectorCeilingZ]]||Gets the ceiling height.
|-
||[[GetSectorFloorZ]]||Gets the floor height.
|-
||[[GetSectorLightLevel]]||Gets the light level.
|-
||[[SectorDamage]]||Damages things in sector.
|-
||[[SetSectorDamage]]||Modifies the damaging floor status.
|-
||[[TagWait]]||Waits for sectors to stop movement.
|}

===Things===
*[[ActivatorTID]]
*[[ChangeActorAngle]]
*[[ChangeActorPitch]]
*[[CheckActorCeilingTexture]]
*[[CheckActorClass]]
*[[CheckActorFloorTexture]]
*[[CheckActorProperty]]
*bool [[CheckFlag]](int tid, str flag)
:Returns true if the first thing with the given tid has the given flag enabled.
*[[CheckProximity]]
*bool [[CheckSight]](int source, int dest, int flags)
:Returns true if there's a line of sight between at least one thing tagged as source and one thing tagged as dest. Currently flags is reserved and must be 0.
*int [[ClassifyActor]](int tid)
:Checks the kind of thing tagged tid. It returns a set of flags, possibly combined:
:*ACTOR_PLAYER (2): it's player-controlled
:*ACTOR_VOODOODOLL (8): it's a duplicate player start, not controlled by the player but still linked to it. Used in Boom maps for advanced mapping tricks
:*ACTOR_MONSTER (16): it's a monster (has COUNTKILL or KILLABLE thing type flag set)
:*ACTOR_MISSILE (128): it's a projectile in flight (has MISSILE thing type flag set)
:*ACTOR_GENERIC (256): neither a monster, nor a projectile
:*ACTOR_ALIVE (32): has positive health
:*ACTOR_DEAD (64): has health <= 0
:*ACTOR_NONE (0): no thing found with this TID
:*ACTOR_WORLD (1): TID is 0 but activator isn't a thing
*[[GetActorAngle]]
*[[GetActorCeilingZ]]
*[[GetActorFloorZ]]
*[[GetActorLightLevel]]
*[[GetActorPitch]]
*[[GetActorProperty]]
*[[GetActorVelX]]
*[[GetActorVelY]]
*[[GetActorVelZ]]
*[[GetActorX]]
*[[GetActorY]]
*[[GetActorZ]]
*[[IsTIDUsed]]
*[[SetActivator]]
*[[SetActivatorToTarget]]
*void [[SetActorAngle]] (int tid, fixed angle)
*[[SetActorVelocity]]
*void [[SetActorPitch]] (int tid, int pitch)
*[[SetActorPosition]]
*void [[SetThingSpecial]] (int tid, int special [, int arg0 [, int arg1 [, int arg2 [, int arg3 [, int arg4]]]]])
*int [[SetActorState]](int tid, str statename[, bool exact]);
*[[SetActorProperty]]
*int [[Spawn]] (str classname, fixed x, fixed y, fixed z [, int tid [, int angle]])
*int [[SpawnForced]] (str classname, fixed x, fixed y, fixed z [, int tid [, int angle]])
*[[SpawnProjectile]]
*[[SpawnSpot]]
*int [[SpawnSpotFacing]] (str classname, int spottid [, int tid])
*[[SpawnSpotFacingForced]]
*[[SpawnSpotForced]]
*int [[ThingCount]] (int type, int tid)
*int [[ThingCountName]] (str classname, int tid)
*int [[ThingCountSector]] (int type, int tid, int tag)
*int [[ThingCountNameSector]] (str classname, int tid, int tag)
*int [[Thing_Damage2]] (int tid, int amount, str type);
*void [[Thing_Projectile2]] (int tid, int type, int angle, int speed, int vspeed, int gravity, int newtid)
*int [[UniqueTID]] ([int tid[, int limit]])

===Player===
*[[CheckInventory]]
*[[CheckWeapon]]
*[[ClearInventory]]
*[[GetMaxInventory]]
*[[GetSigilPieces]]
*[[GetWeapon]]
*[[GiveInventory]]
*[[PlayerArmorPoints]]
*[[PlayerCount]]
*[[PlayerFrags]]
*[[PlayerHealth]]
*[[PlayerNumber]]
*[[SetWeapon]]
*[[TakeInventory]]
*[[UseInventory]]

===Linedefs and sidedefs===
{|class="wikitable sortable"
! zspecial.acs index
! Name
! Return type
! Parameters
! Description
|-
||internal|| [[ClearLineSpecial]] || nothing || nothing || Clears the trigger linedef's special.
|-
|| || [[GetLineRowOffset]] || || ||
|-
|| || [[GetLineX]] || || ||
|-
|| || [[GetLineY]] || || ||
|-
|| || [[LineSide]] || || ||
|-
|| || [[ReplaceTextures]] || nothing || str old_texture_name, str new_texture_name[, int flags] ||
|-
|| || [[SetLineBlocking]] || || ||
|-
||internal|| [[SetLineMonsterBlocking]] || || || Makes a linedef block or not block monsters.
|-
|| || [[SetLineActivation]] || nothing || int lineid, int activation[, int repeat] ||
|-
|| || [[SetLineSpecial]] || || ||
|-
|| || [[SetLineTexture]] || nothing || int line_id, int line_side, int sidedef_texture, str texture_name ||
|}

===Sky===
*[[SetSkyScrollSpeed]]

===Scripts===
*bool ACS_NamedExecuteAlways(str script, int map, int arg1, int arg2, int arg3)
:*Executes a named script, starting a new instance if one already exists. Returns true if successfully started.
*bool ACS_NamedExecute(str script, int map, int arg1, int arg2, int arg3)
:*Executes a named script. Returns true if successfully started.
*int ACS_NamedExecuteWithResult (string script, int s_arg1, int s_arg2, int s_arg3, int s_arg4)
*bool ACS_NamedSuspend (string script, int map)
*bool ACS_NamedTerminate (string script, int map)

===Console===
*int [[GetCVar]] (str cvar)
*string [[GetCVarString]] (str cvar)
*int [[GetPlayerInput]] (int player, int input)

===Polyobjects===
*[[GetPolyobjX]]
*[[GetPolyobjY]]
*[[PolyWait]]
*[[SetPolyobjXY]]

===Quake===
*[[Radius_Quake2]]

===Math===
*[[Cos]]
*fixed [[FixedSqrt]] (fixed number)
*int [[Random]] (int min, int max)
*int [[Sqrt]] (int number)
*[[Sin]]
*[[VectorAngle]]
*int [[VectorLength]] (int x, int y)

===Strings===
*str StrLeft (str string, int length)
*str StrMid (str string, int start, int length)
*str StrRight (str string, int length)

===Level state===
*[[GameSkill]]
*[[GameType]]
*[[GetLevelInfo]]
*[[SetAirControl]]
*[[SetAirFriction]]
*[[SetGravity]]
*[[SinglePlayer]]
*[[Timer]]

==See also==
*[[Parameterized linedef specials]]

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

GetLevelInfo

2026-05-10T08:39:07Z

Printz:

{{ACSFunction|description=Gets various information from level.
|usage=''int'' '''GetLevelInfo'''(''int type'')
|parameters=
*''type'': one of the following:
:*'''LEVELINFO_PAR_TIME''' (0): par time, in seconds
:*'''LEVELINFO_CLUSTERNUM''' (1): episode index, in episode
:*'''LEVELINFO_LEVELNUM''' (2): level index, in episode
:*'''LEVELINFO_TOTAL_SECRETS''' (3): amount of secrets available in map
:*'''LEVELINFO_FOUND_SECRETS''' (4): total found secrets by all players
:*'''LEVELINFO_TOTAL_ITEMS''' (5): amount of [[MF_COUNTITEM]] items available in map
:*'''LEVELINFO_FOUND_ITEMS''' (6): total collected items by all players
:*'''LEVELINFO_TOTAL_MONSTERS''' (7): amount of monsters placed in map
:*'''LEVELINFO_KILLED_MONSTERS''' (8): total killed monsters, both by players and non-players
:*'''LEVELINFO_SUCK_TIME''' (9): level time in seconds after which the intermission will show "SUCKS".
|return=The needed property value
|id=ACC internal
}}

GetLevelInfo

2026-05-10T08:24:25Z

Printz: Created page with "{{ACSFunction|description=Gets various information from level. |usage=''int'' '''GetLevelInfo'''(''int type'') |parameters= *''type'': one of the following: :*'''LEVELINFO_PAR_TIME''' (0): par time, in seconds :*'''LEVELINFO_LEVELNUM''' (2): level index, in episode :*'''LEVELINFO_TOTAL_SECRETS''' (3): amount of secrets available in map :*'''LEVELINFO_FOUND_SECRETS''' (4): total found secrets by all players :*'''LEVELINFO_TOTAL_ITEMS''' (5): amount of MF_COUNTITEM ite..."

{{ACSFunction|description=Gets various information from level.
|usage=''int'' '''GetLevelInfo'''(''int type'')
|parameters=
*''type'': one of the following:
:*'''LEVELINFO_PAR_TIME''' (0): par time, in seconds
:*'''LEVELINFO_LEVELNUM''' (2): level index, in episode
:*'''LEVELINFO_TOTAL_SECRETS''' (3): amount of secrets available in map
:*'''LEVELINFO_FOUND_SECRETS''' (4): total found secrets by all players
:*'''LEVELINFO_TOTAL_ITEMS''' (5): amount of [[MF_COUNTITEM]] items available in map
:*'''LEVELINFO_FOUND_ITEMS''' (6): total collected items by all players
:*'''LEVELINFO_TOTAL_MONSTERS''' (7): amount of monsters placed in map
:*'''LEVELINFO_KILLED_MONSTERS''' (8): total killed monsters, both by players and non-players
|return=The needed property value
|id=ACC internal
}}

GetCVarString

2026-05-10T08:17:43Z

Printz: Redirected page to GetCVar

#REDIRECT [[GetCVar]]

GetCVar

2026-05-10T08:17:26Z

Printz:

{{ACSFunction|description=Get the value of an integer or string [[console variable]].
|usage=
''int'' '''GetCVar'''(''str cvar'')

''str'' '''GetCVarString'''(''str cvar'')
|parameters=
*''cvar'': console variable name
|return=The value of the console variable, or 0 if unauthorized or inexistent.
|notes=This only works with server variables affecting all players, otherwise it will display an error and return 0.
|id=ACC internal for '''GetCVar''', -56 for '''GetCVarString'''}}

GetCVar

2026-05-10T08:17:02Z

Printz: Created page with "{{ACSFunction|description=Get the value of an integer or string console variable. |usage= ''int'' '''GetCVar'''(''str cvar'') ''str'' '''GetCVarString'''(''str cvar'') |parameters= *''cvar'': console variable name |return=The value of the console variable, or 0 if unauthorized or inexistent. |notes=This only works with server variables, otherwise it will display an error and return 0. |id=ACC internal for '''GetCVar''', -56 for '''GetCVarString'''}}"

{{ACSFunction|description=Get the value of an integer or string [[console variable]].
|usage=
''int'' '''GetCVar'''(''str cvar'')

''str'' '''GetCVarString'''(''str cvar'')
|parameters=
*''cvar'': console variable name
|return=The value of the console variable, or 0 if unauthorized or inexistent.
|notes=This only works with server variables, otherwise it will display an error and return 0.
|id=ACC internal for '''GetCVar''', -56 for '''GetCVarString'''}}

ACS built-in functions

2026-05-10T07:14:53Z

Printz: /* Things */

These are predefined ACS functions with no [[parameterized linedef specials|parameterized linedef special]] equivalents, accessible only through ACS scripts.

NOTE: most of these functions are meant to be compatible with those from ZDoom. For any ones not yet documented on this wiki, you can check the ZDoom wiki. A few of them may be incompletely implemented in Eternity. Don't hesitate to update the wiki in case of any mistakes.
==Special TID info==
For functions affecting things, some TIDs (thing tags) carry special meaning. TID 0 means the activator, and TIDs -1 ... -4 mean each of the four players in the game -- this is an Eternity extension
==Data type info==
You may see specifiers such as ''void'', ''str'', ''int'' and others in ACS function signatures. They act as a guide on what kinds of values are expected, but in ACS there really are only two types: '''str''' and '''int''' (and '''str''' internally is merely a string ID number). Most importantly:
*''void'' means that a function should be used as a procedure (command) without returning anything,
*''fixed'' means you can use the decimal point notation: 1.0 is equivalent to 65536, 1.5 to 98304 etc. In ACS, such values are still of '''int''' type, but whether you use the decimal point or not is quite relevant. A value such as 128.0 is ''not'' the same as 128: it's actually equal to 8388608 (no decimal point).
==Function list==
===Sound and music===
*[[ActivatorSound]]
*[[AmbientSound]]
*[[LocalAmbientSound]]
*[[PlayActorSound]]
*[[PlaySound]]
*[[SectorSound]]
*[[SetMusic]]
*[[LocalSetMusic]]
*[[SoundSequence]]
*[[SoundSequenceOnActor]]
*[[StopSound]]
*[[ThingSound]]

===Sectors===
{|class="wikitable sortable
! Name
! Description
|-
||[[ChangeCeiling]]||Changes the ceiling texture.
|-
||[[ChangeFloor]]||Changes the floor texture.
|-
||[[GetSectorCeilingZ]]||Gets the ceiling height.
|-
||[[GetSectorFloorZ]]||Gets the floor height.
|-
||[[GetSectorLightLevel]]||Gets the light level.
|-
||[[SectorDamage]]||Damages things in sector.
|-
||[[SetSectorDamage]]||Modifies the damaging floor status.
|-
||[[TagWait]]||Waits for sectors to stop movement.
|}

===Things===
*[[ActivatorTID]]
*[[ChangeActorAngle]]
*[[ChangeActorPitch]]
*[[CheckActorCeilingTexture]]
*[[CheckActorClass]]
*[[CheckActorFloorTexture]]
*[[CheckActorProperty]]
*bool [[CheckFlag]](int tid, str flag)
:Returns true if the first thing with the given tid has the given flag enabled.
*[[CheckProximity]]
*bool [[CheckSight]](int source, int dest, int flags)
:Returns true if there's a line of sight between at least one thing tagged as source and one thing tagged as dest. Currently flags is reserved and must be 0.
*int [[ClassifyActor]](int tid)
:Checks the kind of thing tagged tid. It returns a set of flags, possibly combined:
:*ACTOR_PLAYER (2): it's player-controlled
:*ACTOR_VOODOODOLL (8): it's a duplicate player start, not controlled by the player but still linked to it. Used in Boom maps for advanced mapping tricks
:*ACTOR_MONSTER (16): it's a monster (has COUNTKILL or KILLABLE thing type flag set)
:*ACTOR_MISSILE (128): it's a projectile in flight (has MISSILE thing type flag set)
:*ACTOR_GENERIC (256): neither a monster, nor a projectile
:*ACTOR_ALIVE (32): has positive health
:*ACTOR_DEAD (64): has health <= 0
:*ACTOR_NONE (0): no thing found with this TID
:*ACTOR_WORLD (1): TID is 0 but activator isn't a thing
*[[GetActorAngle]]
*[[GetActorCeilingZ]]
*[[GetActorFloorZ]]
*[[GetActorLightLevel]]
*[[GetActorPitch]]
*[[GetActorProperty]]
*[[GetActorVelX]]
*[[GetActorVelY]]
*[[GetActorVelZ]]
*[[GetActorX]]
*[[GetActorY]]
*[[GetActorZ]]
*[[IsTIDUsed]]
*[[SetActivator]]
*[[SetActivatorToTarget]]
*void [[SetActorAngle]] (int tid, fixed angle)
*[[SetActorVelocity]]
*void [[SetActorPitch]] (int tid, int pitch)
*[[SetActorPosition]]
*void [[SetThingSpecial]] (int tid, int special [, int arg0 [, int arg1 [, int arg2 [, int arg3 [, int arg4]]]]])
*int [[SetActorState]](int tid, str statename[, bool exact]);
*[[SetActorProperty]]
*int [[Spawn]] (str classname, fixed x, fixed y, fixed z [, int tid [, int angle]])
*int [[SpawnForced]] (str classname, fixed x, fixed y, fixed z [, int tid [, int angle]])
*[[SpawnProjectile]]
*[[SpawnSpot]]
*int [[SpawnSpotFacing]] (str classname, int spottid [, int tid])
*[[SpawnSpotFacingForced]]
*[[SpawnSpotForced]]
*int [[ThingCount]] (int type, int tid)
*int [[ThingCountName]] (str classname, int tid)
*int [[ThingCountSector]] (int type, int tid, int tag)
*int [[ThingCountNameSector]] (str classname, int tid, int tag)
*int [[Thing_Damage2]] (int tid, int amount, str type);
*void [[Thing_Projectile2]] (int tid, int type, int angle, int speed, int vspeed, int gravity, int newtid)
*int [[UniqueTID]] ([int tid[, int limit]])

===Player===
*[[CheckInventory]]
*[[CheckWeapon]]
*[[ClearInventory]]
*[[GetMaxInventory]]
*[[GetSigilPieces]]
*[[GetWeapon]]
*[[GiveInventory]]
*[[PlayerArmorPoints]]
*[[PlayerCount]]
*[[PlayerFrags]]
*[[PlayerHealth]]
*[[PlayerNumber]]
*[[SetWeapon]]
*[[TakeInventory]]
*[[UseInventory]]

===Linedefs and sidedefs===
{|class="wikitable sortable"
! zspecial.acs index
! Name
! Return type
! Parameters
! Description
|-
||internal|| [[ClearLineSpecial]] || nothing || nothing || Clears the trigger linedef's special.
|-
|| || [[GetLineRowOffset]] || || ||
|-
|| || [[GetLineX]] || || ||
|-
|| || [[GetLineY]] || || ||
|-
|| || [[LineSide]] || || ||
|-
|| || [[ReplaceTextures]] || nothing || str old_texture_name, str new_texture_name[, int flags] ||
|-
|| || [[SetLineBlocking]] || || ||
|-
||internal|| [[SetLineMonsterBlocking]] || || || Makes a linedef block or not block monsters.
|-
|| || [[SetLineActivation]] || nothing || int lineid, int activation[, int repeat] ||
|-
|| || [[SetLineSpecial]] || || ||
|-
|| || [[SetLineTexture]] || nothing || int line_id, int line_side, int sidedef_texture, str texture_name ||
|}

===Sky===
*[[SetSkyScrollSpeed]]

===Scripts===
*bool ACS_NamedExecuteAlways(str script, int map, int arg1, int arg2, int arg3)
:*Executes a named script, starting a new instance if one already exists. Returns true if successfully started.
*bool ACS_NamedExecute(str script, int map, int arg1, int arg2, int arg3)
:*Executes a named script. Returns true if successfully started.
*int ACS_NamedExecuteWithResult (string script, int s_arg1, int s_arg2, int s_arg3, int s_arg4)
*bool ACS_NamedSuspend (string script, int map)
*bool ACS_NamedTerminate (string script, int map)

===Console===
*int [[GetCVar]] (str cvar)
*string [[GetCVarString]] (str cvar)
*int GetPlayerInput (int player, int input)

===Polyobjects===
*[[GetPolyobjX]]
*[[GetPolyobjY]]
*[[PolyWait]]
*[[SetPolyobjXY]]

===Quake===
*[[Radius_Quake2]]

===Math===
*[[Cos]]
*fixed [[FixedSqrt]] (fixed number)
*int [[Random]] (int min, int max)
*int [[Sqrt]] (int number)
*[[Sin]]
*[[VectorAngle]]
*int [[VectorLength]] (int x, int y)

===Strings===
*str StrLeft (str string, int length)
*str StrMid (str string, int start, int length)
*str StrRight (str string, int length)

===Level state===
*[[GameSkill]]
*[[GameType]]
*[[GetLevelInfo]]
*[[SetAirControl]]
*[[SetAirFriction]]
*[[SetGravity]]
*[[SinglePlayer]]
*[[Timer]]

==See also==
*[[Parameterized linedef specials]]

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

FixedSqrt

2026-05-10T07:14:14Z

Printz: Redirected page to Sqrt

#REDIRECT [[Sqrt]]