Ultimate Doom Builder

[Kappes Buur]

I can't download it. I tried with every browser I have. When the download was near it's end, it said the network connection was interrupted, while my internet was working fine.
Could you give me an alternate download of some sort, or fix the one here?

I assume that you have difficulties with the DRDteam server.

Try these MediaFire links

• UltimateDoomBuilder-r3844-x64
• UltimateDoomBuilder-r3844-x86

I uploaded both versions since I do not know your computer specs.
Hopefully this will work for you.

[Alpha]

I can't download it. I tried with every browser I have. When the download was near it's end, it said the network connection was interrupted, while my internet was working fine.
Could you give me an alternate download of some sort, or fix the one here?

I assume that you have difficulties with the DRDteam server.

Try these MediaFire links

• UltimateDoomBuilder-r3844-x64
• UltimateDoomBuilder-r3844-x86

I uploaded both versions since I do not know your computer specs.
Hopefully this will work for you.

Thanks!
It worked for me.

[boris]

For the 3 people that care: UDBScript was merged into the master UDB branch, a new version was released just now. Docs are here: https://biwa.github.io/udbscript-docs/. For those who don't know, UDBScript lets you write JavaScript scripts to programmatically modify the currently opened map (like DBX's Lua plugin, just different)

[dpJudas]

For the 3 people that care

Don't underestimate this feature! It may be for the advanced user, but it will also unlock them to do some amazing stuff they'd otherwise just not do! Can't wait to see what people come up with.

[Enjay]

Thanks for your continued work on UDB.

I've been meaning to say thanks for the map checking options being remembered across sessions. I know that I requested it but even I didn't expect how much of a QoL thing it would be. It really improves my workflow. Good to see the "block land monsters" line flag in the update too. I've been using it for a while (I downloaded the modified config from GitHub shortly after it was added a couple of weeks back or so) and I've already lost count of how many times I've used it. Again, much more useful than even I expected it to be.

The scripting stuff is intriguing. I'll have to look into it when I get a chance.

[CJacobsLP]

Hey there boss, excellent work on the program, the continued support is wonderful. Got a question, however: When pasting, is there an option to keep textures pinned on the pasted sectors, as with dragging them? I can't find the option, selecting "Floor Textures Transform" for example on the in-progress paste keeps the offsets but not the pin, so their offsets rocket to the multiple thousands and don't align with the original. It seems a bit useless if you're copying a series of sectors with different textures, but maybe I'm not understanding how to use it right? Please let me know!

[boris]

Yeah, that's just broken.

[Fishytza]

For a while now (since GZD 4.6.0, I think?) GZDoom has Eternity's Line_QuickPortal (301) line special. But it's not recognized from UDB's side (special 301 is treated as unknown).

It's not defined anywhere in ZDoom_linedefs.cfg

[Logan MTM]

Can't wait to see what people come up with.

Something like Actor Args name in UDB. Would be Nice!

Code: Select all

//$Arg[0] = Do Something

In UDB thing properties show "Do Something" intead Arg 0.

[boris]

Code: Select all

//$Arg[0] = Do Something

In UDB thing properties show "Do Something" intead Arg 0.

That already exists, works like this:

Code: Select all

//$Arg0 Do Something

[Enjay]

Following on from a bit of digging that I did as a result of this thread: viewtopic.php?f=123&t=74110

It seems as if UDB might not be aware of (G)ZDoom's special handling of graphics in the flats namespace that are bigger than 64x64 (or probably just power of 2 rather than just any increase in size - but I'm pretty sure that they have to be square... *I think*. So I think that 128x128 and 256x256 will do this, but 64x128 might not. *-See edit at the bottom of the post* ).


I'm mentioning this here first, rather than on GitHub because it could just be that I have missed an option or something.

Anyway, one of the early implementations of hi-res graphics in ZDoom (and therefore carried into GZDoom) was that if you put a FLAT in a WAD that was bigger than 64x64 - e.g. 128x128 or 256x256, ZDoom would auto-scale it to behave like a 64x64 flat. This was designed waaaay back in the day when importing the graphic had to be in the FLAT format (RAW or whatever that format is) but this is still supported today even if the graphic is in the PNG format (as in the above linked thread).

So, anyway, here are a couple of examples.

This UDB screenshot shows a map - with no in-map scaling and no additional control lumps - with a 128x128 FLAT used on the floor, ceiling and a wall. The graphic is just a copy of DOOR9_2 imported into a WAD between F_* markers, in FLAT format and called TESTFLT1.

Obviously, the graphic is being shown as an unscaled 128x128 graphic.

In GZDoom it looks like this:

The graphic has been scaled to 64x64 and is effectively a hi-res flat/texture. This, as far as I know, is correct behaviour.

And just for completeness, here is the same map loaded with a PK3 resource. In this case, a colour-modified (just so I could be sure I'd loaded the right one) PNG copy of DOOR9_2 has been put in the Flats folder as TESTFLT1.PNG and it works in exactly the same way as the WAD version.

UDB


GZDoom


In case it helps, the map and resource files are attached. Unpack the zip and load the FlatMap.wad with either the FlatTest WAD or PK3.

ScaledFlats.zip

(9.83 KiB) Downloaded 63 times

So, I suspect that this is an unimplemented feature in UDB but I thought I'd check here first.

[edit] I've done a bit of testing, and GZDoom only seems to scale the graphic if it is 128x128 or 256x256. Bigger powers of 2 do not scale (e.g. 512x512), non powers of 2 do not scale (tested 192x192 and a few other random values) and non square versions (even if they are powers of 2 - e.g. 256x128, 64x128 etc) also do not scale.

Also, FWiW, smaller values (32x32) do not seem to scale up either.


So, I guess the short version of all of this is:

If a graphic in the flats namespace is 128x128 or 256x256, GZDoom autoscales it to behave like a hi-res 64x64 image. However, UDB does not seem to be aware of this. [/edit]

[Logan MTM]

That already exists, works like this:

Code: Select all

//$Arg0 Do Something

Happyness define

[boris]

Yeah, I don't think UDB supports that weird scaling. That GZDoom does the scaling is actually documented: https://zdoom.org/wiki/Flat

[Enjay]

Ah, thanks. I failed to find the details in the wiki. Good to see that my testing and conclusions match the Wiki account of things.

Do you want me to open an issue for it on GitHub or is it something that there isn't any interest in adding?

[boris]

Do you want me to open an issue for it on GitHub or is it something that there isn't any interest in adding?

Yes, please open an issue.