Knowledge Base - WadAuthor WCF File
WadAuthor WCF File
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.
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.