Hey
This topic tries to explain few things and clarify some misconceptions about dehsupp lump.
The other main idea, suggested by many, is to make a common official dehsupp instead of having every modder coding his own dehsupp, with all informations in one place. This will allow all of us to have a proper-fine-tuned dehsupp source based off the real code that is now opensourced thanks to Kilgore, without quirks, flaws etc.

What is DehSUPP
It's a lump of table definitions for actors, sprites, sounds for the engine. It can add new sounds or tamper existing ones. It cannot add entirely new actors, but will allow to use hexen actors, frames etc. in doom and vice-versa. It's the only ability to add new content in mods in ZDaemon and something people outside ZD are afraid to touch. Those are ment to be edited using DeHackEd. It has to be compiled using a compiler (which also serves as decompiler)

Some history
DehSUPP was ment to be an internal lump in zdoom engine beign created around year 2004, but later was made to be used by more advanced mappers for advanced defintions. It had a very short lifespan as it was quickly deprecated in year 2006 as Decorate took over.

Current shared one
These will get updated whenever it gets necessery and are maintained by community. Feel free to submit changes with compatibility in mind.

v1.2 (9.4.2018)
- Fully restored DeHackEd compatibility.
- Fixed correctly FirstStat* on every heretic, hexen, zdaemon weapon. (Which is against common sense, but it works correctly this way, before you wouldn't be able to pickup a weapon)-
- Extended infonames

This update is crucial.
Because of these changes the entire frame set was shifted.
This is one of these bad cases when something happens to be wrong.
Existing DeHackEd code have to be redefined.

How to use it
Simply click and download the binary or build your own by compiling the fresh source using compiler.
Place it inside your WAD and you can start using extended frames and other things.
If you can't see the icons don't panic it just means my server is dead for whatever reason. (or my ISP again cutoff)
It will eventually get on.

Please note! Altough ZDaemon allows dehsupp modding it comes with a risk that state tables may change in future updates, this could break your mod's. To avoid that you may wan't to use only heretic states unless you are willing to keep updating your mods.

Do not use dehsupp's created for other ports. Obviously, they will not be compatible!

The original dehsupp made by grubber for zdoom can be found HERE.
All the tools you may need are available on ZDaemon Editing Tools page.

// 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)

// 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{};

Last edited by Aeyesx on Sun Aug 05, 2018 6:06 pm; edited 12 times in total