ZDoom

Tarachillax wrote: ↑Fri Jul 25, 2025 12:16 pm I’m creating a level in Ultimate Doom Builder and I can’t find a way to merge two designs on top of each other.

I have Sector A, where I only designed the floor. It has various textures, height differences, actions (like tags), etc. The ceiling is still empty and just a basic square.
Then I duplicated Sector A to create Sector B, deleted floor design and designed only the ceiling with height, texture and details.

Sector A: Only floor
Sector B: Only Ceiling

Now I want to combine Sector A and Sector B but without overwriting both. The problem is, there’s no special “overlap” function or plugin. If I drag sector B on sector A, A will get same floor like B.
I want to select the ceiling from Sector B, choose a function that only replace the ceiling and then place it over the floor design of Sector A. Brightness setting can too.

I don’t know if this is possible — that’s why I’m asking.
This function would be ideal for complex layout design without requiring too much manual work. Maybe it was already suggested before, but it's hard to implement?

Unfortunately this is how doom works as all maps are projected from 2D space. There are "ROR" type quirks (room-over-room) that try to evade this limitation in Hexen or preferably UDMF:
- 3D floors (actual sector based geometry). You select a sector area Floor at 0, Ceiling at 256, give it a tag 10 for example and create another triangle dummy sector outside the map, give it heights like Floor at 32 and Ceiling at 64, select any of its lines (1 linedef is enough), give it action 160, give it tag parameter 10 (you made earlier) and it's going to translate its properties to your tag#10 sector.
- portals:
a) line portals (vertical) - makes a vertical window passage between one wall (not strictly wall but linedef) and another. Give one linedef a tag 20, another 21, then on line#20 give it exit tag 21, and on line#21 tag 20 (interconnect them), and choose "Interactive". Make sure there must be a free space after each of them at least 32 map units but 64 is preferable. E.g. idealy, there must be a tunnel on one side and other with the same height parameters, the same textures, and before the dead end wall (white linedef that faces black void) you step those 64 units and split it with another linedef which you assign portal action to - on both sides!
b) stacked sectors (horizontal) - a bit more complex but it allows you to connect holes in floors and ceilings between different parts of the maps. Make sure that connected floor and ceiling heights must be the same.

Darkcrafter wrote: ↑Fri Jul 25, 2025 3:04 pm [snip]

Nothing about what they said indicates they want RoR. From the sounds of it, they want UDB to "merge" one set of sectors' floors with another's ceilings, and make modifications where necessary to fit. Nothing about that should require 3D floors or portals, just new editor features. (It'd have to cut some sectors up to fit together if they have different shapes, but that's nothing mappers don't already do manually to make floors and ceilings with different patterns)

My bad then. Yeah, maybe that would be nice to have such a feature but it seems like it's really hard to implement, like what's about merging errors like overlapping vertices, linedefs and etc, something very error prone.

I have noticed a minor oddity that may just be as expected, or it may be unintended. So I thought I'd check.

Situation:
A ZScript actor has a scale factor applied in its default block. For example, 0.8 to make it slightly smaller.
I then decide to replace the actor with a model, but the model is too big, so I scale it in MODELDEF. e.g. 0.5 0.5 0.5

I want to keep the original actor as it was, so that the model is optional.

Ingame, the model looks the correct size. I assume that GZDoom is able to apply both scale factors, presumably resulting in an actor/model the is 0.8*0.5=0.4 its original size. It's quite hard to tell for sure, but I think that's what's happening.

In UDB, the model appears too big and appears to be using the scaling from ZSCript, but ignoring the scaling from MODELDEF.
This does not seem to happen when actors have no scale value in their ZScript.

I can fix the model myself so that it is the size I want in the actual MD3 file, and appears the same in game and in UDB. So, it's not really an issue for me. I just thought I'd check if it was a known situation.

May I ask if we can change the shift value? For example, I want to change lighting in steps of 8.

Sorry if this has been asked before.

SuaveSteve wrote: ↑Sun Aug 03, 2025 9:31 am ...., I want to change lighting in steps of 8.

The simple answers is no.
In vanilla DOOM/BOOM the brightness is effective only in steps of 16.
For steps of 8 you have to map in UDMF.

The step size for lights is set in the game configs, so you could make a custom one with different step sizes.

In the script editor when I undo with ctrl-z it jumps to the bottom of the entire script file, although the undo function does work.

I keep getting this crashing bug if i try to save and GZDoom is still running:

Spoiler:

---

Can't reproduce with the given info. Also the error says that it happens while autosaving, not when manual saving.

boris wrote: ↑Mon Aug 25, 2025 5:06 am Can't reproduce with the given info. Also the error says that it happens while autosaving, not when manual saving.

It happens when I try to save manually while the game is still running (testing the map).
How could I help to reproduce the bug? Which info should I collect? (My configs are in Portuguese, is it because of this?)

Also, I got this one some minutes ago:

Spoiler:

---

Is there any way in UDB to have a line colour preset for lines that have been given a tag? I can only see options for flags, action and activation type

When working on a complicated map, there are obviously lots of lines, and many of them might be given tags because they will end up being given a special by a script during gameplay. However, that means they don't have a special at the time of editing, and so they just appear like standard lines (making it hard to spot them).

Nope, not possible, you can just use what's in the linedef color dialog. As a workaround you could give those line a non-existing linedef action, and create a linedef color preset for that.

Thanks. I suspected that was the case but it doesn't hurt to ask. I appreciate the confirmation.
I'll give the fake action type thing a go. Thanks again.

I have noticed that sometimes visual mode in UDB doesn't show texture alignment in exactly the same way as it appears in game. This only seems to happen with scaled textures. So, I'm assuming rounding errors of some sort (and maybe it can't/won't be fixed) but it does make aligning things difficult at times.

Here's hoping this image works. I'm trying ImgBB because I'm in the UK and Imgur is now blocked here. The thumbnail should open the full image.


If you can see it, the top-left image (with the arrows) shows the texture surrounding the switch after me pressing A and then Shift-A to align the texture horizontally and vertically. As you can see (I hope) from the visual mode preview, it looks like UDB has got its calculations wrong. The texture does not seem to be properly aligned. The texture has been scaled by a factor of 1.35 (vertically only) and all I did was apply that scale to one of the mid textures and then relied on UDB to autoscale the rest when I pressed the alignment keys.

So, the preview in visual mode looks wrong - but in game (the top-right picture) it actually looks fine (ignore the poor alignment of the textures above the arch, I just hadn't aligned them yet). So, despite showing me what looked like poorly aligned textures, UDB had got its calculations correct. It just couldn't display the result correctly.

The bottom-left image shows my manual attempt at aligning the textures. I allowed UDB to align them (as above), saw that it looked wrong and adjusted them myself. Perhaps not surprisingly, when I looked at it in game this time, what seemed like good alignment in visual mode, was actually bad alignment in game (bottom-right image).

I've had this happen a lot recently. It seems as soon as scaling gets involved, I can't rely on UDB to be showing me an accurate reflection of what will appear in game. A lot of the time, it actually doesn't matter that much but, when you are working on fiddly little bits that the player is likely to look at directly, then it becomes tricky and I have to keep dipping in and out of the game to check what things actually look like (kind of like in the "good" old days before visual editors were a thing).

There's actually another, less obvious, example in the pictures too. The switch is a 64x128 texture and the switch panel is 32x32, but its in a 24x24 hole. The texture is scaled in the map by 1.333 both horizontally and vertically. If you look closely (particularly at the bottom edge of the switch panel, but you can see it on the right edge too) there is a difference in appearance between what you see in UDB visual mode and in game. I probably should have switched off Anti-Aliasing and ambient occlusion in game to make the difference more obvious, but I think it can still be seen.

So, anyway, is this just the way it is, or can anything be done?