Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
boris

Ultimate Doom Builder with DeHackEd support - feedback wanted

Recommended Posts

Been looking forward to this! It doesn't seem to support loading external DeHackEd lumps though (like STRAIN for example). Maybe I missed something?

Share this post


Link to post
8 minutes ago, Andromeda said:

It doesn't seem to support loading external DeHackEd lumps though (like STRAIN for example). Maybe I missed something?

 

No, it doesn't. Nowadays the lumps are usually embedded in the WAD, even when they also come as stand-alone for vanilla.

Share this post


Link to post

I'm guessing that other DeHackEd utilities and supporting ports just ignore fields they don't understand, but I could be wrong about that. Anybody with port experience want to chime in before I commit to an enhancement to DECOHack?

Share this post


Link to post

That sounds great.

 

I think for adding metadata fields, the safest and most guaranteed-to-not-cause-compat-issues route is probably to use # comments in the deh patch.

 

Also, I would love to see this backported to DBX and/or GZDB-BF, since UDB refuses to run on my computer...

Share this post


Link to post

I tested arbitrary thing fields with:

  • GZDoom
  • PrBoom+
  • DSDA-Doom
  • Eternity
  • Chocolate Doom
  • Crispy Doom
  • k8vavoom
  • Woof
  • Doom Retro

It works in all of them. 4 of those have a console (GZDoom, Eternity, k8vavoom, Doom Retro), and of those 2 complain about unknown fields (GZDoom and k8vavoom). For what it's worth, Doom Retro already defines a bunch of non-standard fields.

 

24 minutes ago, esselfortium said:

I think for adding metadata fields, the safest and most guaranteed-to-not-cause-compat-issues route is probably to use # comments in the deh patch.

 

That's fine by me, too, since that's already how it's done for DECORATE/ZScript (although the editor keys there are also prefixed by "$", so that might be a good idea for metadata comments in DeHackEd, too).

Share this post


Link to post

Alright. Let us know what the final spec is, and I'll chuck it on the "issues" board for DoomTools.

Share this post


Link to post
3 hours ago, boris said:

Obviously it'd be nicer to have all things in the correct category. To achieve this the DeHackEd patch will need to supply some metadata for each thing that tells UDB what category to place the thing in, just like the editor keys for DECORATE/ZScript. 


Since nobody writes DeHackEd patches manually that will require support from @exl's WhackEd and @MTrop's DecoHack. Those tools would have to have some means to add the metadata to the DeHackEd file.

 

I propose the following three editor metadata fields (if someone has better ideas for the field names I'm all ears):

 


Editor category = <string>
Editor color = <number>
Editor angled = <bool>

How about keeping closer to the editor keys, and using metadata fields like this?

#$Category = string
#$Color = number
#$Angled = bool

Since # identifies a comment, no port should complain.

Share this post


Link to post

Even more worthy of the name Ultimate Doom Builder now. A 3D editing environment with DeHacked (and beyond!) support. Awesome. Wiki page is updated to reflect this support.

 

A few more ones to test this with:

Share this post


Link to post

This is great. Not needing to check if a custom enemy would get stuck in a monster closet every time you move it slightly is great.  

Share this post


Link to post

Some suggestions:

 

have a Frame metadata field: mainly to help differentiate between monsters using the same sprite like Specters an Pinkeys (witch use the same frame now when I load my mod)

 

respect the 2 recolor flags: In my previous mod (Pact of the Damned) I made a green monster sprite and used  TRANSLATION1/TRANSLATION2 to have a brown monster and grey monster and I would like UDB to showed that.

 

It would be nice if Dehacked lumps could be loaded separately for WIP purposes, so I don't have to put it in a wad after every revision

 

also outside of dehacked you should be able to set the friendly flag in Boom(mbf)/MBF21 file format by default.

Edited by Blue Phoenix

Share this post


Link to post
20 hours ago, Gez said:

How about keeping closer to the editor keys, and using metadata fields like this?

 

That's an option, although I'm not super fond of some of the editor keys - they could just be a bit more descriptive and less generic.

 

20 hours ago, Gez said:

Since # identifies a comment, no port should complain.

 

That's fine by me, but that could in theory pose problems, since tools usually don't preserve comments, so they'll have to interpret them and write them back later. Realistically that shouldn't be a problem here, since the only program that reads/modifies/writes the files is Whacked, as DecoHack just creates the whole patch each time.

 

7 hours ago, Blue Phoenix said:

have a Frame metadata field: mainly to help differentiate between monsters using the same sprite like Specters an Pinkeys (witch use the same frame now when I load my mod)

 

Makes sense, as there are also DECORATE/ZScript editor keys for that. Also makes sense for invisible things (like a Heretic style teleporter particle spawner). Should be a sprite and somewhat flexible, though. Should probably allow something like "TROO" (tries to figure out if there's "TROOA0" or "TROOA1"), "TROOH" (with all rotations), or "TROOG2G8" (this exact image).

 

8 hours ago, Blue Phoenix said:

respect the 2 recolor flags: In my previous mod (Pact of the Damned) I made a green monster sprite and used  TRANSLATION1/TRANSLATION2 to have a brown monster and grey monster and I would like UDB to showed that.

 

UDB doesn't do translations right now, unfortunately. And that will probably not change anytime soon.

 

8 hours ago, Blue Phoenix said:

It would be nice if Dehacked lumps could be loaded separately for WIP purposes, so I don't have to put it in a wad after every revision

 

Yes, that'd be nice. In the mean time you could set up some toolchain that automatically puts your DeHackEd patch into a WAD.

Share this post


Link to post

A very nice addition, I ran into exactly this issue when experimenting with some MBF21 stuff. I'll add it to WhackEd, when I get around to updating it (and the spec is final).

Share this post


Link to post

Either will work for me. Parsing data in comments would mean extending the parser to support that, so parsing more fields makes more sense from WhackEd's point of view. And I guess UDB's as well. But ultimately I feel that the editor-specific fields are metadata, so separating it from the actual data makes more sense from a patch file's point of view. So that would have my preference.

Share this post


Link to post

Chiming in for DECOHack: I don't mind either way, since it was said before that DECOHack recreates the full patch every time. My preference is either actual fields or commented out fields, included in the same patch file.

 

If the "actual field" route is taken, two ports will need to tweak their DEH/BEX parsers to ignore those fields, but I can't imagine that would be too difficult for them.

 

Quote

Yes, that'd be nice. In the mean time you could set up some toolchain that automatically puts your DeHackEd patch into a WAD.

DoomMake can do this out-of-the-box, more or less. I really need to start writing some tutorials for it...

Share this post


Link to post

This is incredible, been wanting this for SO long now. I’ll be testing it from today onward!

 

Just to clarify about the SS_START thing, it’s necessary for these wads to run in vanilla: the presence of a “functional” S_START lump will cause a crash. Would it be trivial to add support for SS variety markers? I know they aren’t legitimate lumps, but their usage is an extremely common convention to let modders/modding programs know “hey, these are all sprites, but vanilla Doom is dumb so I had to rename the lump”.
 

Since it’s still semi-common even today, support for it would be awesome. It’ll mean I don’t have to modify my wads/rename the lump when switching between mapping and playing!

Share this post


Link to post

UDB complains about internal DEHACKED patches that are of version 19 as opposed to 21 or 2021. It also fails to properly load custom vanilla sprites that use said DEHACKED patch to change the 4-character prefix for sprites. This is presumably in tandem with the aforementioned, along with the SS_START thing @Doomkid is talking about.

Share this post


Link to post

That version 19 problem is already fixed in the repository.

 

Replacing sprite names generally works (see the screenshots from in the first post from Rowdy Rudy, which extensively renames sprites). Or are you getting errors about UBD not finding sprites because of S_START (etc.)?

Share this post


Link to post

image.png.b5e270ae23d914fd44a8986c6b271c4a.png

 

Amazing. Thank you for this DeHackEd support, though I think it really would be useful to support having .deh files as resources, too.

Share this post


Link to post

So I came up with the following metadata fields. They are alle in comments and prefixed with the $ character. This way it will not interfere with unaware ports, and is still easily distinguishable from normal comments. Otherwise they follow the same style of normal fields, which should make parsing easy. They have to be inside a thing definition block.

 

#$Editor category = <string>
#$Editor color id = <int>
#$Editor sprite = <string>
#$Editor angled = <bool>

 

#$Editor category

 

The editor category is a string that can optionally include slashes for sub-categories. For example

 

#$Editor category = Monsters/Strong

 

would create a "Strong" sub-category in the "Monsters" category.

 

 

#$Editor color id

 

The editor color id is a number between 0 and 19 as shown in the color table. If not set it will inherit the color of the category it's in. For example it's not necessary to set the color id to 12 (Light Red) when the editor category is set to "Monsters". If no color and no existing category is given the color will default to 18 (Light Brown).

 

 

#$Editor sprite

 

The editor sprite is the full name of the sprite the editor uses to display the thing. This can be something like STIMA0 or TROOG1. For sprites that have rotations UDB will chose the appropriate rotation image. If this is not set it'll use the sprite that's associated with the "Initial frame" field.

 

 

#$Editor angled

 

The editor angled field tells the editor that the rotation (angle) of the thing is relevant. It's used to indication the thing's direction with an arror. Can be "true" or "false". If not set it'll use whatever the original thing used, or false for new things.

 

 

Full example

 

This example replaces the "Dead Lost Soul" thing with a stronger imp, puts it in the "Strong" sub-category of the "Monsters" category, gives it a different color, sets the Imp's attack sprite as the editor sprite, and sets it to be angled (since the original Dead Lost Soul thing is not set to be angled in UDB).


 

Patch File for DeHackEd v3.0
# Created with DECOHack v0.17.0 by Matt Tropiano
# Note: Use the pound sign ('#') to start comment lines.

Doom version = 19
Patch format = 6


Thing 116 (Strong Imp)
#$Editor category = Monsters/Strong
#$Editor color id = 16
#$Editor sprite = TROOG1
#$Editor angled = true
Hit points = 120
Speed = 12
Height = 3670016
Pain chance = 200
Bits = 4194310
Initial frame = 442
First moving frame = 444
Injury frame = 455
Close attack frame = 452
Far attack frame = 452
Death frame = 457
Exploding frame = 462
Respawn frame = 470
Alert sound = 39
Action sound = 76
Pain sound = 27
Death sound = 62

In UDB it will look like this:

 

grafik.png.16ec4bdf77be18daf467c30e4375f682.png

 

Tagging @exl and @MTrop.

Share this post


Link to post
On 9/6/2021 at 8:48 AM, Blue Phoenix said:

It would be nice if Dehacked lumps could be loaded separately for WIP purposes, so I don't have to put it in a wad after every revision

 

You can actually let UDB load the lump from a directory. That didn't work in R3822 due to a bug, but works in R3828 and higher. Just add a resource, select "From Directory" and point it to where your Dehacked patch is in. Note that the file has to be actually named "dehacked" (with any extension). If there are multiple "dehacked" files in the directory it'll only load the last one.

Share this post


Link to post

That looks perfect to me. Just to make sure there is no ambiguity during parsing; does the $ sign have to follow the # sign, or is something like

# $Editor category = Monsters/Strong

also correct?

Share this post


Link to post
11 hours ago, boris said:

You can actually let UDB load the lump from a directory. That didn't work in R3822 due to a bug, but works in R3828 and higher. Just add a resource, select "From Directory" and point it to where your Dehacked patch is in. Note that the file has to be actually named "dehacked" (with any extension). If there are multiple "dehacked" files in the directory it'll only load the last one.

Neat.

 

It'd still be a bit weird having to rename the .deh to 'DeHackEd.*' before editing, though, rather than simply recognising any file with a .bex or .deh extension.

Share this post


Link to post
1 hour ago, exl said:

That looks perfect to me. Just to make sure there is no ambiguity during parsing; does the $ sign have to follow the # sign, or is something like


# $Editor category = Monsters/Strong

also correct?

 

The current implementation in UDB requires that there are no whitespace characters between "#" and "$", i.e. it has to be "#$" - that just makes it a bit easier when parsing, since one can simply check if a line starts with "#$". That's also how the DECORATE/ZScript editor keys work. If there's a consensus that "# $" (or any number of whitespace characters) should be allowed too (since it does increase human readability) that's fine by me.

 

22 minutes ago, Nikku4211 said:

It'd still be a bit weird having to rename the .deh to 'DeHackEd.*' before editing, though, rather than simply recognising any file with a .bex or .deh extension.

 

That's just how resource loading from directories work in the DB2 family. it just acts like the file names before the "." are the lump names in a WAD, and since the Dehacked lump name in a WAD has to be called "DEHACKED" that's how it has to be named in the directory (with any extension, so "dehacked.deh" or "dehacked.bex" are fine, but also "dehacked.lalala", or even just "dehacked").

Share this post


Link to post

I'd rather keep it simple and stay with just #$ as the magic marker for a metadata comment, and keep on gleefully ignoring and discarding any line that starts with a # that isn't immediately followed by a $.

Share this post


Link to post
38 minutes ago, Gez said:

I'd rather keep it simple and stay with just #$ as the magic marker for a metadata comment, and keep on gleefully ignoring and discarding any line that starts with a # that isn't immediately followed by a $.

 

Agreed.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×