LDL Concept Release Tutorial
This document is about the preliminary LDL concept release. For the
latest information on LDL, which will be changing frequently at this
early stage, please visit .
Please help out Matthew's research by filling in the short survey on
your feelings about LDL, which is available at
. I need answers to these questions
by the start of May if possible (though up to and including the 4th
would be manageable). Please accept my apologies for the short notice
but it's been a very busy few months working on LDL and also applying
for funding for my work.
What is LDL?
The AGRIP *Level Description Language*, or LDL, is a language being
developed to allow people to easily describe 3D spaces. Currently the
description is written in a type of XML file, but later we aim to expand
to more natural language and also provide level-editing programs. LDL is
currently aimed at blind gamers who want to make maps for Quake. This is
a very preliminary concept release, so it's important to say what it
does, doesn't and will do (this will be discussed shortly).
Before LDL
How would one go about making maps for Quake before LDL? If you just
want to find out how to use LDL you can skip this section, however it
does provide useful background information on the area that we are now
working on providing access to.
1. Well first off you'd have to be able to see well enough to use a
graphical CAD-like program - a level/map editor - to draw the shapes
of your rooms on the screen.
2. The shapes you draw - brushes - would make up the rooms in the map.
It works like building blocks and you have to put many blocks
together to make a single room - one for the floor, ceiling and all
of the sides. If you wanted to put a hole in a wall (for a door, for
example), you would have to build the brushes around the space where
you wanted the hole to be.
Later editors alleviated the difficulties caused by this system and
made up "smart" brushes that automatically created the gaps for
holes (the editor used by the AGRIP project, QuArK, does this).
3. Textures would have to be applied to the brushes. Entities (weapons,
lights, monsters) would be added to the map to make it more
interesting. Doors and buttons are special entities that are
associated with a brush (that moves, for example, when you walk near
it).
4. When the map is finished it must be saved as a .map file so that the
level compilation tools can read it. The .map file is even
lower-level than many level editors' internal formats. It contains a
list of the brushes and entities in the map, but with the bushes
defined in terms of triples of points on the 3D planes that make
them up.
5. Finally the .map file can be compiled with the Quake map compilation
tools. These would be run as follows.
bsp mapname
This converts the textual description of planes and so on in the
text file to a binary format that can be read by the engine.
light mapname
This calculates all of the lighting values (more modern game
engines do some/all of this on-the-fly during game-play but
doing it as a pre-processing stage saves a lot of resource
requirement later on).
vis mapname
This helps the engine work out which parts of the map don't need
to be displayed depending on the viewpoint of the player, thus
saving the engine from having to draw everything in the map at
all times and speeding things up dramatically.
How Does LDL Work?
The operating principle of LDL is that we start with as high-level a
description as possible and gradually transform it, by filling in the
details, into a low-level description suitable for compiling with the
standard Quake map tools. This allows you to talk in terms of rooms and
connections between them, whereas the map tools at the bottom of the
chain want to know about scary things like intersecting 3D planes.
LDL - the code - is actually a chain as mentioned above. Each stage is a
separate program and the whole thing works by feeding the output of one
into the next, until we have our final answer - the .map file.
You start by writing a pretty high-level XML file that describes your
map (later we plan to add even easier ways to get data into the system,
such as natural language, or an interactive editor program but for now
we need to test the basic premise). An XML file is just a plain text
file (think similar to HTML if you've used that before), which you can
edit with any text editor (e.g. Notepad, Notepad++, ViM, ...)
The work-flow for using LDL is as follows.
1. Write your XML file with a text editor, as per the examples in the
tutorial section below.
2. Run the LDL tools on it (a script/batch file is provided to automate
this). They should be run from a terminal/command window.
The scripts will check that your XML file is "well-formed" before
going further. This means checking that you have typed it in without
mistakes such as unclosed tags.
If it doesn't work, there could be an error in your XML file (or a
bug in the LDL code, which we implore you to report!) Go back to the
XML, try to fix the problem (error messages will try to help you do
this) and try again.
If/when it does work, you will then be able to play the map in
AudioQuake.
What Does the LDL Test Release Do?
The test release is focused on describing the spaces and making simple
deathmatch maps. It does the following.
* Allows you to describe rooms - their size and style (which causes
texturing and lighting to be automatically applied so that sighted
people can play your maps too).
* Allows you to specify how rooms are connected (directly) to each
other - i.e. you can specify that a given room is positioned north
of another room and that there should be a door between them and
both rooms will be positioned correctly - including at the right
height - and the door - and any required stairs or an elevation
platform - inserted.
* Placement of items within rooms (such as player start points and
weapons) on a compass directions system (this is planned to be
expanded into percentage-based coordinates in the future).
What Does it *Not* do?
* It can't make connections between rooms that are not next to each
other - that is to say you need to specify the corridors that
connect between rooms (as rooms themselves, which they are - they're
usually just longer and thinner).
Supported, Planned and Blue Sky Features
The lower levels of LDL support many features, not all of which are
currently enabled. The test release is designed mainly to assess how
well the tool works as a way to allow blind people to specify 3D spaces,
so doesn't contain all of the features of regular Quake, but we will be
adding many (and fixing reported bugs) quickly over the coming weeks and
months.
Some features are planned for future releases of LDL, as follows.
* Higher-level descriptions - giving you the ability to say roughly
where some rooms are in 3D space and the programs working out the
best way to link them (i.e. with corridors, stairs or lifts).
* Providing a natural language-like interface.
* Providing a level editor application to make writing the
descriptions and make error-checking easier.
Some limitations of the system that may be addressed in future include
the inability of it to cope with angled/slanted brushes. This isn't so
much of a limitation at the moment as we can use stairs and so on - and
are not aware of the best way to present such complex structures. Once
we've done more research into how to navigate such maps and how to
represent them in LDL this may be an area of improvement.
For now, however, there's a great deal you *can* do - as we hope the
tutorial below will show.
Getting LDL
Requirements
LDL currently runs on Linux and Windows, with plans to support MacOS X
as soon as possible. To make it run, you will need Python 2.5. If you're
on Linux this should be as easy as
apt-get install python2.5
or similar. On Windows, you should get the Windows Installer package
from and install
it.
Getting LDL
The test release is available from . It
contains the LDL map translation scripts and Quake map compilation
tools.
Running LDL
Here are the (brief) instructions for setting up LDL on your system.
...on Linux
There are no restrictions on where you should unpack the zip file and
run the scripts from. However, you'll need to copy the Quake map
compilation tools (qbsp, light and vis) to somewhere on your path (such
as /usr/local/bin/ or ~/bin/ if it's on your path).
To test your installation, open a terminal and issue the following
commands.
cd ~/.zquake/ldl/
./mkmap.sh tut08
...on Windows
When you've installed Python 2.5 and downloaded the test release, please
unzip it into your AudioQuake directory, so that the ldl/ folder is
inside your AudioQuake folder, alongside id1/.
To test your installation, open a command prompt and issue the following
commands.
cd "C:\Program Files\AudioQuake\ldl\"
mkmap tut08
Once this command has completed, issue the following command to test the
map.
test tut08
Expected Test Results
This should (a) transform the XML into a .map file using the LDL
scripts, then (b) compile the map using the quake map tools and (c) run
it using AudioQuake.
If this is not what happens, consult and
the AGRIP-discuss mailing list for help -
. Any
error messages will be output to the command window for you to read and
submit as part of your email to the mailing list. If you are working on
your own map, it's also a good idea to send in your XML file so we can
see if there are any errors in it.
Making Maps with LDL
This section is a tutorial on making levels with LDL. It assumes you've
followed the set-up instructions above and that the system is working.
Basic Concepts
Before you start, please be aware of the following.
* LDL maps are XML files (which are plain text files and look similar
to HTML files). You can edit them with any text editor. You should
be able to copy and paste from this document into a text file - name
it something like tutorial.xml and run it through the LDL system in
a terminal/command window, as above.
If you are new to XML don't worry - you can copy the examples given
here. Also, there is a tutorial on XML at
.
* When you run the LDL scripts on a map, you should not include the
.xml part of the map's name.
* It is strongly recommended that you compile and test the map as you
go along with writing it as often as you can do so. This will help
you appreciate how the system works and help you to determine when
an error in your map (or bug in our code) has been introduced.
The LDL scripts will point out errors in the XML file such as
unclosed tags. These need to be fixed before you can continue (an
example is given below).
* Unless you add enough deathmatch player start points, you will have
great problems running the map in deathmatch mode, as all of the
bots will try to spawn out of one start point. You'll read later how
to add start points.
For now, be aware that the map test script/batch file is provided so
that you can test your maps in non-deathmatch mode. For that to
work, you have to have one - and only one - info_player_start entity
in your map. Again, more on this later.
Hello, World!
Let's start with a very simple example map.
That's the simplest map you can make with LDL that can be played. Let's
take a look at each line and see what it does...
.
Back to the map file...
This and the following 2 lines represent a room and its contents. Note
that you must always close elements, just like any other.
The room has been given an *id* so that LDL can uniquely identify it
later. You must supply an ID for all rooms in your map. We didn't bother
to specify a size for it, so it will default to being "medium" in size
in all 3 directions - width, depth and height.
This room contains one *item* - a player start point which, according to
its "pos" attribute, is to be positioned in the centre of its containing
room. The item itself does not contain anything (this wouldn't make much
sense) so it can be closed simply by writing a forward slash before the
closing angle bracket. This is the same as if we had written it out in
full, as follows.
We close the room element because we have no more items to add.
Finally we have got to the end of the map file so we can close the map
element.
Try running this map through the LDL system. As part of the conversion
to a .map file (which will be converted by the standard Quake mapping
tools to a .bsp) the level will be textured and lit appropriately for
the style chosen above. Save the XML as tut01.xml and convert, compile
and test the map with, if you're using Linux:
./mkmap.sh tut01
or, in Windows:
mkmap tut01
test tut01
Remember to just type the part of the filename before the .xml
extension. Once the LDL scripts have run and the Quake map tools have
finished processing, the game will start and you should be in a
medium-sized room with not much else going on.
Room Sizes
When you don't specify a size for the room, it's made "medium" by
default. Let's try specifying a different size for the room. Here's the
whole map, with the size altered.
Try saving it and running it. You should find that you can walk much
further in any direction before hitting the walls.
There are several room sizes: vsmall, small, med, big, large, vlarge,
xlarge, huge, vhuge and xhuge.
If you were to specify a size that is not valid, you would get an error
message. Try that now, with the following input.
Because the room is a 3D object, you can also specify its size in the 3
dimensions - width, depth and height. Different programs and systems use
these terms differently, so to avoid any possible confusion, we'll
define them as LDL uses them here.
width
is, if you are stood inside the room facing north (which is how you
start off), the size of the room from left to right.
depth
is the distance from back to front
height
is the distance from floor to ceiling.
When you only give one word for the size, LDL will work out an
appropriate 3D room size based on the one given. If you want more
control, though, you'll need to specify all three (note that you can't
specify just 2 of the 3 dimensions - in that case, LDL could not know
which 2 of the 3 you were referring to).
Try making the room into a corridor - copy and paste the following into
a file, then save, compile and test it.
You will spawn in the middle of a thin, but long, corridor-shaped room.
Try strafing left/right and notice you hit the walls almost immediately.
Then try going back and forward.
One last thing to note about room sizes in LDL is that the sizes in the
width and depth dimensions have been designed to increase more quickly
than in height - that is to say that a room with the size "med" (which
is the same as "med med med") will be wider and deeper than it is tall.
It will be as wide as it is deep but it won't be quite as high. This is
because in most Quake maps, as with most buildings, rooms are not
completely cube-shaped. This feature is designed to make it easy for you
to make realistically-sized rooms even when you only specify one word
for the size attribute.
If you really really want to make your room exactly cube-shaped, you can
- use any of the following for your room's size attribute "vsmall vsmall
small", "small small big", "med med vlarge", "big big xlarge", "large
large huge", "xlarge xlarge vhuge" or "huge huge xhuge".
XML Errors
We will now purposely introduce an error into the file, so that you can
experience the effects and the solution, which will hopefully help you
fix errors in your own maps, should they occur. Because XML files are
very structured in nature, in our case with rooms inside maps and items
inside rooms, they are sensitive to errors such as omitted information.
In the example above we have a ) before it finds the end of the room.
Try removing the closing room tag () and run LDL on the map as
usual. You will get an error such as the following.
Stage 05 ERROR! The XML you supplied is not valid: mismatched tag: line 4, column 3
This is saying that on what is now line 4 of the map file, there was an
unexpected tag. Line 4 used to be "" but now it is "". This
means that the computer was expecting something other than ""
which was, in this case the closing room tag "". The computer
complains because it doesn't make sense structurally to put the marker
that says "that's the end of the entire map" inside one of the rooms!
Naturally you can fix the error by reintroducing the expected
tag.
A similar thing would have happened if you had changed the - line,
from
to
-
Now we've just got the start of the item tag. What the computer reads
next it will assume is meant to be insie the item (which doesn't make
any sense to us of course, as items, like weapons, spawn points or
powerups can't actually contain anything). On reading the tag,
the computer will realise there is a problem as the thing we've
effectively tried to put inside the item is the end of the room! Clearly
there has been an error (we know this to be a missing
or a
missing "/" before the end of the - tag) but the computer doesn't
have the brains to work out what that error is, so it will just tell you
about it.
So, if you ever get such errors on your own maps, you now know what they
mean. If you want help in fixing them, please mail the AGRIP-discuss
list.
Connecting Rooms
Now to make the map a bit more interesting! We will create two rooms and
link them.
There are now 2 rooms, "start" and "other", which are linked by a door.
LDL places the room "other" to the north of "start" because we asked the
connection to "other" to be made via the north wall ("n") of "start".
The north wall is the one you face when spawning in the map for the
first time; west and east correspond to left and right respectively and
south is behind you.
This is the same as the way directions work in most Interactive Fiction
games. If it helps, you could imagine being above the map and looking
down on it as if it was an, erm, map. Then, north would be to the top,
south to the bottom, west to the left and east to the right. (Both ways
of imagining the situation are the same - hopefully at least one will be
helpful.)
Above we specified the connection inside the room "start". It works the
other way around too, so that was exactly the same as if we had said the
following instead.
Run the map through LDL and experiment. The room you start in will lead
onto another room, which you will access via a door that is directly in
front of you when you start (LDL places doors in the middle of the wall
they're on and at ground level by default - more on this later).
Items and Monsters
Let's make the last map a little more interesting. We'll move the player
start point to the south end of the start room, add a shiny weapon for
you to pick up and, in the northern room, place a monster for you to use
it on.
As this map is in the medieval style, you may have noticed the door
making a different sound when it opened. The texturing and lighting of
the level will also be different and more appropriate to the medieval
style (meaning that sighted games might like to play your map too).
Compass Points
Currently the way to specify the location of items within rooms is to
use compass points. When you specify the location of an item, it works
in a similar way to connections above.
We plan to implement other ways to specify locations soon but, for now,
you can specify the following points: "nw" (north-west); "n" (north);
"ne" (north-east); "e" (east); "se" (south-east); "sw" (south-west); "w"
(west) and "c" (centre).
Currently we don't provide a mechanism to control at what height within
the room that items will be placed; this will be added later.
Making Deathmatch-Suitable Maps
So far we have made some simple maps that are designed for the
single-player version of the game. Single-player maps have one
"info_player_start". Deathmatch maps require many
"info_player_deathmatch" spawn points. If you only have one
"info_player_deathmatch", all of the bots and clients will spawn from
that one point and keep telefragging each other, causing the level to be
over quite quickly! Let's make a very simple deathmatch level, suitable
for a small number of players. This time, we'll construct the map step
by step before giving the whole XML file that you can copy and paste.
Let's make our map have one large central room that is surrounded by
four smaller rooms, which will contain the spawn points. One of those
rooms can also contain an "info_player_start" so we can test the level
in single-player mode without being fragged by bots. It's safe to put
both of these on the same spot in your map as only one would ever be
used at a given time (the "info_player_start" if we're in single-player
mode, or the "info_player_deathmatch" otherwise).
The basics of the central room may be something like this
Each surrounding room may be something like this
We need to give each of these rooms a unique ID attribute, however, so
we may as well name them partly after the compass points, as we'll be
using those to place them around the outside of the central room. So,
our side room IDs will be "spawn_south", "spawn_north", "spawn_east" and
"spawn_west". We'll put our "info_player_start" in the southern one, so
it will look more like this:
Note that we've also added some rockets for the player as no ammo was
given in the main room above. To make it easy for the player to pick up
the rockets, we've put them in the north of this room (which is on the
way from the centre of this spawn room to the main room, because the
main spawn room is to the north of the southern spawn room).
We'll need to list the connections to the spawn rooms in the main room's
definition. These will be as follows and can be placed anywhere between
the opening and closing tags for the central room.
We've got the basics of a deathmatch map covered, but before we compile
it, we need to consider one last thing: the direction the player faces
when spawning. We have positioned spawn rooms around a central room. By
default the player will spawn facing north. This is fine if they spawn
in the southern room because they'd spawn facing the door that leads
onto the main room. However, when the player spawns in one of the other
side rooms, they will be facing the wrong way. To correct this, we can
supply an "angle" attribute for the spawn points.
For example: consider the westerly spawn room. This is positioned to the
west of the main room so if someone spawns there they'll need to move to
the east to get out of the spawn room and into the main room. In that
case, we can make their life easier by writing the spawn point in the
west room as follows.
This ensures that when the player spawns there they'll be facing east
and thus be able to walk straight forward into the main room.
Now we've discussed all the parts of the map we need, here is the full
version of it, which you can paste in and try for yourself.
When you run the normal LDL compilation and test scripts on this map,
you'll be in single-player mode and can walk around and test the shape
of the map as normal. To play in deathmatch mode, issue the following
console commands.
deathmatch 1
kill
Hopefully you have now had a pleasant deathmatch experience in your own
map!
Directional Issues
Up until AudioQuake 0.3.0.1, there was a bug that caused the direction
the player faced when spawning to always be labelled as "north". This
has now been alleviated and thus if you upgrade your AudioQuake
installation, you will be able to use LDL with it and not have this
problem. Maps made with LDL will still work fine on older versionos of
AudioQuake, but there may well be some confusion with directions. It is
best to at least test your maps on at least version 0.3.0.1 of
AudioQuake for this reason.
Co-Operative Maps
These are similar to deathmatch maps in that you need to include more
than one spawn point. However, the spawn points are usually situated
together at the "start" of the map and must be of type
"info_player_coop" (you can have as many as you like).
Remember, to play a co-op map, set the console variables as follows.
deathmatch 0
coop 1
map mapname
Connections Reloaded
We'll now revisit our previous example of two connected rooms. So far
we're able to specify that two rooms are linked by making a connection
from one to another, which may be in the form of a door or just a hole
in the connecting wall. By default the connection is made in the middle
of the wall at floor level.
To make things a bit more exciting, however, you might want to make some
rooms have different heights relative to each other. Here's a quick
example.
This is very similar to the example above (tut05), however, we have
added two attributes to the connection from the room "start" to the room
"other". These are:
pos This is the position *on the connecting wall* that you want the
hole/door to be created. That is to say: when you specify a position
- "top" (t) in this case - you are specifying the position on that
wall where you want the hole to be made, as if you were standing in
front of the wall itself.
Valid positions are: "tl" (top left), "t" (top centre), "tr" (top
right), "r" (right), "br" (bottom right), "b" (bottom centre - which
is the default), "bl" (bottom left) and "c" (centre).
elevtype
When you specify that the connecting hole/door is to be placed
somewhere other than at ground level on the wall, it might be
necessary to provide some means for the player to access the hole -
i.e. stairs or a plat (lifting platform). You will be warned when
this may be necessary, but as it's a design decision and you may not
wish the player to be granted access through this route, you can
specify "none" to disable the creation of such a device.
Try running this map - walk straight forward and you will find some
stairs. Carry on and you'll go up into the second room.
If you'd like to try a plat instead of stairs, change the value of the
"elevtype" attribute for the connection to "plat" and try the map again.
Even More Positioning
Try changing the "pos" to "tl" from "t" and you'll find that you have to
move to the left/west to find the stairs up to room "other".
It is important to note that even when you use the "pos" attribute to
change the position on the wall in the "start" room, you still always
end up in "other" at the same place - the connection on that side is
made in the default place of the middle of the connecting wall, at
ground level.
Once you're happy with this, you might be asking how you can reposition
the connector on the target room's side. The answer is that you can.
Let's take the example above and change it so that both rooms are
actually at the same height but the door between them is at the top of
the wall. Stairs will be built to get up to and down from the door on
both sides.
Making Connection Corridors
Say you have two rooms, at different heights and you want to make a
connection between them, in the form of a corridor with stairs in it.
This is an example of how you might go about doing so.
We have two rooms - "start" and "other" as ever. We will position
"other" to the north of "start", also as ever. This time, though, we
will place a corridor between the two. The corridor will be not very
wide, quite long and quite tall so that it can accommodate the change in
height from "start" to "other".
As the corridor will be connecting "start" and "other" we'll give it the
ID "start2other". This quickly identifies it as a corridor. Here is the
map...
When you enter this map, you'll find a door in front of you and then a
corridor, which has a set of steps at the end that lead (without a door)
into a room with the rocket launcher.
But those steps are very steep and - as you're using the entirety of
start2other as a corridor - it would be much better if those steps
filled the whole room rather than just a small part of it. You can make
this happen, as follows...
We've added an attribute, "extent", to the connection and given it the
size "+". That should be read as "fill all available space". Try making
this change and running the map - the stairs will take up all of the
available space in the corridor but not above the height they're meant
to be).
You can specify sizes ("small", "med" and so on) in the "extent"
attribute, as you can with rooms. You can also mix and match, so saying
"extent='+ med'" means "take up all available width, but be only
medium-sized in depth". Bear in mind that if the corridor was going from
east to west (or vice-verse) these would be reversed (which is why it's
often easier to just use "+" as the size specifier).
Vertical Connections to Other Rooms
It is possible for you to position one room entirely on top of or
underneath another and link them with connections as discussed earlier,
though you'd use "u" (up) and "d" (down) to identify the walls the
connections lie on. Currently it is not possible to make elevation
devices for these connections (e.g. a plat) but this is under
development and will be released soon.
We're also working on implementing teleporters, so you can move between
rooms instantaneously.
Feedback
This has been a tutorial of the LDL system's concept release. There is a
lot more to do and a lot of feedback to collect on how it is going so
far! If you need more information, please consult
and the AGRIP-discuss mailing list -
.
Please, if you can, help Matthew in his research and us in building a
great level-editing system for you by providing constructive criticism
of the system. Bear in mind the stage we're at and let us know what
direction it should take in future.
Please also feel free to send us your maps (in XML form) - we'd love to
play them!
Some Golden Rules
* Always write well-formed XML. This means closing tags and quotes
properly, or you will get a "parse error".
* Maps must only contain one element.
* Rooms must all have a unique "id" attribute.
* Connections between rooms are seen as if we're looking down onto the
map, as in Interactive Fiction games. We use compass directions like
"e" (east) to say that, when we are in room A and room B is to the
east, we must turn to the right.
If a room is on top of, or underneath another room, we use the
directions "u" (up) and "d" (down).
* We place items in rooms according to the same compass direction
scheme.
* When assigning sizes to things like rooms, we may say "large" or, if
we want to be more precise, specify the size in each of the 3
dimensions of width, depth and height, separated by spaces - e.g.
"medium large medium". When facing north in a room, its width is the
distance from your left to your right; its depth is the distance
from back to front and its height is vertical distance between its
floor and ceiling.
Test Maps Included with LDL
The tutorial files (tut*.xml are also provided for your reference.
The test maps (test_nn_*.xml files) included with LDL provide some
examples on how to use the system. The number in the name indicates
which level of the system the map is written for. You will only be
interested in level 05 maps because the lower levels rely on absolute
coordinates and are there only to allow the higher levels to be simpler
(and will not work with the mkmap script).
The End
This has been a tutorial of the LDL system's concept release. There is a
lot more to do and a lot of feedback to collect on how it is going so
far! If you need more information, please consult
and the AGRIP-discuss mailing list -
.
Please, if you can, help Matthew in his research and us in building a
great level-editing system for you by providing constructive criticism
of the system. Bear in mind the stage we're at and let us know what
direction it should take in future.
Please also feel free to send us your maps (in XML form) - we'd love to
play them!
Reference Information
The Style File - Automating Texturing and Lighting
One helpful feature of LDL is that it automates the process of texturing
and lighting a map. This often tedious stage involves applying
appropriate pictures to the walls of the brushes (solid shapes) in the
map and also adding light entities in the right places to create the
desired "look". Though LDL cannot compete with a sighted human on
artistic grounds, it goes a long way and provides somewhat atmospheric
lighting for sighted players.
The file style.xml included with LDL contains information on the
textures and lighting. It will be document more fully in the coming
releases.
List of Valid Entities
This list is available on most Quake mapping websites, such as "Quake
MAP Specs".
Please note that most, but not all, entities are supported by the
current release of LDL. We will be adding support for the rest quickly
as time goes on and according to user demand.
air_bubbles
Rising bubbles
ambient_drip
Dripping sound
ambient_drone
Engine/machinery sound
ambient_comp_hum
Computer background sounds
ambient_flouro_buzz
Flourescent buzzing sound
ambient_light_buzz
Buzzing sound from light
ambient_suck_wind
Wind sound
ambient_swamp1
Frogs croaking
ambient_swamp2
Slightly different sounding frogs croaking
ambient_thunder
Thunder sound
event_lightning
Lightning (Used to kill Cthon, shareware boss)
func_door
Door
func_door_secret
A door that is triggered to open
func_wall
A moving wall?
func_button
A button
func_train
A platform (moves along a "train")
func_plat
A lift/elevator
func_dm_only
A teleporter that only appears in deathmatch
func_illusionary
Creates brush that appears solid, but isn't.
info_null
Used as a placeholder (removes itself)
info_notnull
Used as a placeholder (does not remove itself)
info_intermission
Cameras positioning for intermission (?)
info_player_start
Main player starting point (only one allowed)
info_player_deathmatch
A deathmatch start (more than one allowed)
info_player_coop
A coop player start (more than one allowed)
info_player_start2
Return point from episode
info_teleport_destination
Gives coords for a teleport destination using a targetname
item_cells
Ammo for the Thunderbolt
item_rockets
Ammo for Rocket/Grenade Launcher
item_shells
Ammo for both Shotgun and SuperShotgun
item_spikes
Ammo for Perforator and Super Perforator
item_weapon
Generic weapon class
item_health
Medkit
item_artifact_envirosuit
Environmental Protection Suit
item_artifact_super_damage
Quad Damage
item_artifact_invulnerability
Pentagram of Protection
item_artifact_invisibility
Ring of Shadows (Invisibility)
item_armorInv
Red armor
item_armor2
Yellow armor
item_armor1
Green armor
item_key1
Silver Key
item_key2
Gold Key
item_sigil
Sigil (a rune)
light
A projected light. No visible lightsource.
light_torch_small_walltorch
Small wall torch (gives off light)
light_flame_large_yellow
Large yellow fire (gives off light)
light_flame_small_yellow
Small yellow fire (gives off light)
light_flame_small_white
Small white fire (gives off light)
light_fluoro
Fluorescent light? (Gives off light, humming sound?)
light_fluorospark
Fluorescent light? (Gives off light, makes sparking sound)
light_globe
Light that appears as a globe sprite
monster_army
Grunt
monster_dog
Attack dog
monster_ogre
Ogre
monster_ogre_marksman
Ogre (synonymous with monster_ogre)
monster_knight
Knight
monster_zombie
Zombie
monster_wizard
Scragg (Wizard)
monster_demon1
Fiend (Demon)
monster_shambler
Shambler
monster_boss
Cthon (Boss of Shareware Quake)
monster_enforcer
Enforcer
monster_hell_knight
Hell Knight
monster_shalrath
Shalrath
monster_tarbaby
Slime
monster_fish
Fish
monster_oldone
Shubb-Niggurath (requires a misc_teleportrain and a
info_intermission)
misc_fireball
Small fireball (gives off light, harms player)
misc_explobox
Large Nuclear Container
misc_explobox2
Small Nuclear Container
misc_teleporttrain
Spiked ball needed to telefrag monster_oldone
path_corner
Used to define path of func_train platforms
trap_spikeshooter
Shoots spikes (nails)
trap_shooter
Fires nails without needing to be triggered.
trigger_teleport
Teleport (all trigger_ tags are triggered by walkover)
trigger_changelevel
Changes to another level
trigger_setskill
Changes skill level
trigger_counter
Triggers action after it has been triggered count times.
trigger_once
Triggers action only once
trigger_multiple
Triggers action (can be retriggered)
trigger_onlyregistered
Triggers only if game is registered (registered == 1)
trigger_secret
Triggers action and awards secret credit.
trigger_monsterjump
Causes triggering monster to jump in a direction
trigger_relay
Allows delayed/multiple actions from one trigger
trigger_push
Pushes a player in a direction (like a windtunnel)
trigger_hurt
Hurts whatever touches the trigger
weapon_supershotgun
Super Shotgun
weapon_nailgun
Perforator
weapon_supernailgun
Super Perforator
weapon_grenadelauncher
Grenade Launcher
weapon_rocketlauncher
Rocket Launcher
weapon_lightning
Lightning Gun