From a9022b5972dc49d86f617a27940fafe9c4d0e7e7 Mon Sep 17 00:00:00 2001 From: Ian C Date: Thu, 9 Jun 2011 13:46:28 +0000 Subject: Initial import of (very old) vidoom sources. --- doc/overview.htm | 1164 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1164 insertions(+) create mode 100644 doc/overview.htm (limited to 'doc/overview.htm') diff --git a/doc/overview.htm b/doc/overview.htm new file mode 100644 index 0000000..aeec434 --- /dev/null +++ b/doc/overview.htm @@ -0,0 +1,1164 @@ + + + + +viDOOM - Free Software DOOM editor + + + + +

viDOOM Overview

+ + + +
+ +

Introduction

+ +

viDOOM is a Free Software DOOM editor. It supports the +following id produced +games:

+ + + +

Note that in accordance with id software's wishes you are only +allowed to generate edited levels for the game if you have a +full, registered version of the game.

+ +

viDOOM is fully configurable through config files, so it can +be expanded to accommodate the BOOM and ZDOOM extensions. Well, +once I've found out the slight difference in format of WAD file +that seems to accompany them too.

+ +
+ +

Why bother?

+ +

Good question. Anyone who has ever used them will know there +are a number of very good DOOM editors available (links to lots +of them can be found at Doomworld +and all good FTP servers).

+ +

However, I always felt a bit clumsy using them, and in true +hacker fashion I decided writing one I could use would be easier +then reading the instructions for the others. Hence viDOOM.

+ +

I reasonably like the way viDOOM works, so I release it on the +off chance other people may too.

+ +
+ +

Supported systems

+ +

As with most Free Software viDOOM is primarily distributed as +source code. The source is fairly ANSI C compliant, and therefore +the core of viDOOM should compile on all operating systems. The +current distribution includes the hardware dependent routines for +the following platforms:

+ + + +
+ +

Environment

+ +

If defined in the environment, the value of VIDOOM_DIR +will be made the current directory as soon as viDOOM starts. This +is important as the following initialisation files are expected +to be in the current directory when viDOOM starts.

+ +

Note:
+How this environment is set will differ from system. Basically +viDOOM just calls the C library getenv() function. So,. +for instance in a Unix type system this could be:

+ +
+

% setenv VIDOOM_DIR $HOME/viDOOM
+ or
+ % export VIDOOM_DIR=$HOME/viDOOM

+
+ +

Whereas in DOS/DJGPP version this could be:

+ +
+

C:\> set VIDOOM_DIR=C:\viDOOM

+
+ +
+ +

Initialisation File - VIDOOM.INI

+ +

On starting viDOOM will look for a file in the current +directory called vidoom.ini. This file tells viDOOM what +version of DOOM it is expected to be editing, the configuration +for that version of DOOM and the editor configuration. The +general format of the INI file is:

+ +

[Section]
+identifier=value
+

+ +

Blank lines and lines starting with a comment character (#) +are ignored. The following sections and identifiers are explained +below.

+ + + +

After reading VIDOOM.INI, then a defined config file is also read.

+ +
+ +

[Game]

+ +

Controls for the version of DOOM

+ + + + + + + + + + +
gameUse this to say which version of DOOM + you will be editing. The following values are allowed:
    +
  • Doom
    • +
  • Ultimate Doom
    • +
  • Doom 2
    • +
  • TNT: Evilution
    • +
  • Plutonia Experiment
    • +
  • ZDoom
    • +
+
askIf set to yes then on starting viDOOM will ask + for the game type to edit.
+ +
+ +

[Editor]

+ +

Global editor configuration

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ask_middle_on_2sidedWhen creating a new sector and the + sector has a two-sided boundary asks whether a middle + texture should be asked for. Allowable values yes + and no
auto_block_linedefsWhen linedef flags are altered and this + is set to yes, linedefs that were 2-sided and are + now 1-sided have the impassible flags automatically set.
+ Likewise linedefs that were 1-sided and are now 2-sided + have the impassible flag automatically cleared.
+ If set to no no action is taken when these events + happen.
brightDescribes a gamma value applied to any + textures, flats and sprites read in from the DOOM WAD + files. Allowable values are any floating point number.
clear_on_menuIf set to yes then once the + pop-up menu has been used to modify the selected objects + they are automatically unselected.
clear_on_moveIf set to yes then once the + selected objects have been moved they are automatically + unselected.
default_light_level
+ default_floor_height
+ default_ceiling_height		Describes the default light, floor and + ceiling height for created sectors. Note that if a sector + is created within another sector, the values for that + sector, rather than these defaults, are used.
default_edit_modeDefines the default edit mode when + loading a new map into the editor. Possible values are: +
default_scaleThe starting scale used in the editor.
gridUse this to say whether the grid will be + shown on screen while editing. Allowable values are yes + and no.
grid_lockUse this to say whether inserted and + moved object in the editor will be snapped on a grid. + Allowable values are yes and no.
grid_sizeDescribes the size of the grid used by + the above items. Allowable values are integer values + greater than two.
hover_selectWhen editing object in a DOOM level this + alters the way that viDOOM works if the right mouse + button is used over an unselected object. The allowable + values, and their affects are:
    +
  • none - nothing is done. The right mouse + button works as expected.
    • +
  • add - the object the mouse is over is + added to the selected objects before displaying + the menu.
    • +
  • single - the object the mouse is over is + made the sole selected object before displaying + the menu.
    • +
+
insert_selectWhen inserting new objects in a DOOM + level this alters the way that viDOOM selects the objects + after creation. The allowable values, and their affects + are:
    +
  • none - nothing is done. The new object is + left unselected.
    • +
  • add - the new object is added to the + selected objects.
    • +
  • single - the new object is made the sole + selected object.
    • +
+
linedef_selectDefines who many pixels around a LINEDEF + the bounding box stretches when selecting a line.
merge_linedefIf you overlay vertexes on top of each + other you can merge vertexes. Once these vertexes are + merged checks are made to see whether linedefs share + these vertexes, and hence overlap. This option controls + what happens when these overlapping linedefs are found. + The possible values are:
    +
  • always - always merge the overlapping + linedefs without any prompting.
    • +
  • ask - confirms with the user before + merging linedefs or not as requested.
    • +
  • never - never merge overlapping linedefs.
    • +
+
new_2sided_selectWhen linedefs have there flags set so + that a new left sidedef is added to it controls how the + altered linedefs are selected. Possible values are:
    +
  • select - clears the currently selected + linedefs (if any) and selects the linedefs that + have new double sides.
    • +
  • ask - confirms with the user. If the user + opts to select the linedefs, the current + selection is cleared and the altered linedefs + selected.
    • +
  • never - never select the altered linedefs. + Note that a notice is still displayed so that you + know new left sidedefs have been created.
    • +
+
sector_moveDefines which linedefs are actually + moved when moving a sector. Possible values are:
    +
  • all - move all linedefs that border the + sector.
    • +
  • right - move only linedefs that have this + sector to their right.
    • +
  • left - move only linedefs that have this + sector to their left.
    • +
+
show_full_linedef_infoIf set to yes then in the linedef edit display + the linedef type will be shown as the full linedef name + as defined in the config file. + If set to no then linedef type will be displayed + as a hex value and it's class.

This has no effect when + editting HEXEN format maps.

+
tag_highlightIf set to yes then the tag + highlighting mode is enabled by default in sector and + linedef modes.
vertex_radiusDescribes the size of the box around a + VERTEX which is used to select the VERTEX while editing. + Recommended values are any integer greater than four.
width
+ height		Describes the size of the display used + by viDOOM. viDOOM expects a resolution of at least + 640x480.
+ +
+ +

[viDOOM]

+ +

Main menu configuration

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
auto_loadmapSet this to a list of levels to load on + startup. The format is to set it to a list of level names + seperated by commas. The first level that can be loaded + successfully is used. If this is set then initial_empty_map + is ignored.

If empty or not used then no map is auto + loaded, e.g.

+

# Load the first map, whether we're editing DOOM + or DOOM2
+ auto_loadmap=MAP01,E1M1

+

# Don't auto load any maps
+ auto_loadmap=

+
initial_empty_mapIf set to yes then on startup + viDOOM will have an empty map, either MAP01 or E1M1, + ready for editing. This is ignored if auto_loadmap + is set.
load_flatsIf set to yes then the graphics + for the flats will be loaded so they can be selected + graphically. If set to no then flats are selected + just using their name.
+ This is provided as the graphics reading is not very + efficient and can be slow on certain machines.
load_texturesIf set to yes then the graphics + for the textures will be loaded so they can be selected + graphically. If set to no then textures are + selected just using their name.
+ This is provided as the graphics reading is not very + efficient and can be slow on certain machines.
load_spritesIf set to yes then the graphics + for the things will be loaded so they can be selected + graphically. If set to no then things are selected + just using their name.
+ This is provided as the graphics reading is not very + efficient and can be slow on certain machines.
map_clear_warningIf set to yes then a warning is + displayed whenever an option is chosen that will replace + the currently edited map with another, if the editor has + been used since the level's loading/creation.
map_exit_warningIf set to yes then a warning is + displayed if exit is chosen and the editor option has + been used.
overwrite_warningIf set to yes then a warning is + displayed if you save a map over a file that already + exists.
show_titlepicIf set to yes then the title + picture for the version of DOOM you are editing will be + displayed on the main title screen.
sort_flat_namesIf set to yes then when selecting + ceiling or floor flats they will be sorted into + alphabetical order. If set to no they are simply + in the order they appear in the IWAD file.
sort_texture_namesIf set to yes then when selecting + wall textures they will be sorted into alphabetical + order. If set to no they are simply in the order + they appear in the IWAD file.
+ +
+ +

[Check LINEDEF]

+ +

This defines how the Check LINEDEF function in the +editor (see editing for +details) operates. Note that part of the configuration for this +command also occurs in the config +file. This is required as texture names can be different in +different versions of DOOM. The following options are definable +within the INI file:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
assume_yesIf this is set to yes then any + time a question would be asked to see if it's OK to + remove a texture that viDOOM considers unnecessary then + it will be removed without asking. Likewise when asking + to add missing textures the texture picklist will appear + (with the linedef number and what is to be set in the + title) without any prompting.
check_1side_lowerIf set to yes then when a sidedef + is attached to a one-sided linedef and there is a lower + texture defined viDOOM will ask if it's OK to remove it.
check_1side_middleIf set to yes then when a sidedef + is attached to a one-sided linedef and there is no middle + texture defined viDOOM will ask if it's OK to define it.
check_1side_upperIf set to yes then when a sidedef + is attached to a one-sided linedef and there is an upper + texture defined viDOOM will ask if it's OK to remove it.
check_2side_lowerIf set to yes then when a sidedef + is attached to a two-sided linedef which is between two + sectors with different floor heights and there is no + lower texture defined viDOOM will ask if it's OK to + define it.
check_2side_middleIf set to yes then when a sidedef + is attached to a two-sided linedef which is between two + sectors and there is a middle texture defined viDOOM will + ask if it's OK to remove it.
check_2side_upperIf set to yes then when a sidedef + is attached to a two-sided linedef which is between two + sectors with different ceiling heights and there is no + upper texture defined viDOOM will ask if it's OK to + define it.
check_2side_same_sectorIf set to yes then when a sidedef + is attached to a two-sided linedef which is wholly within + one sector and there are any textures defined viDOOM will + ask if it's OK to remove them.
+ +
+ +

[Node Builder]

+ +

Node Builder configuration - used to build nodes for maps +automatically when saving.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
always_view_outputNormally viDOOM will only show the + output from the build command if it fails for some + reason. Setting this to yes means any output from + the node builder will be displayed regardless.
commandDefines the command used to execute the + node builder. e.g.

command=c:\bsp\bsp.exe

+
ignoreIf set, then any saved filename that + includes this string will not be passed through the node + builder. This is useful so that structures for merging + into other maps (see editing + for details) need not be put through the node building + process. e.g. if set to

ignore=str

+

Then saving a map named MAP01.WAD will be + passed through the node builder, whereas WALL_STRUCT.WAD + would not be.

+

Another important use for this is to leave a back door + where you can save a WAD without it being passed through + the node builder if anything goes wrong with trying to + build the map.

+
infileDefines the format for the infile + parameter to the node builder. Any occurrence of the '%' + character will be replaced with the full path of the map + being saved. e.g.

infile=%

+
outfileDefines the format for the outfile + parameter to the node builder. Any occurrence of the '%' + character will be replaced with the full path of the map + being saved. e.g.

outfile=-o %

+

Note that if your node builder does not allow the + input and output file to be the same then it is + permissible to put extra characters after the % + that will get tacked onto the end of the name, e.g.

+

outfile=-o %_NEW

+
in_before_outDefines the order of the the arguments + to the node builder. If set to yes then the node + builder is invoked as:

command infile outfile

+

If set to no then the command is built as:

+

command outfile infile

+
useIf set to yes then the node + builder described above is used on any maps being saved. + If set to no then the map is saved and the nodes + must be built outside of viDOOM.
+ +
+ +

[ACS]

+ +

ACS compiler configuration - used to build BEHAVIOR lumps for +HEXEN format maps.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
always_view_outputNormally viDOOM will only show the + output from the compiler if it fails for some reason. + Setting this to yes means any output from the + compiler will be displayed regardless.
commandDefines the command used to execute the + acs compiler. e.g.

command=c:\doom\acc\acc.exe

+
dirDefines a working directory that will be + used for the compilation. This will generally be the same + place that the acs header files are stored and viDOOM + will change directory to this directory before + compilation. e.g.

dir=c:\doom\acc\

+
scriptviDOOM will write an acs script with + this name, into the directory defined by dir + before compilation. e.g.

script=vidoom.acs

+
objectviDOOM will assume that the acs object + created by the compiler will have this name. e.g.

script=vidoom.o

+
argsDefines the argument list to the ACC + compiler. The string %S will be replaced + by script, defined above. The string %O + will be replaced by object defined + above. e.g.

args=%S %O

+
+ +

 

+ +
+ +

[GUI]

+ +

GUI configuration. All the values in this section are an RGB +triplet defined as an hex number, i.e. 0xRRGGBB. The +following values can be set from the INI file.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
gui_hiThe brightest colour used to draw the 3D + looking interface.
gui_midThe medium colour used to draw the 3D + looking interface.
gui_loThe darkest colour used to draw the 3D + looking interface.
gui_textThe colour of text.
gui_textshadowThe colour of the shadow behind text. + This is only really used by viDOOM's own portable GUI + routines. If set to the same value as text then no + shadows are drawn.
gui_boldThe colour of bold text (used for + titles)
+ +
+ +

[Game name]

+ +

One of these sections appears for each possible setting of the +game variable in the [Game] section. These are:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
iwadDefines the path to the IWAD for this + game.
pwad_dirDefines the default load/save directory + for editing PWAD files.
level_styleDefines the level naming convention for + the game. Allowable values are:
    +
  • Doom - allows level names E1M1 to E3M9
    • +
  • Ultimate Doom - allows level names E1M1 to + E4M9
    • +
  • Doom 2 - allows level names MAP01 to MAP32
    • +
+
preloadLists a number of PWAD files to preload + on startup. PWAD files are separated by ; and the full + path is expected.
vidoom_configDefines the config + file for this version of DOOM. This defines the + values used for defining things, linedefs, sectors and so + on.
+ viDOOM is currently supplied with doom.cfg, doom2.cfg + and zdoom.cfg.
mapinfo_lumpThis only applies to the section for [ZDoom] + .

If this is set to yes then on loading a + map from the loaded WAD files, the directory pointed to + by pwad_dir is searched for MAPINFO.WAD. + If found then the MAPINFO lump from the MAPINFO.WAD is + read in and can be edited within the editor. If + WADINFO.WAD does not exist then an empty MAPINFO lump is + created.

+

NOTE: On saving the level if there is anything + in the mapinfo entered in the editor the MAPINFO.WAD file + will be overwritten (or created if it does not exist). + This means that any infomation (apart from the edited + MAPINFO lump) that was in this WAD file will be lost. It + is suggested that nothing goes into MAPINFO.WAD except + for the MAPINFO lump.

+
create_hexenThis only applies to the section for [ZDoom] + .

If this is set to yes then on creating a + new map, it will be marked as being in the HEXEN format + (ie. having a BEHAVIOR lump and the HEXEN format of + THINGS and LINEDEFS). If set to no then the map + will be created as a DOOM map.

+

Setting to ask means that you will be asked + prior to creation which sort of map you want.

+
+ +
+ +

Config file

+ +

There is two config files supplied with viDOOM, doom.cfg +and doom2.cfg. Each file is comprised of sections followed +by the data expected in each section. Each section is defined by +a line like:

+ +

%SECTION_NAME

+ +

While the data lines are on individual lines with the pipe (|) +character used to separate fields, e.g.

+ +

Field 1|Field 2

+ +

Blank lines and lines starting with a comment character (#) +are ignored. In addition to this blocks of lines can be forced to +be ignored by enclosing them with directives introduced with the +@ charcater. See the following +section for more details.

+ +

Note that some sections allow an edit mode to be defined, to +indicate whether this definition is for DOOM or HEXEN edit mode +(or both). The currently allowed edit modes are:

+ + + +

If what is being defined applies to more than one mode, these +can be seperated with commas.

+ +

The following sections are defined:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
%INCLUDE_FILESDefines any other config files to + include before processing this one. Simply type the + filenames to be included on individual lines.
%THING_CLASSESDefines the classes to group THINGs into + in the editor picklists. Each line is in the form + "Class Name|Colour". Note that colour is + defined as an hexadecimal number with the most + significant byte for RED, the middle byte for BLUE and + the least significant byte for GREEN. e.g.

Monster|0xff0000

+
%LINEDEF_CLASSESDefines the classes to group LINEDEF + types into in the editor picklists. Each line is a class + name.
%SECTOR_CLASSESDefines the classes to group SECTOR + types into in the editor picklists. Each line is in the + form "Edit mode|Class Name". e.g.

Doom,Hexen|Lighting

+
%THING_TYPESDefines the names and IDs of the THINGs + supported by DOOM. Each line is in the form + "Class|Name|ID|Radius|Sprite Name". e.g.

Monster|Former + Human|3004|20|POSSA1

+
%THING_FLAGSDefines the flags used when setting a + THINGs flags. Each line is in the form "Edit + Mode|Group|Mask1|Mask2|Name|Single flag character". + e.g.

Doom,Hexen|0|0x01|0x01|Skill 1 and 2|E

+

The group number indicates masks that should be + mutually exclusive. Group zero means that the flag can be + toggled independently of any other. Other group numbers + mean that only one of that group should be set at a time.

+

The ways the masks work is:

+
+

To see if a flag is set the flags are ANDed with + mask1. If the result equals mask2 then the flag is + set.

+

When defining flags all the mask1 values are ORed + together and those bits cleared from the flags. Then + for any option that has been set mask2 is ORed onto + the flags.

+
+
%LINEDEF_TYPESDefines the names and IDs of the LINEDEF + types supported by DOOM. Each line is in the form + "Class|ID|Name", e.g.

Special|48|Scrolling + wall

+

Note: Please note that the text for the LINEDEF + types in the supplied config files is taken directly from + the Unofficial Doom Specs (see the thanks page for details). + Please feel free to change them to something more useful + if you prefer.

+
%LINEDEF_FLAGSDefines the flags used when setting a + LINEDEFs flags. The format for this section is identical + to THING_FLAGS.
%LINEDEF_FLAGS_EXTRAConfiguration so that viDOOM knows which + bits control certain functions. If more that one line + appears in this section then the last one is used. The + form of the line is "Bit number controlling + 2-sided|Bit controlling Impassible|Bit controlling lower + unpegged|Bit controlling upper unpegged". e.g.

2|0|3|4

+
%LINEDEF_DEFAULTSThis section must not appear before + %LINEDEF_FLAGS_EXTRA and defines the bit patterns for + various linedef styles. These are used in the editor so + that defining a type of LINEDEF can be quickly done when + creating them. The format of each line is + "Name|Flags value", e.g.

2-sided + wall|0x47

+
%SECTOR_TYPESDefines the names and IDs for the + different sector types. Each line is in the form + "Edit Mode|Class|ID|Long name|Short name". e.g.

Doom|Lights|1|Light + random off|Random off

+
%SECTOR_STYLESDefines styles for painting sectors + quickly. The form of each line is + "Mode|Name|Upper|Middle|Lower|Floor|Ceiling". + e.g.

0x19|Quarry|SP_ROCK1|SP_ROCK1|SP_ROCK1|RROCK09|F_SKY1

+

The mode is a bit significant number where the bits + have the following meaning:

+
    +
  • Bit 0 - Paint textures on the sidedefs facing + into this sector
    • +
  • Bit 1 - Paint textures on the sidedefs facing out + of this sector
    • +
  • Bit 2 - Leave current lower/upper settings
    • +
  • Bit 3 - Set upper unpegged if an upper texture is + painted
    • +
  • Bit 4 - Set lower unpegged if a lower texture is + painted
    • +
+

If neither bits 2, 3 or 4 are set it is assumed that + lower/upper unpegged will be cleared on painting those + textures.

+
%EMPTY_TEXTURE_NAMESimply defines the empty texture name + used by DOOM. This will generally just be the - + character, e.g.

%EMPTY_TEXTURE_NAME
+ -

+
%NORMAL_TYPESDefines the values that define the + normal linedefs and sectors. The form of the single line + of data is "Id for normal linedef|Id for normal + sector". In all current versions of Doom this is + zero, e.g.

%NORMAL_TYPES
+ 0|0

+
%LINEDEF_CHECK_DEFAULTProvides an optional default texture to + use when a texture is requested when checking linedefs. + If this value is defined to be the same as + EMPTY_TEXTURE_NAME then the user is prompted for a + texture to use, otherwise this texture is used instead, + e.g.

%LINEDEF_CHECK_DEFAULT
+ ASHWALL

+

See editing for + details on the check linedef operation.

+
%LINEDEF_GEN_BITMASKSThis defines the bitmasks used to + represent generalised LINEDEF types (these were + introduced by BOOM).

This + section is a bit more complex than most of the others as + the format of the data is not fixed from line to line. + Each set starts with the class name for the bitmask. + Format for this line is:

+

class name|no of fields

+

After this follows no of fields repetitions + of the following:

+

field name|shorthand name|value

+

e.g.

+

%LINEDEF_GEN_BITMASKS
+ Speed|4
+ Slow|Slow|0
+ Normal|Norm|1
+ Fast|Fast|2
+ Turbo|Turb|3

+

Remember that value will be shifted left a specified + amount when used in the LINEDEF_GEN_TYPES + section and so they should be defined relative to bit 0. + Also note that inside the editor all the values + associated with a bitmask are ORed together to create a + mask that can extract that information from a generalised + linedef. Following all this can follow another class, and + so on. Also remember that blank lines and comments are + OK, so that sections can be readably split using white + space.

+
%LINEDEF_GEN_TYPESThis defines the groupings of + LINEDEF_GEN_BITMASKS to make up different generalised + LINEDEF types.

This section is a bit more complex than + most of the others as the format of
+ the data is not fixed from line to line. Each set starts + with the class name describing the name of this type of + generalised linedef, the number of different bit patterns + defined in the class, the low and high values that the + type occupies and a mask used when generating the value. + Format for this line is:

+

class name|low value|high value|mask|no of + bit-field classes

+

After this follows no of bit-fields repetitions + of the following:

+

bit-field name|shift

+

e.g.

+

Locked Door|0x3800|0x3bff|0x3800|5
+ Trigger|0
+ Speed|3
+ Locked door kind|5
+ Opens with|6
+ Number of keys|9

+

The shift defines how much the bitmask is shifted to + the left to generate the actual values stored in the + linedef type field. Note that along with these bitmask + values the mask field is also ORed onto the result to + create the entire linedef type value. Following all this + can follow another class, and so on. Also remember that + blank lines and comments are OK, so that sections can be + readably split using white space.

+
%SECTOR_GEN_BITMASKSThis works in exactly the same way as LINEDEF_GEN_BITMASKS, + but is used to define the generalised bitmasks used by a + SECTOR.
%SECTOR_GEN_TYPESThis works in exactly the same way as SECTOR_GEN_BITMASKS, but is + used to define the generalised types used by a SECTOR.
%HEXEN_ACTION_SPECIAL_CLASSESDefines the classes to group action + special types into in the editor picklists. Each line is + a class name.
%HEXEN_ACTION_SPECIALSDefines the HEXEN action specials. Each + line is of the form "Class + Name|Id|Name|arg0,arg1,arg2,arg3,arg4". Note that + not all the argument names need be filled in. e.g.

Normal|0|No + action|
+ Polyobject|1|Polyobj_StartLine|po,mirror,sound
+ Lighting|116|Light_Strobe|tag,upper,lower,u-tics,l-tics

+

Any arg name that is "tag" is used to work + out what sector the special is referring to. This is so + that tag highlighting (see editing + for details) still works in HEXEN mode.

+

Note that unfortunately this does not apply to THINGs + yet.

+
+ +
+ +

Config file directives

+ +

In the config files blocks of lines can be included or +excluded by surrounding them by enclosing them with directives +introduced with the @ charcater, e.g.:

+ +

@DOOM_LEVEL_STYLE
+%SECTOR_STYLES
+<data>
+@END DOOM_LEVEL_STYLE

+ +

As you can see a directive is terminated by putting the same +directive, beginning with END.

+ +

The main purporse of these is to stop SECTOR_STYLES and +LINEDEF_CHECK_DEFAULT being defined inappropriately (Doom and +Doom 2 have differing texture names, etc), and also to allow one +single ZDOOM configuration file to be defined, regardless of +whether you are using the Doom or Doom 2 IWAD files with it.

+ +

The following directives are currently supported:

+ + + + + + + + + + + + + + + + + + +
@DOOM_LEVEL_STYLEIncludes the lines up to the next @END + DOOM_LEVEL_STYLE if the level_style for this game is + defined as either Doom or Ultimate + Doom.
@DOOM_1_LEVEL_STYLEIncludes the lines up to the next @END + DOOM_1_LEVEL_STYLE if the level_style for this game is + defined as Doom.
@ULT_DOOM_LEVEL_STYLEIncludes the lines up to the next @END + ULT_DOOM_LEVEL_STYLE if the level_style for this game is + defined as Ultimate Doom.
@DOOM_2_LEVEL_STYLEIncludes the lines up to the next @END + DOOM_2_LEVEL_STYLE if the level_style for this game is + defined as Doom 2.
+ +
+ +

Back to index

+ +

$Id$

+ + -- cgit v1.2.3