ZDaemon tables

[Aeyesx]

Hello!

This was supposed to be reguest so sorry if I put it into bad place (also sorry for bad eng.)

I was curious if ZDaemon tables (config) could be added? I could try write them by myself but its huge and complicated, Authors of original tables have propably 10x more practice with it. ZDaemon supports up to heretic and hexen (hexen partially but soon will be fully supported too). Using DEHSUPP we can utilize these states and actors to create custom new stuff. What is painy is that there is no other way, just to write everything "manually" in text editors. In comfy editor like WhackEd4 it's gonna be much user friendly.

Thank you!

[email protected] Skype: Aeyesx

[GitExl]

This would be interesting to add, but I would need some sort of documentation or code reference for how this works in ZDaemon. Does it define new states to be used, or does it add them base on what a DEHSUPP lump defines? I'm not entirely familiar with what exactly a DEHSUPP lump does either.

[Aeyesx]

Hi! Yay didn't expected someone is gonna ever answer Dehsupp defines new states that can be used (doom + heretic + hexen + others) allowing us to edit these (with frames up to 4900 its pretty usefull), however there is not yet official one (mostly because of unfinished works on hexen). I'll ask if doomer's dehsupp can be used as its most powerfull one. I'll reply soon if I'll get permission and gather all "docu's" and codepointer lists and stuff. Thanks

[Doomer-]

hi, DEHSUPP is a zdoom invention used as a dehacked lookup table for the engine. Basically it defines what you can modify with dehacked. Note that you cannot create new things or frames with it (ala DECORATE), you can only add items which are already supported by the engine hardcodedly. It contains lists of things, sprite names, sounds, things, flags, render styles, codepointers etc... (so. eg. you can reference a heretic sprite with a dehacked sprite number when you supply a dehsupp file along with your dehacked). The most useful parts are things, sprites, sounds and frames. I emphasize the most useful part, because there are other parts of the dehsupp file which gets ignored by Zdaemon, like the ActionList (an internal list is used instead, there might be others too but these details never made it to public). You can write your own dehsupp as a text file, then use the dehsupp compiler tool (console app) to convert it to the actual binary lump which is then inserted in a wad file. Since we are talking about lists, you might ask what are the order of the things inside the lists? EXACTLY. There is no predefined order, so each time you create a dehsupp lump, it is entirely up to you to order them as you want. So, lets say DEHSUPP1 defines the heretic knight as thing 230, but in DEHSUPP2 it is referenced to as thing 356. This also leads to a major problem which explains why zdoom devs banned the usage of custom DEHSUPP lumps. You can even redefine the order of original Doom2 things as well, completely messing up the conventional dehacked order (eg. the Player is thing 124, etc...). Of course, the few people who understand DEHSUPP and use it for modding never do this unless they are out of their minds. So, the logical move when creating your DEHSUPP is to extend the list beyond what is already defined (Doom). Because Heretic and Hexen never had dehacked support, there is no convention on how to order the new things. (for this reason, it is very rare to encounter cross compatible dehsupp lumps, unless they were explicitly written to take compatibility into consideration)

In Zdoom 1 days, it was possible to use custom dehsupp lumps for modding purposes. When DECORATE was introduced, this ability was disabled because DECORATE is far more flexible, and dehsupp is very fragile. According to devs, it was never meant for modding. DEHSUPP relies on the engine containing the defined things and frames, and if something changes internally in the engine which affects this(eg. the number of the frames of a thing) it causes all sorts of problems with the wad including the dehsupp file (like pointing to non-existing frames, crashes, unwanted behavior etc..) Zdaemon however(being based on 1.22-23) still allows to use custom dehsupp lumps so modders there have greater flexibility with dehacked.

Here is my dehsupp which is currently up to date with recent Zdaemon changes: http://destiny-server.no-ip.org/stuff/dehsupp_zd110b1.zip

I use the very same dehsupp in my (and my brother's) coop wad TEH BASE, you can see it in action on Zdaemon Destiny-Server.

Also, I have written a tool in java which creates documentation out of uncompiled(text) dehsupp files called DDG: http://forums.zdaemon.org/viewtopic.php?t=15968

Considering all of the above, I think the most useful thing to have would be a program which creates WhackED tables from dehsupp text files, since there is no agreed upon standard dehsupp, and would be pointless to have as long as Zdaemon keeps adding new things.

[Aeyesx]

This is starting to appear hella difficult xD In whacked there is no interface to define "unkown1 / 2" fields or ARGS + zd had backported even some decorate codepointers.

[GitExl]

After taking a quick look at the dehsupp text, it looks like it would be realtively easy to add support for in WhackEd4. I'll put this on the list for version 1.1 that I've been working on.

[GitExl]

Having looked more closely at this, there is something missing to create table files from dehsupp data. There are no thing editor numbers, radius, height and health values for the non-Doom things. Likewise for the states and sounds there are no properties known about them either. Is there somewhere that I can find what these are in ZDaemon?

[Doomer-]

I can supply the zdaemon 1.06 source code for heretic things, as well as things like splashes, scripted marine and things shared between heretic/hexen (raven).

http://destiny-server.no-ip.org/stuff/a_scriptedmarine.zip http://destiny-server.no-ip.org/stuff/a_splashes.zip http://destiny-server.no-ip.org/stuff/g_heretic.zip http://destiny-server.no-ip.org/stuff/g_raven.zip

I don't have source files for Hexen things though. Kilgore said however, that he implemented those according to Zdoom wiki (I used it as well to add them to my dehsupp). Now that you mention thing editor numbers, Zdaemon has couple additions to dehacked which makes working with actors from different games easier. Might be worth adding these to WhackED as editable fields. Snippets from the changelog:

1. Implemented 2 new dehacked thing properties: SpawnID #= , where value can be 0-255. Game = , valid names are "Any", "Doom", "Heretic", "Hexen" and "Raven". SpawnID is used in line specials like Thing_Spawn. Game is used for changing the game an actor belongs to.
2. Implemented new dehacked features:
   1. Added heretic armor classes to dehacked misc section. The properties are "Silver Armor Class" and "Enchanted Armor Class".
   2. Made armorclass values fixedpoint, eg. "Green Armor Class = 1.5" will give 150 armorpoints.
   3. Mixed Doom and Heretic armorlists, it's now possible to have 4 different armors in doom or heretic.
   4. Added 3 thing state types "Burning death frame", "Ice death frame" and "Crash frame".
   5. Added support for MBF-style codepointer Spawn. It uses the frames "Unknown 1" field as the dehacked thing number to spawn, and the "Unknown 2" field as the height relative to the thing to spawn.
3. Added support for MBF-style codepointer PlaySound. It uses the frames "Unknown 1" field as the dehacked sound number to play, and the "Unknown 2" field as either 0 for normal attenuation, or 1 for no attenuation.
   1. Added a new dehacked FireCustomRailgun codepointer. It uses the frames "Args1" and "Args2" fields for the Damage and offset of the railgun shot.
4. Implemented a new DeHacked thing property for items: "Respawn time", it takes a tic value, which if bigger than zero, overrides the respawn delay for that item.
5. Implemented three new Dehacked global properties (Misc section):
   • Vampire Max Health: specifies the max. health reachable via vampire. Defaults to 200.
   • Vampire Player Factor: specifies the vampire scale factor applied to damages on humans/bots. It's a percentage value defaulting to 50 (%).
   • Vampire Monster Factor: specifies the vampire scale factor applied to damages on monsters. It's a percentage value defaulting to 25 (%).
6. Added the CLIENTSIDE flag to dehacked; objects having that flag move independently on the client (no bandwidth is consumed for their movement).
7. Added the CLIENTSIDEONLY synonym to the CLIENTSIDE dehacked flag.
8. New dehacked flag called "SERVERONLY"; any object having that property will spawn on the server (so it can do whatever it's supposed to do), but the spawn & movement will not be sent to the clients. This is useful for objects that need a single, authoritative instance (running on the server) as opposed to many instances (one on the server + one on each client). Objects related to game logic can benefit from this flag. The principal difference between this flag and the CLIENTSIDE flag is that CLIENTSIDE tells the clients than the object has been spawned, but doesn't send movement afterwards (so the client has to move it), whereas SERVERONLY does not tell the clients anything about that object (so it exists only on the server).

The following changes are included in the upcoming release of Zdaemon:

1. Extended the number of possible Args in dehacked frames to 9 (Args1...Args9). This will be useful in future extensions.

2. Implemented several new MBF-style codepointers; they're inter- faces to the ACS scripting functions and they're designed to allow controling ACS scripts from dehacked. For each relevant ACS function, there are 2 codepointers: one strictly for actor frames (names starting with CPA_), the other strictly for weapon frames (names starting with CPW_). All the codepointers take their parameters as Args1...Args5 in the order used by the ACS function that they call. Here is the list:

   a. CPA_Execute, CPW_Execute: they map to the ACS function: ACS_Execute(script, map, s_arg1, s_arg2, s_arg3) Since ACS_Execute takes 5 parameters, the codepointers use Args1...Args5.

   b. CPA_ExecuteAlways, CPW_ExecuteAlways: they map to the ACS function: ACS_ExecuteAlways(script, map, s_arg1, s_arg2, s_arg3) Since ACS_ExecuteAlways takes 5 parameters, the codepointers use Args1...Args5.

   c. CPA_LockedExecute, CPW_LockedExecute: they map to the ACS function: ACS_LockedExecute(script, map, s_arg1, s_arg2, lock) Since ACS_LockedExecute takes 5 parameters, the codepointers use Args1...Args5.

   d. CPA_LockedExecuteDoor, CPW_LockedExecuteDoor: they map to the ACS function: ACS_LockedExecuteDoor(script, map, s_arg1, s_arg2, lock) Since ACS_LockedExecuteDoor takes 5 parameters, the code- pointers use Args1...Args5.

   e. CPA_Suspend, CPW_Suspend: they map to the ACS function: ACS_Suspend(script, map) Since ACS_Suspend takes 2 parameters, the codepointers use Args1...Args2.

   f. CPA_Terminate, CPW_Terminate: they map to the ACS function: ACS_Terminate(script, map) Since ACS_Terminate takes 2 parameters, the codepointers use Args1...Args2.

3. Implemented an MBF-style codepointer RandomJump. It can alter the execution path of actors depending on a random drawing. One uses the "Unknown2" parameter to specify the desired probability (N / 256) of a jump to the frame specified by the "Unknown1" parameter. If for example, Unknown2=192 and Unknown1=14, it means we want the actor to jump to frame 14 with a probability of 75% (192/256) or to the next frame otherwise.

4. The FastChase codepointer can now be accessed from dehacked.

[Aeyesx]

http://www.speedyshare.com/ZP2AX/actors.7z

There is list of actors (source) that Kilgore gave me. (hexen, heretic, rave) They should match last changes maybie even beta03. They're not SAME always like zdoom, aka there are 3 projectiles with "fastprojectile" this mechanism is not implented. Also hexen leaves got clientsideonly codepointer (zdoom not)

[GitExl]

That complicates things, but it's still doable. This will take some time, so don't look forward to full ZDaemon support before christmas. :) Is there also info available for the priority and singularity properties for the sounds table?

[Doomer-]

No info on sounds that I could find. Zdaemon dehacked source file tells however that the sound section is entirely disabled:

// The only remotely useful thing Dehacked sound patches could do // was change where the sound's name was stored. Since there is no // real benefit to doing this, and it would be very difficult for // me to emulate it, I have disabled them entirely.

The sound list in DEHSUPP is useful on the other hand, because if you add sounds there defined in SNDINFO, you can reference to it with a dehacked sound number. This is good with PlaySound codepointer, where Unknown 1 field controls which sound to play (only integers are accepted, as it is a frame property). Eg. you could define some fancy sound in SNDINFO, add it to the end of the dehsupp sound list, and you can reference to that sound with number 109 (108 is DSRADIO). This way you don't need to replace doom sounds to use new ones with PlaySound.

Thanks for your work on this!

[GitExl]

I did some preliminary work on it before the holidays, but right now I'm busy with other stuff. It'll get done when it gets done :)

On 21-Jan-15 15:44, Aeyesx wrote:

That is true, no need for sounds section of heretic/hexen/raven. Anyway, how it's going ? I think it'll be great for chick modders, + I'll hope doomer's dehsupp could be official someday (after hexen get finished) in zdaemon.wad

— Reply to this email directly or view it on GitHub https://github.com/GitExl/WhackEd4/issues/1#issuecomment-70848820.

[GitExl]

I'm working on completing version 1.1 which includes support for most ZDaemon\ZDoom features (but not yet DEHSUPP). A few things aren't yet 100% clear to me:

The ZDaemon binary has strings for a number of action functions in it. Some are the same as their MBF counterparts and were easy enough to add, but the parameters\usage of the following aren't quite known to me:

• FireRailgun
• FireRailgunLeft
• FireRailgunRight
• Gravity
• HideThing
• LowGravity
• MonsterRail
• NoGravity
• PlayWeaponSound (same as PlaySound but for weapons?)
• RailWait
• SetFloorClip (this one and other Set\UnSet actions change thing flags?)
• SetInvulnerable
• SetReflective
• SetReflectiveInvulnerable
• SetShootable
• UnHideThing
• UnSetFloorClip
• UnSetInvulnerable
• UnSetReflective
• UnSetReflectiveInvulnerable
• UnSetShootable

Likewise in the ZDaemon binary the string "BFG Aiming" appears alongside miscellaneous value strings. What does it do?

Lastly, there's strings for a lot of thing flags in the ZDaemon binary that do not appear in it's default DEHSUPP lump. See http://pastebin.com/8LGFn3Vu for a list of these, a number of which I've identified through the ZDoom source code. Unknown ones are on the very bottom of the list. Am I right in assuming that these thing flags are all supported by ZDaemon's Dehacked parser?

[Aeyesx]

Few of them are it's Decorate equialents, few comes from hexen / heretic, BFG Aiming is a variable used in dehacked that simply specify if bfg can shoot Up&Down or does not.

I'll edit you're pastebin in few minutes hopefully explaining what it does... Either i am not certainly sure about few so I have to ask >) But heck thanks for the effort ! It is cool

[Doomer-]

Hello,

the codepointers you listed can be found on the zdoom wiki: http://zdoom.org/wiki/ZDoom_codepointer_extensions

Only MF1 and MF2 flags are supported by Zdaemon's dehacked, as far as I know. The MF3 and MF4 are Hexen and other special flags, they cannot be used by dehacked.

There is a recent addition:

1. Added a "SYNCMOVEMENT" flag to dehacked; it can be used for projectiles having idiosynchratic/randomized movement that need frequent "driving" from the server to the clients (use it with restraint though: it consumes more bandwidth than normal projectiles).

CLIENTSIDE, CLIENTSIDEONLY are the same and explained in one of my previous posts, as well as SERVERONLY.

Set and UnSet codepointers are used for setting/unsetting the actor flag in question, though they not yet work in Zdaemon. No harm in adding them though.

The TRANSLUCXX flags just set the actor's translucency to the said percentage. FRIENDLY flag is a work in progress which allows to make monsters friendly towards the player, and attack other monsters.

The others are less important flags, or unknown/not yet supported.

PlayWeaponSound is a Zdaemon exclusive codepointer which is similar to PlaySound but it is used on weapon frames, not on actor frames. The reason for needing both codepointers is that codepointers used on actor frames don't work on weapon frames and vice versa. This is an engine limitation of Zdoom 1.22 based ports.

1. Implemented an MBF-style codepointer A_PlayWeaponSound. It's similar to A_PlaySound, except that: a. it applies to weapon rather than actor frames, b. it uses the weapon rather than the body channel, c. it uses Args1/Args2 rather than Unknown 1/2 for the sound number and attenuation flag respectively (Unknown 1/2 are used for the animation in weapon frames).

BFG Aiming specifies wether you can or cannot control the vertical angle of the bfg ball when firing. By default, the BFG ball is always fired straight ahead no matter if freelook is enabled (for some oldschool reasons). This setting allows BFG ball to behave the same as other player projectiles when set to 1.

[Aeyesx]

+1 Great explanation as always doomer, I wish to be accurate like that someday either >D

[GitExl]

That's very helpful, thanks. I'll add the thing flags that are present in ZDaemon's DEHSUPP, as well as the CLIENTSIDE, CLIENTSIDEONLY, SERVERONLY, SYNCMOVEMENT and FRIENDLY flags. Also the ZDoom codepointer extensions abd OlayWeaponSound. Anything else I consider undocumented and untested, so best not to include at this point.

[Aeyesx]

Could you left the "undocumented/untested" list please ? o,o I am curious of them, CLIENTSIDE is de-facto just a synonym for a CLIENTSIDEONLY... I guess use the longer variant as it is used either in zandronum/skulltag for compatibility purposes,

[Aeyesx]

Update: http://www.zdaemon.org/?CMD=info&NAME=deh_cptr_actor < Actor codepointers http://www.zdaemon.org/?CMD=info&NAME=deh_cptr_weapon < Weapon codepointers http://www.zdaemon.org/?CMD=info&NAME=deh_thingflags < Thing flags

A lot of things happening. Also there is by now official dehsupp, which doomer will provide hopefully.

[GitExl]

Great, those lists are perfect! I've made some headway with ZDaemon support a few months ago, most things are done except for extended thing flag editing and some testing\polish. It may still be a while, but I'll get around to it sooner or later.

[GitExl]

I've finished working on the extended features. There's a beta release that includes a ZDaemon configuration that supports all the new features in ZDaemon thus far: https://github.com/GitExl/WhackEd4/releases/tag/v1.1.0-beta

Since a lot of internal things have changed, there will certainly be bugs and such, so keep that in mind when you test it out. Also please let me know if I got the ZDaemon features right!

[Aeyesx]

An awesome piece of work! The options are just tip-top containing everything so far I've seen. I'll put this on ZDaemon forum later, I have to thanks you a lot this will be very very handy for those who are not familiar with manual zdaemon mapping.

By the way... About DehSUPP it does not contain any extended states/weapons(up to 31)/or things... Why? It makes sence to me since there is no official one. (Which is kinda shame, but there's one already ready maintained by doomer but it's nowhere announced so who knows how this will end). Yet, when I imagine Slade... Would it be possible to load dehsupp source or content or even better convert those? (this is already real luxury) whatever lets see

[GitExl]

Adding things from a DEHSUPP lump is something I'll probably do in a later version. Using an "official" DEHSUPP as the source for the data would be gooed, but perhaps I can create a script or tool that can convert any DEHSUPP lump into a useable WhackEd table. But that's for a next version.

[Aeyesx]

That would be very very cool,

Imagine how time passes many people coded various monsters/weapons/objects based on different dehsupps's, This is its negative side, since you cannot use those anymore or mix them up. There's TNSTeam library that suffers a lot from it, but re-writing it would take month.

[Aeyesx]

ZD Beta07 went out, i guess itll slow down by now, how nice to have things in one place.

[MaiklRussia]

Hello everyone! :) GitExl, DEHSUPP support in winhacked will be MOST USEFULL feature! Very very very waiting for this!!!!!

Also i found a couple of bugs.

1. when try to select PlaySound action in States list:

Traceback (most recent call last): File "src\whacked4\ui\editors\statesframe.py", line 674, in set_action File "src\whacked4\ui\editors\statesframe.py", line 496, in set_param_visibility KeyError: 'name'

1. when try to select PlayWeaponSound action in States list:

Traceback (most recent call last): File "src\whacked4\ui\editors\statesframe.py", line 674, in set_action File "src\whacked4\ui\editors\statesframe.py", line 511, in set_param_visibility KeyError: 'name'

[GitExl]

Thanks for the report MaiklRussia. To fix that, replace whacked4\cfg\tables_zdaemon.json with the one from this ZIP file to fix that: tables_zdaemon.zip

There's a similar bug in the MBF configuration, this JSON file fixes that one: tables_mbf.zip

[GitExl]

Not yet, no. I've reserved that for 1.2, but I don't know when I'll get around to working on that. On Dec 19, 2015 09:33, "MaiklRussia" [email protected] wrote:

Hello everyone! :) GitExl, Is 1.1.0 version of winhacked not support DEHSUPP yet?

— Reply to this email directly or view it on GitHub https://github.com/GitExl/WhackEd4/issues/1#issuecomment-165960848.

[MaiklRussia]

BTW, is it possible add Heretic to winhacked?

[Aeyesx]

Dude, doomer's official ZD dehsupp already supports all states, however Whacked4 cannot load any Dehsupp atm. but by default it might be able to so it can convert old ones into new one, and people will create stuff that would be compatible across wads... That's why I was tellin ya not to use JCD's one.

[MaiklRussia]

I mean vanilla Heretic, not Heretic actors in Doom.