Ultimate Doom Builder

[boris]

It's a bug. both the horizontal and vertical scales get rounded, but the vertical one then gets converted from a double precision floating point number("double") to a single precision floating point ("float"). And in that process it loses some accuracy. It's probably a remnant from when UDB was moved from using floats to doubles.

[Enjay]

Well, that would explain it. Thanks for the answer.

[Enjay]

A question about texture alignment - in a specific circumstance.

I noticed when making a map that has 3D floors and railings along the edge of the 3D floors, that letting UDB align the railings (Y direction) can unalign the railings instead, if there is a ceiling height difference. So, I was wondering if there is a way around this?

To explain.



The highlighted midbars have been aligned manually to sit on the 3D floor (to look like railings along the edge). You can also see that there is a ceiling height difference in the sectors. If I press Shift-A to align the railings vertically, what will happen is what you can see in the background: the railing in the lower-height sector will remain at the correct height but the ones in the taller sector go up to the ceiling. It only seems to happen on the outer edge of the 3D walkway. The sidedefs facing inwards remain aligned. It also doesn't happen when there is no 3D floor - just railings hanging in the air. So, I'm guessing that UDB is having problems with the 3D floor edge versus the railing and figuring out what to align (though, as you can see, I have selected the railing textures, and not the side of the 3D floor). So, I'm guessing it's not a bug as such, merely a limitation, but is there a way to stop this happening? Several times I have accidentally unaligned my railings (in far more complicated maps than this) and had to re-align everything manually again.

Map is attached. The southern bridge has the bars manually aligned. The northern bridge was manually aligned, but then I used UDB's Y-align and the outer railings became unaligned.
The railings in the map are non-blocking to allow easy walking on/off the bridges.


Edit: I think I have a workaround/solution. If I press Tab in 3D mode to remove GZDoom features, the 3D floors disappear and the railings can be aligned how I want by pressing shift-A. I can then press Tab again top bring the 3D floors back. I'm not sure if that's the intended way, but it seems to work.

[boris]

Should be fixed, and maybe I didn't break anything in the process.

[Enjay]

So far so good anyway and, as ever, your efforts are appreciated.

[Ravick]

This crashing bug haunts me.

It happens when I try to type the name of a texture.

[boris]

Known problem. Never happened to me, and in fact it should be impossible to happen. So I can't fix it.

[dpJudas]

It is probably due to a race condition. Many years ago I tried to fix the threaded loading of images in UDB which was done completely wrong. The code basically didn't lock access to shared variables and it created win32 objects (such as System.Drawing.Bitmap) on worker threads while the win32 GDI object model is built on the apartment thread model. I guess I must have missed a spot since its still happening.

The image loading code in UDB is some of the worst code I've ever seen, so don't expect anyone to fix this. Only way to really do it would be to rewrite most of it to be perfectly honest.

[boris]

In all the reports it's the "UnknownImage", not some random texture. And the UnknownImage is loaded when a map is created/loaded, and not when it is needed, like textures. And the weird thing is that it seems to happen to some people regularly, and never to others.

[dpJudas]

The key question here is whether "new Bitmap(loadbitmap)" is thread safe or not, since it might be both the UI thread and the background loader thread could be calling it. Not even sure if using Properties.Resources.UnknownImage directly instead would be safer. The way Microsoft implemented their GDI integration in .NET is really a guide in Don't Do That for how to manage resources in a garbage collected language. I suppose one could try throw a lock(loadbitmap) into LocalLoadImage and GetPreview to see if it fixes the problem or not.

[Enjay]

Is there any way, built-in or a plug-in, that helps you search for joined sectors?

Normally I just sweep the mouse over the map and it's pretty obvious when two separate areas highlight at the same time. Unfortunately, however, I'm working with an old map where I used an auto-merge-sectors tool (because, back in the day when it was important, it could reduce the size of a WAD file). Now I want to split them all up, but the map is big and has a lot of details. So, it's really hard to spot little areas that might highlight across the other side of the map when I'm zoomed out really far.

[Enjay]

While I'm on, I've been having difficulty Y-aligning textures on 3D floors.

The following is an example.

In-game view:


UDB 2D view:

Blue arrow shows the direction of view in the game pic.

The in-game pic is looking from a sector that is a lift, and the lift is lowered. Below the red line is a support-like texture that is only exposed when the lift is lowered, above the red line is the wall that is visible when the lift is in the up position. This split is done with a 0-height sector with its floor and ceiling at the height of the lift floor. So, everything above the red line is an upper texture, everything below is a lower texture.

With one exception - the little panel highlighted with the green arrow is a 3D floor to allow the appearance of a 32x32 switch recessed into the wall.

All fine, all good. However, if I select the techy panel and the front of the 3D floor and press the key-combo to Y align textures, UDB will get the alignment of the front of the 3D floor wrong and it has to be fixed manually.

This has cropped up in many situations where I want to align a texture on a 3D floor with some traditional architecture. Is this a known "you can't do that" limitation, something I'm getting wrong or an actual problem?

[boris]

Joined sectors: there's nothing built-in to find them, but you can use this simple script to list them:

Code: Select all

/// <reference path="../udbscript.d.ts" />

`#version 5`;
`#name List Joined Sectors`;
`#description Lists all joined sectors in the map.`;

UDB.Map.getSectors().forEach(s => {
	if(s.getLabelPositions().length > 1)
		UDB.log(s);
});

If you just want to split all joined sectors an easy way is to make sure to set the merging mode to "Merge Dragged Geometry" or "Replace with Dragged Geometry", select all sectors, press E to enter Edit Selection Mode, and just press enter (or left click on the space outside the selection rectangle).

3D floor alignment: there's definitely something fishy going on. When you have multiple sidedef (parts) selected it'll always use the currently highlighted one as a base to align the other textures to. And when you have the non-3D-floor one highlighted it'll not apply the correct offset to the 3D floor, and pressing the Y alignment key multiple times makes the texture on the 3D floor will jump up and down each time. A workaround seems to highlight the 3D floor as a base (i.e. highlight it), then it seems to work as expected

[Enjay]

Thanks for the answers. I'll give the script a go tomorrow.
[edit] The script worked like a charm. Exactly what I needed. I found far more split sectors than I thought there were, and was able to leave the ones alone that I wanted to keep split.
Once again, thank you.[/edit]

In this case, I don't want to separate all joined sectors, because some are needed for various effects, but I'll bear that solution in mind too.

Thanks also for the tip about the 3D floor alignment. Unfortunately, in most cases I've come across, it's been easier to get the other textures right and (if it was working) have UDB align the 3D floor to the other textures. Like in the attached pic, the 128-tall techy sidedef was easy to align because it was the exact right height and has some obvious features on it. It was less obvious with the panel on the 3D floor because it looks like this:

So, it was hard to spot when the correct panel was in the right place but, in game, it becomes obvious when you've got the wrong one because the subtle differences in the vertical shading on the SHAWN-like texture do show up when they are side by side.

At least I know it's not just me, and I can use the tip in some situations.

Again, thank you.