EDF miscellaneous reference

Back to EDF

DOOM II Cast Call

The cast call structure allows you to edit and extend the DOOM II cast call used after beating the game in DOOM II. Editing existing thing types via EDF or DeHackEd can otherwise cause this part of the game to malfunction, and it has never before been possible to add your own monsters into the fray. Now this can be done.

Unlike most other EDF sections, castinfo sections will be kept in the order they are specified, unless the castorder array is defined. The castorder array feature allows you to explicitly specify a complete ordering for the castinfo sections which overrides the order of their definitions. See below for more information on castorder.

Beginning with EDF 1.1, all castinfo sections are required to have a unique mnemonic. Sections with duplicate mnemonics will overwrite, with the last one occuring during parsing taking precedence as the definition.

Syntax

castinfo <mnemonic>
{
  type        <thing type mnemonic>
  name        <string>
  stopattack  <boolean>
  
  # see notes about this; there can be from zero to four sound blocks
  sound
  { 
     frame  <frame mnemonic>
     sfx    <sound mnemonic>
  }
}

Explanation of Fields

• type

Default = No default; this field is required.

This field must be set to a valid thing type mnemonic. This denotes which thing type is displayed at this entry's position in the cast call. As of EDF 1.2, if this type is not valid, the thing type "Unknown" will be substituted. This may cause the cast call to malfunction, however. The previous behavior was to cause an error.

• name

Default = See below.

This is an optional field that allows providing a name to display on the screen for the thing type. Note that if this field is not present in any of the first 17 definitions, those cast members will use the normal default names from the executable, which are editable via BEX string replacement. If cast members beyond the first 17 have no name provided, they will say "unknown" (so you should always provide it in those cases).

stopattack

• Default = false

This is a special boolean value (can be any of yes/no, on/off, or true/false) which makes the thing break out of its attack frame cycle after its initial frame. This is only used by the player type by default, but could be used by any other type as well.

sound

There can be up to four of these special blocks defined within each cast member. They define a sound event, so that whenever the thing type enters the designated frame, it will play the designated sound. If there are less than four definitions, the unused ones will be zeroed out. If there are more than four, any beyond four are simply ignored. Also, if the values provided to the fields in this block are invalid, they are simply ignored.

Explanation of Inner Fields

• frame

Default = S_NULL

Name of the frame this event should occur on

• sfx

Default = none

Name of the sound to play when this event occurs.

Restrictions and Caveats

• The castorder list is NOT required.
• At least one cast member must be defined.
• All cast members must have a unique mnemonic. Mnemonics should only contain alphanumeric characters and underscores. All other punctuation marks are explicity reserved for extended syntactical use. Format will not be verified. Non-unique mnemonics will overwrite previous definitions, see below.

Full Example

# My New Cast Call -- Only The Ultimate FooBar and the Player are worthy!
castinfo foobar
{
  type = FooBar
  name = "The Ultimate FooBar"
  
  sound { frame = S_FOOBAR_ATK1; sfx = firsht }
  sound { frame = S_FOOBAR_ATK3; sfx = firsht }
  sound { frame = S_FOOBAR_ATK5; sfx = firsht }
}

# Notice since DoomPlayer is now #2 and not #17, I still need to set his
# name, otherwise it would call him a former sergeant o_O
castinfo player
{
  type = DoomPlayer
  name = "Our Hero"
  stopattack = true
}

Using the castorder Array

When editing the cast call, it will probably be advantageous to specify the castorder array. Doing so will allow you to avoid the EDF 1.0 problem of being forced to redefine the entire cast call simply to add a new cast member in the middle. It also allows you to move around existing castinfo definitions without editing them, and to omit or repeat definitions.

Syntax

castorder = { <mnemonic>, ... }

All mnemonics specified in the castorder list must be valid. If any do not exist, an error will occur.

As with other EDF lists, if the list is defined more than once, the latest definition encountered is the one used. Also, you may use addition lists to add entries to the end of the castorder list.

Full Example

# I decided to switch the cast call order around
castorder = { player, foobar }

...

# Later on, perhaps in another file, I add a new castinfo. I can do this:
castinfo weirdo
{
  type = WeirdoGuy
  name = "The Weirdo Guy"
}

# This will add weirdo to the end of the existing castorder list.
# I could also just redefine the entire list, but there's no point in this case.
castorder += { weirdo }

DOOM II Boss Brain Types

The Boss Brain thing types list allows editing of the types of monsters which can be spawned by the DOOM II Boss Brain cube spitter object. This structure is a simple list of thing type mnemonics, which are kept in the order they are provided. You can redefine the list at will, just as with the spritenames list.

Starting with EDF 1.1, there is no longer an 11-type limitation on the boss spawner list. However, if you provide more than 11 thing types in this list, you must also define the new boss_spawner_probs list, which must be a list of numbers which when added together equal 256. These numbers serve as the probability values out of 256 for the corresponding thing types. If exactly 11 types are defined and the boss_spawner_probs list is not defined, the normal defaults will be used. If boss_spawner_probs is defined, it MUST be the exact same length as the boss_spawner_types list.

Starting with EDF 1.2, if a thing type in the boss_spawner_types list is invalid, the "Unknown" thing type will be substituted for it. The previous behavior was to cause an error.

Syntax

# A list of thing types

boss_spawner_types =
{
  <thing type mnemonic>, ...
}

# A list of probabilities for the above thing types. If provided, this list
# must be the same length as the above, and if not provided, the above list
# must contain exactly 11 types. The numbers in this list must add up to 256.

boss_spawner_probs =
{
  <number>, ...  
}

Full Example

# Changed DoomImp to FooBar, and Archvile to the ScarletPimpernel
# (so it can give you a powerup, but not very often, since Archvile is the
#  rarest type ;)
# In a TC you might want to change ALL the monster types...
# These will use the default probabilities listed below, unless a
# boss_spawner_probs list is also defined somewhere.

boss_spawner_types =
{
  FooBar, Demon, Spectre, PainElemental, Cacodemon, ScarletPimpernel,
  Revenant, Arachnotron, Mancubus, HellKnight, BaronOfHell
}

Example with More than 11 Thing Types:

boss_spawner_types =
{
  DoomImp, Demon, Spectre, PainElemental, Cacodemon, Archvile, Revenant,
  Arachnotron, Mancubus, HellKnight, BaronOfHell, FooBar, ScarletPimpernel
}

boss_spawner_probs =
{
  40, 40, 30, 10, 30, 2, 10, 20, 30, 22, 10, 10, 2
}

Normal Default Probabilities Used When 11 Types are Defined:

boss_spawner_probs =
{
# prob. / thing type normally in this position in the list
  50,  # DoomImp
  40,  # Demon
  30,  # Spectre
  10,  # PainElemental
  30,  # Cacodemon
   2,  # Archvile
  10,  # Revenant
  20,  # Arachnotron
  30,  # Mancubus
  24,  # HellKnight
  10   # BaronOfHell
}