DEHSUPP

From DoomWiki.org

Revision as of 08:14, 21 June 2021 by Redneckerz (talk | contribs) (Revision: Remove stub. Include links + description of DEHSUPP table as used by ZDaemon. Main ZDaemon article will link to this page.)


DEHSUPP is a lump introduced by ZDoom that is used to add things to the list of actors and weapons that can be modified by DeHackEd. By compiling a DEHSUPP lump using the associated utility and inserting it into a WAD file, DeHackEd patches can reference things from Heretic, Hexen, and even Strife. It should be noted that DEHSUPP does not do anything by itself, and must be used in conjunction with either an internal or external DeHackEd patch that takes advantage of the new references.

DEHSUPP is now considered deprecated amongst the ZDoom community, as DECORATE now covers the creation of new actors and weapons. The lump itself in ZDoom is now in a text format, but only the one in zdoom.pk3 will be loaded, and if a DEHSUPP lump is present in a wad loaded, it entirely deactivates DeHackEd support for the session.

ZDaemon implementation

DEHSUPP modding has been embraced by the ZDaemon community, since this port is based on a version of ZDoom that predates DECORATE.

The DEHSUPP table as used by ZDaemon is as follows:

///////////////////////////////////////////////////////////////////////////
// C O D E B L O C K S      U S E D     B Y     Z D A E M O N 
///////////////////////////////////////////////////////////////////////////

// Sprite names in the order Doom originally had them.
// These are actually fully used by ZDaemon 1.10.
// The default DOOM2 order cannot be redefined.
// You cannot add new ones. If you try ZDaemon will switch and use default ones.
// However you can define all existing within the engine so you can actually use all of them in DeHackEd,
// after the default DOOM2 one's.
// Note that you can rename sprites in DeHackEd (Text 4 4 feature) - Aeyesi/Medis

OrgSprNames{};

// StateMap defines which frames are available,
// so you could have all the frames available without being able to reference the thing
// it belongs to, if you don't have the thing added to infonames

StateMap{};

// Sound equivalences. When a patch tries to change a sound,
// use these sound names.
// Those are fully used by ZDaemon for a long time.
// It seems you cannot re-define the default 108 sounds order (They are hardcoded).
// You CAN add new custom ones after the 108 original ones. - Aeyesi/Medis

SoundMap{};

// Names of different actor types, in original Doom 2 order
// Those are the actual "Things". You can only define those
// known to engine.

InfoNames{};

// RenderStyles, should match those in actor.h
// They ARE used and ZDaemon reguires them.
// If not defined, RenderStyles won't work.
// (some are actually defined in zdaemon.wad/dehsupp)

RenderStyles{};

///////////////////////////////////////////////////////////////////////////
// C O D E B L O C K S     U N U S E D     B Y     Z D A E M O N
///////////////////////////////////////////////////////////////////////////
// Let's bust those myths!

//  This is a list of all the action functions used by each of Doom's states.
//  Also note from ZDaemon changelog 1.09b28 release (2012-08-31)
//
//    66. Fixed dehacked frame pointer definitions. Dehsupp ActionLists are now
//          ignored, and an internal list is used instead. Adjusted the code so
//          that the internal order of the codepointers no longer matters. This
//          fixes the issue with dehacked codepointers using the action list.
//
//  I recently (5.3.2018) verified that this list is completly ignored by ZDaemon 1.10
//  and thus can be fully removed and should not be used.. (unless you target other engine)
//  There was a little of use (unless it defined stuff for engine itself in the past).
//  You can always edit those using DeHackEd via [CODEPTR] - Medis/Aeyesi

ActionList{};

// What it seems like this defined of which codepointers (actions) were aviable.
//  I recently (5.3.2018) verified that this list is completly ignored by ZDaemon 1.10
//  and thus can be fully removed and should not be used.. (unless you target other engine)
// 
//  ZDaemon uses separated actions for WEAPONS / ACTORS without the need to define them.
//  Please follow http://www.zdaemon.org/?CMD=info&NAME=deh
//  - Medis/Aeyesi

Actions{};

// These are the original heights of every Doom 2 thing. They are used if a patch
// specifies that a thing should be hanging from the ceiling but doesn't specify
// a height for the thing, since these are the heights it probably wants.
//
//  I recently (5.3.2018) verified that this list is completly ignored by ZDaemon 1.10
//  and thus can be fully removed and should not be used. (unless you target other engine)
//  You can primarly edit those using DeHackEd - Medis/Aeyesi

OrgHeights{};

// DeHackEd made the erroneous assumption that if a state didn't appear in
// Doom with an action function, then it was incorrect to assign it one.
// This is a list of the states that had action functions, so we can figure
// out where in the original list of states a DeHackEd codepointer is.
// (DeHackEd might also have done this for compatibility between Doom
// versions, because states could move around, but actions would never
// disappear, but that doesn't explain why frame patches specify an exact
// state rather than a code pointer.)
//
// To shorten your thinking this was some sort of conversion for original doom2.exe
// And is certainly ignored by ZD... ancient thing and does not have to be used - Aeyesi/Medis

CodePConv{};

// Seems like a list of thing flags that were aviable for the engine
// Most likely unused. Define flags in DeHackEd instead.
// Please follow http://www.zdaemon.org/?CMD=info&NAME=deh
// - Medis/Aeyesi

ThingBits{}; 

External links