WadAuthor WCF File

By Richard Clark

One of the reasons I use WadAuthor is because the editor is extensible. The game data is not hard coded into the executable; it is contained in a configuration file. This allows easy addition of new data types. This has come in quite handy now that several flavors of Doom ports currently exist, with new ones coming all the time.

Anatomy of a WCF File

The WCF file, just like a windows ini file, has different sections that perform different functions.

; Defines general parameters of the game for which wadfiles are intended.
;
;	Name		textual name for internal use
;	IWAD		standard 8.3 base name and extension of main wadfile
;	NewMap		default name for new map -- dictates format for all maps
;	Directory	directory in which main wadfile (and game files) reside
;	Run		command to execute (from the directory) for running a map

[WadGame]
Name=ZDoom (Hex)
IWAD=zddoom2.wad
NewMap=MAP01
Directory=C:\zdoom
Run=zdoom.exe -file $_Wadfile -warp $_Wadmap

The semicolons, ;, are comments. Each section has some explanatory text before it begins. WA ignores any line with a semicolon. The verbiage with the square brackets, [ ], is the section header. A section begins with the section header and ends at the next section header, or the end of the file.

The WadGame section, shown above, lists the game information. The Name entry is the name of the configuration file that is displayed in the status bar of the editor. The IWAD is, of course, the game IWAD to use. The NewMap is the default map number for the game being edited. For example, for Doom2 and ZDoom it reads Map01. For Doom 1, it would read E1M1. The Directory entry is the folder where the game executable is located. This also needs to be the folder where the IWAD is located as well, since WA looks for the IWAD and EXE in the same folder. The Run entry is the commands line that is passed to the game when the Run button is clicked in the editor. You can add items to the run command here or in the run dialog that displays when the Run button is clicked. For example, for a Doom1 Boom wcf add the -iwad doom.wad before the -file parameter.

The -file $_Wadfile, indicates the current wad being edited. The variable $_Wadfile will be replaced with the actual wad file name, i.e. mb1.wad. Likewise the -warp $_Wadmap parameter is the map number i.e., 1 for Doom2 Map01 or 1 1 for Doom E1M1.

Note: in order to run Windows based wad games you need to add the following to the beginning of the wauthor.ini file:

[Debug]
NoWaRun=1

This will bypass the DOS runtime utility that WA uses by default.

The next set of sections shown below are the various defaults used in the editor. These defaults are used when no Motif has been selected.

; Defines parameters of the default sector motif created when no motif
; file can be located at startup.

[Default.Sector]
Above=STARTAN2
Main=STARTAN2
Below=STARTAN2
Ceiling=CEIL3_5
Floor=FLOOR4_8
CeilingHeight=128
FloorHeight=0
Lighting=160

; Defines parameters of the default door motif created when no motif
; file can be located at startup.

[Default.Door]
Base=FLAT1
Door=BIGDOOR2
Track=DOORTRAK
Type=12

; Defines parameters of the default stair motif created when no motif
; file can be located at startup.

[Default.Stair]
FloorRunner=STONE4
CeilingRunner=STONE4
Stairwell=STONE4
FloorInc=8
CeilingInc=0
LightingInc=0

The rest of the sections are divided into logical sections called Classes and Types. The classes are the major groupings that are displayed in the edit dialogs of the editor. The types are displayed when a class has been selected. Figure 1 shows the ACS class has been selected which it turn displays all the ACS types availible.

Edit Dialog Showing Classes and Types
Figure 1: Edit Dialog Showing Classes and Types

The following are the class of Things in the game.

;	ID			used to classify things
;	Flags			supplies some additional information:
;				0x0001 - indicate thing facing angle
;	Red			red value for drawing things of said class
;	Green			green value for drawing things of said class
;	Blue			blue value for drawing things of said class
;	Name			textual description of class

[Things.Classes]
0x001	0x0001	255	255	255	Start
0x002	0x0000	128	128	0	Weapon
0x003	0x0001	255	0	0	Enemy
0x004	0x0000	128	128	0	Ammo
0x005	0x0000	0	255	255	Powerup
0x006	0x0000	255	255	0	Key
0x007	0x0000	192	192	192	Scenery
0x008	0x0001	255	0	255	Teleport
0x009	0x0000	192	0	0	Hazard
0x00a	0x0000	0	192	0	Armor
0x00b	0x0000	0	0	255	Healing
0x00c	0x0000	96	96	96	Sounds
0x00d	0x0000	0	128	128	Special
0x00e	0x0000	96	96	96	Sound sequences
0x00f	0x0000	128	128	255	Particle effects

The first column is the class ID. This is used to group items into classes (shown in the Types) section. The number is in HEX. (The Windows calculator in Scientific mode will convert decimal number to Hex). The second column is the Flags column. For classes, this indicates that a facing angle is required. This value is either 1 or 0, HEX. The next three columns are the red, green and blue color values used to display the Thing token in the map display of the editor. The last column is the Name of the class that is listed in the Class list on the edit dialog.

;	ID			used to uniquely identify things in a map
;	Class			classification (defined above section)
;	Size			approximate thing size (in map units)
;	Sprite			name of the sprite to use for display purposes
;	Name			textual description of thing

[Things.Types]
0x001	1	32	playa1		Player 1 *( number, -, -, -, - )
0x002	1	32	playa1		Player 2 *( number, -, -, -, - )
0x003	1	32	playa1		Player 3 *( number, -, -, -, - )
0x004	1	32	playa1		Player 4 *( number, -, -, -, - )
0x005	6	20	bkeya0		Blue card

The Type section immediately follows the class section (only partially listed here). The first column is the Thing ID, in Hex. This is the ID number the games uses to identify this thing. The second column is the class ID. The class id is used to identify this item with the above classes. When a class is selected in the edit dialog, the items with that class number are displayed in the Types list. This number is in decimal though, not HEX (don't ask me why :). The third column is the approximate Size of the thing. This parameter is used to make the Thing token larger or smaller in the map view to aid in placing things correctly in relation to walls and other Things. The fourth column is the Sprite graphic used to display the Thing in the Thing dialog. The last column is the Name that is listed in the edit dialog. The *( number, -, -, -, - ) is unique to ZDoom; it indicates the arguments this Type uses. In Figure 1, the arguments section are listed directly below the Types list. This is actually a Hexen feature, that is used in ZDoom to allow ACS scripting. The arguments are not present in the standard Doom game.

The next sections are the linedef Classes and Types. In ZDoom these are called Specials, again a Hexen variation.

[Specials.Classes]
0x001	Special
0x002	Door
0x003	Ceiling
0x004	Lift
0x005	Floor
0x006	Pillar
0x007	Stairs
0x008	ACS
0x009	Scroll
0x00a	Thing
0x00b	Teleport
0x00c	Lighting
0x00d	Polyobject
0x00e	Exit
0x00f	Elevator

In Doom 2 these are listed as:

[LineDefs.Classes]
0x001	Special
0x002	Local door
0x003	Remote door
0x004	Ceiling
0x005	Crushing ceiling
0x006	Lift
0x007	Floor
0x008	Moving floor
0x009	Stairs
0x00a	Exit
0x00b	Teleport
0x00c	Lighting

In both cases the definitions contain the ID number, again in Hex and the Name which is displayed in the Classes list.

	ID
;	class
;	Name( arg0, arg1, arg2, arg3, arg4 )

[Specials.Types]

; Special
0x081	1	UsePuzzleItem( item, script, sArg0, sArg1, sArg2 )
0x08c	1	Sector_ChangeSound( tag, sound, -, -, - )
0x078	1	Earthquake( intensity, duration, damrad, tremrad, tag )
0x079	1	Line_SetIdentification( line, -, -, -, - )
0x0bf	1	SetPlayerProperty( who, set, which, -, - )

The ZDoom Special Type definitions follow the same format as the Thing definitions. The first column is the Special ID recognized by the game. The second number is the Class ID, in decimal. The Third column is the Name and arguments this special requires.

Regular Doom has a slightly different format:

;	ID
;	class
;	codes
;		n       does NOT require a tag number
;		W       walk-over activation
;		S       switch (triggered by player use)
;		G       gunfire (pistol, shotgun, chaingun) cross or hit line
;		1       the line may be activated once only
;		R       potentially repeatable activation
;		&       affected sectors locked out from further changes
;		m       monster actions can activate the line's effect
;	speed 
;		(slow=1, medium = 2, fast = 3, turbo = 4)
;	time
;	texture changes
;	description

[LineDefs.Types]

; Special
0x030	1	n		-	-	-   scrolling wall (left)

; Local door
0x001	2	nSRm	2	4	-	open/close
0x01a	2	nSR		2	4	-	open/close (blue key required)
0x01c	2	nSR		2	4	-	open/close (red key required)
0x01b	2	nSR		2	4	-	open/close (yellow key required)

The first two columns are the familiar game ID and Class ID. The third column is the action Codes that this linedef uses. As listed in the comments, these are actions like switched or walkover lines. The fourth column is the speed at with the action occurs. A fast lift or a slow lift, for example. The next column indicates the amount of Time an action may take. For example, a door may stay open for 30 seconds then close. The next column indicates that the linedef performs an action based upon a texture. For example, a up to next highest floor + texture switch. The last column is the Description which is displayed in the Types list.

The last section is the Sector types. Since the sector types are listed in the sector dialog and it only has a single list, there is no sector class section.

[Sectors.Types]
0x0001 Phased light (manual)
0x0002 Phased light sequence start
0x0003 Phased light sequence 1
0x0004 Phased light sequence 2
0x001a Stairs 1
0x001b Stairs 2
0x0041 Blink (random)
0x0042 Blink (1/2 second)
0x0043 Blink (1 second)
0x0044 -10/20% health, blink (1/2 second)

The Doom and ZDoom sections are the same. The first column is the Sector ID recognized by the game. The last column is the description shown in the sector list in the Sector edit dialog.

Keep in mind that the entries listed in the WCF file are the entries that the particular game recognizes. Adding new entries in the WCF will not make the game recognize the entries. In other words, the WCF reflects what the game does, not what you want the game to do. For that you will need to edit the source code or use Dehacked to add to the game.

Adding a New Entry

For a wad I was working on I wanted to have some fake three-d bridges. I created a dehacked patch that replaced one of the hanging corpses.The hanging corpses are in the Scenery class:

0x007	0x0000	192	192	192	Scenery

The old entry in the Thing Types section:

0x032 	7	20	gor2a0 		Chain w/player hung by ankles (block player)

Will be replaced by the new entry:

0x032	7	128	gor2a0		Bridge W=128

Here the Thing ID is 32 hex (decimal 50), it is in class 7 and is 128 units wide. The sprite being used is gor2a0 which has been replaced by a small cyan square in the wad file to make it invisible. The description is Bridge thing with a width of 128.

To add a new linedef follow the same procedure. Either select an existing class or add a new class to the linedef (or specials) class section. If adding a new class, just use the next available class ID number.

For example, the Sounds class for ZDoom was simply added to the end of the Things Class section. The original Doom2 Things section ends in Healing with a Class ID of 0x00b hex (11 decimal). The next class ID would be 12 decimal or 0x00c hex.

Once the layout of the WCF file becomes clear it is easy to modify the file for any wad based game. For example, using the data sheet provided with Banjo Software's HacX Total Conversion, it would be a simple matter to create a special wcf file just for HacX. I'll leave that as an exercise for the reader.

Back