Yadex 1.7.0 (2026-07-12)

# Yadex game definition files

## Introduction

Yadex game definition files (conventional extension `.ygd`) are designed to contain all the information relative to a particular game. The syntax and the semantics are very simple ; it's more like a database than a real script language. For normal use, you don't ever need to read, much less modify, ygd files.

## General syntax

A file is a valid Yadex game definition file if its first line contains exactly the following magic string : "`# Yadex game definition file version 4`" (without the double quotes).

The rest of the file is split in lines, each line separated from the following by a newline. White space at the beginning and end of a line is stripped. Each line is then split in tokens, separated by one or more white space characters. A double quote removes the special meaning of subsequent white space characters until the next double quote. A token formed of just two consecutive double quotes is an empty token : its value is the empty string. Double quotes are stripped from the token after the token splitting is done. There is no way to include a double quote in the contents of a token.

A hash mark ("`#`") at the beginning of a token marks the beginning of a comment. Everything from the hash to the end of the line is stripped. If no tokens remain, the line is ignored. If at least one token remains, the first token must be the name of a valid directive and the following form its arguments. If the first token is not the name of a valid directive or the number of arguments is wrong, the whole file is rejected.

Note that the following common features are not supported : breaking lines with "`;`", joining lines with "`\`" at the end of the first line, quoting with "`'`" or "`\`".

The following lines are equivalent :

    foo bar baz
    foo bar baz      # You too can wear a nose mitten
    foo bar  baz
    foo "bar" baz
    foo bar "b""a""z"""
    foo bar ba""z
      foo bar baz

The following lines are not equivalent to the above :

    foo bar baz ""
    foo bar "baz "

## Directives

### `ldt type group shortdesc longdesc`

  Defines a linedef type. Takes exactly 4 arguments.

  `type` |  | The linedef type. Must be a decimal integer.
  `group` |  | The linedef type group this linedef type belongs to. This field is silently truncated to 1 character. The group must have been prealably defined by an `ldtgroup` directive.
  `shortdesc` |  | Description that will be displayed in the object info window. There is no limit on the length of this field but only the first 16 characters of it are shown in the object info window.
  `longdesc` |  | Description that will be displayed everywhere else. There is no precise limit on the length of this field but it's recommended to keep it within reasonable limits.

  There should be at least one linedef type for each group defined. There is no precise upper limit but defining more than 30 in the same group will cause problems. You should not define the same linedef type more than once.

### `ldtgroup group desc`

  Defines a group of linedef types. Takes exactly 2 arguments.

  `group` |  | The identifier of the linedef types group. It is silenty truncated to 1 character.
  `desc` |  | Description. There is no precise limit on the length of the this field but it's recommended to keep it within reasonable limits.

  There is no upper or lower limit on the number of groups but defining more than 20 will cause problems. You should not define the same group more than once.

### `level_format level_format`

  Indicates the format in which levels are stored in the wad. There is only one argument. It can have the following values :

  Value | Meaning
  --- | ---
  `alpha` | Doom alpha format, 7 directory entries per level (label, `FLATNAME`, `POINTS`, `LINES`, `SECTORS` and `THINGS`).
  `doom` | Normal Doom format, 11 directory entries per level (label, `THINGS`, `LINEDEFS`, `SIDEDEFS`, `VERTEXES`, `SEGS`, `SSECTORS`, `NODES`, `SECTORS`, `REJECT` and `BLOCKMAP`).
  `hexen` | Hexen format, 12 directory entries per level (same as for `doom` then `BEHAVIOR`).

  Reading is supported for all formats but writing is not supported for `hexen`. For `alpha`, writing is done in `doom` format.

  This directive is mandatory. If there are several `level_format` directives, it's the last one that counts.

### `level_name level_name`

  Indicates whether the level names for that game are of the form `EnMn` or of the form `MAPnm`. There is only one argument. It can have the following values :

  Value | Meaning
  --- | ---
  `e1m1` | `EnMm` (Doom, Doom press release and Heretic).
  `e1m10` | `EnMm` or `EiMjk` (Doom alpha only)
  `map01` | `MAPnm` (Doom II, Hexen and Strife).

  The influence of this directive on the behaviour of Yadex is in the choice of the default name for new levels and the way shorthand arguments to the `edit` and `create` commands are interpreted.

  This directive is mandatory. If there are several `level_name` directives, it's the last one that counts.

### `picture_format picture_format`

  Indicates in which format the pictures are stored in the wads. There is only one argument. It can have the following values :

  Value | Meaning
  --- | ---
  `alpha` | The obsolete format used in Doom alpha 0.2, 0.4 and 0.5.
  `pr` | The obsolete format used in the Doom press release pre-beta.
  `normal` | The normal format used by all other iwads.

  This directive is optional. If it's missing, the default is `normal`. If it's repeated, it's the last occurrence that counts.

### `sky_flat flat_name`

  Specifies the name of the flat used for skies. This is important to Yadex as far as upper and lower texture checking is concerned (upper/lower textures are not rendered if both sectors have a sky ceiling/floor). The argument is matched against the sector's flat name in a case-insensitive fashion where at most the 8 first characters matter. I personally use lower case and recommend that you follow the same convention.

  This directive is optional. If it's missing, all flats will be considered normal. If it's repeated, it's the last occurrence that counts.

### `st type shortdesc longdesc`

  Defines a sector type. Takes exactly 3 arguments

  `type` |  | Must be a decimal integer.
  `shortdesc` |  | Short description that will be displayed in the object info window. There is no limit on the length of the short description but only the first 14 characters are shown in the object info window.
  `longdesc` |  | Long description that will be displayed everywhere else. There is no precise limit on the length of this field but it's recommended to keep it within reasonable limits.

  There is no lower limit on the number of `st` directives. If there are too many of them, the menu will not fit in the window so don't do that. You should not define the same sector type more than once.

### `texture_format texture_format`

  Indicates in which format the textures are stored in the wads. There is only one argument. It can have the following values :

  Value | Meaning
  --- | ---
  `nameless` | The obsolete format used in Doom alpha 0.4 (no texture names).
  `strife11` | The format used by Strife 1.1 and later. Note that Strife 1.0 uses the regular format (`normal`).
  `normal` | The normal format used by all other iwads.

  This directive is optional. If it's missing, the default is `normal`. If it's repeated, it's the last occurrence that counts.

### `texture_lumps texture_lumps`

  Indicates in which lump(s) is the list of textures for that game. There is only one argument. It can have the following values :

  Value | Meaning
  --- | ---
  `textures` | There is only one lump and it's called `TEXTURES` (Doom alpha 0.4 and 0.5).
  `none` | There is no textures lump (Doom alpha 0.2)
  `normal` | There is `TEXTURE1` and optionally `TEXTURE2` (all other iwads).

  This directive is optional. If it's missing, the default is `normal`. If it's repeated, it's the last occurrence that counts.

### `thing type group flags radius desc` [`sprite`]

  Defines a thing type. Takes 5 or 6 arguments.

  `type` |  | Must be a decimal integer.
  `group` |  | The thing type group this thing type belongs to. This field is silently truncated to 1 character. The group must have been prealably defined by a `thinggroup` directive.
  `flags` |  | Should be either "`s`" for things that have a spectral or translucent look (like Doom's spectres and Heretic's ghosts) or "`-`" for the others.
  `radius` |  | Radius. Must be a strictly positive integer.
  `desc` |  | Description. There is not limit on the length of this field but only the first 19 characters of it are shown in the object info window.
  `sprite` |  | The root of the name of the sprite associated with the thing type. Yadex will display the first (in alphabetical order) sprite whose name begins with those characters. For example, if the root is `CEYE` and the iwad contains sprites `CEYEA0`, `CEYEB0` and `CEYEC0`, the sprite displayed will be `CEYEA0`. If this field is omitted, Yadex will show no sprite for this thing type. This is appropriate for things that have no visual representation, like sound sources. The present convention is to use upper case (and I've not tested whether lower case works).

  There should be at least one thing type for each thing type group defined. There is no precise upper limit but defining more than 30 thing types in the same group will cause problems. You should not define the same thing type more than once.

### `thinggroup group colour desc`

  Defines a group of thing types. Takes exactly 3 arguments.

  `group` |  | The identifier of the thing types group. It is silenty truncated to 1 character.
  `colour` |  | The colour in which things pertaining to this group will be displayed the editing window. It's an X11-style colour specification. The syntax is "`rgb:r/g/b`" where `r`, `g` and `b` are each one or more hexadecimal digits.
  `desc` |  | Description. There is no precise limit on the length of the this field but it's recommended to keep it within reasonable limits.

  There is no upper or lower limit on the number of groups but defining more than 20 will cause problems. You should not define the same group more than once.

AYM 2003-02-21