[Open Assets] Zone Builder v3.2

[glaber]

Zonebuilder's visual mode has another problem as well.

Spoiler

As you can see, in visual mode, everything is lind up just fine. In game however.

The results are anything but as expected.

 

[toaster]

the difference is you didn't describe anything about the problem at all (not even the linedef flags or relative sector heights, the ones at the bottom not even in the screenshot) and expect it to be fixed by sight alone, whereas red described a specific feature's srb2 implementation and what he could gather from the zone builder result as much as possible

 

[glaber]

The lines in question have only double sided and lower unpegged.

This problem can also be observed around walls next to slopes, and walls next to lower floors than their neighbors too.

Spoiler

Again these lines have nothing more than the flags Double sided, and Lower Unpegged.

In the earlier post, the ceiling is at 5384 with the main affected sector (the Triangle with the misaligned textures) has a total height of 5320, with a floor of 64. Bordering sectors that could affect the lines have Total heights of "3848" and "3328". (Floor heights of 1536 and 2056 respectively)

The cave pictures in this post have the ceiling at 3200 for all sectors involved. the higher floor's sector floor height is at 1608. the lower Floors against that sector are at the following levels: "1280"(Far wall on left), "1232", "1280", "1136" (Spike pit), and "1168".

And again, no tags other than double sided and lower unpegged.

I've also noticed that for some reason, when attempting to manually align textures, the textures are locked to only be aligned by at most, their assigned texture's resolution. This was observed on linedefs with just the Double Sided flag.

Sorry for not providing enough detail earlier. I'll provide the affected level soon.

Oh one more bug, your installers still install VisplaneExplorer.dll.

 

[MK.exe]

The lines in question have only double sided and lower unpegged.

This problem can also be observed around walls next to slopes, and walls next to lower floors than their neighbors too.

Spoiler

Been geting this problem also. Its been happening since 2.4 got released (?)

 

[glaber]

Here's the level from my screen shots: https://www.dropbox.com/s/z0rdprf13zu631j/RobotowerEmeraldFlower.wad?dl=0 There may be other affected areas in the map that I didn't show, but the pictures ones are near where the player starts, and slope area around cordnates X-11616 Y2368

 

[MascaraSnake]

@glaber: I suspect I may have introduced some texture alignment bugs when I added support for texture skewing. I'll look into this.

Uno petición, por favor.

Una petición :P

In-game, when you use Repeat Midtextures and also apply a vertical offset, the texture will only repeat away from its pegging (so downward if the line isn't Lower Unpegged, and upward if it is), which is really useful for placing tall texture effects that don't fill the entire wall. ZB's visual mode doesn't reflect this, and defaults to rendering the texture across the entire wall, which is inconvenient when I'm trying to line up the effect. It'd be nice if this reflected what the game rendered more accurately.

I'll fix this as soon as I tear up the rendering code for middle textures, which has turned into an unmaintainable mess over time.

Oh one more bug, your installers still install VisplaneExplorer.dll.

Not a bug. The Visplane Explorer still exists, it's just disabled by default.

I've also noticed that for some reason, when attempting to manually align textures, the textures are locked to only be aligned by at most, their assigned texture's resolution. This was observed on linedefs with just the Double Sided flag.

This is intentional, to keep the offsets in a sane range.

 

[Prime 2.0]

But what if the wall and middle textures are of different lengths that don't cleanly divide? If it doesn't allow up to the first common multiple, then there are valid, unique configurations that are impossible.

Far more importantly though, aerial middletexture placement needs large vertical offsets to work.

 

[glaber]

To expand on what Prime 2.0 is saying, it's not just aerial midtextures, but midtextures intended for the edges of FOFs that are affected too.

Plus Visplane Explorer tries to activate every time I install Zone builder or a zone builder update. The only way I can deactivate it is to delete it.

 

[Zwip-Zwap Zapony]

I just tried, and I see absolutely no issues in changing texture offsets to have "aerial" mid-textures using the arrow keys in visual mode. Just remember to change the offsets of the middle texture, not the upper or lower textures. (Selecting the middle texture before using the arrow keys helps avoid accidentally moving a different sidedef's offsets.)

Edit: Noticed a bug. Things are colourmapped/darkened based on their Z height relative to the sector floor. Which doesn't look right when you have flipped Things in a sector partially filled with a colourmap or different sector brightnesses. (The colourmapping-ness of Things ignores whether the Thing is flipped or not.)
Observed around co-ordinates -10880 -8976 in DSZ1, with the flipped diagonal springs. Above the water, they're affected by the water's colourmap and brightness. If they're lowered deep enough into the water (increasing their Z height), they lose the colourmap, as if not flipped.

 

[MascaraSnake]

I should have been more precise: The offsets are only clamped when you use the auto-alignment tool or change them manually in Visual Mode. When you move an aerial middle texture, the Y offset is exempt from this. You do need to explicitly target the middle texture with your cursor for this to happen though. If you target the lower or upper texture and move that one, the offsets will be clamped. That can indeed be annoying and I'll try to change it. Apart from that, I can't think of a situation where you can't produce a unique offset configuration because the offsets are clamped.

Plus Visplane Explorer tries to activate every time I install Zone builder or a zone builder update. The only way I can deactivate it is to delete it.

I'm not sure what you mean by "tries to activate". The Visplane Explorer should be disabled by default. If it isn't, you can go to Game Configurations -> Modes and disable it there. But even if it's enabled, I'm not sure why it would cause problems as long as you don't use it...

Edit: Noticed a bug. Things are colourmapped/darkened based on their Z height relative to the sector floor. Which doesn't look right when you have flipped Things in a sector partially filled with a colourmap or different sector brightnesses. (The colourmapping-ness of Things ignores whether the Thing is flipped or not.)

Fixed.

As for glaber's alignment bug, I've identified the issue: When using the Lower Unpegged flag on a lower texture, the texture should be attached to the lower floor. Instead, Zone Builder displays it as being attached to the ceiling above that floor. You can easily observe this in Visual Mode: If you move the floor below a texture with Lower Unpegged, the texture will stay in place. If you move the ceiling above it, however, the texture will move along with it.

Now here's where it gets weird: This isn't a new bug. It also seems to happen in all previous versions of Zone Builder, in GZDoom Builder, in Doom Builder 1 and 2, and in SRB2 Doom Builder. Weirder yet, it also seems to happen in SRB2's OpenGL renderer. Only SRB2's software renderer and Workbench's 3D mode display it correctly. Unfortunately, that kind of limits my options. I barely understood enough of the rendering code to port the OpenGL texture skewing code to Zone Builder, but I don't understand enough to identify an issue that exists in both SRB2 and Zone Builder. I filed a bug report for it, but until someone fixes it in SRB2, you'll have to live with it in Zone Builder too, I'm afraid.

 

[MascaraSnake]

Thanks to MonsterIestyn's help, the alignment bug (as well as some bugs with texture skewing) is now fixed in both SRB2 and Zone Builder.

 

[StellarStardust]

Not sure if this is a bug or just a error on my part, but sometimes you change floors to slopes, one end is lined up with the floor next to it, while the other isn't.

 

[MK.exe]

Not sure if this is a bug or just a error on my part, but sometimes you change floors to slopes, one end is lined up with the floor next to it, while the other isn't.

Im hoping its a bug but i think its to do with the sector geometry.

 

[glaber]

if you're just useing the vertex free slopes, it's how you built the sector. I suggest you use triangles when doing slopes unless you get your intended slope first try with a rectangle or other shape.

 

[Zwip-Zwap Zapony]

Not sure if this is a bug or just a error on my part, but sometimes you change floors to slopes, one end is lined up with the floor next to it, while the other isn't.

That's an error on your part. If you set a line to be sloped, said line will be at the height of the opposite sector, while the vertice furthest away from the line (based on distance to a 90-degree angle to the line, not the middle of the line) will be at the height the sloped sector is set to. Any other vertices will be interpolated, not based on neighbour sectors, but how long their "90-degree line" to the slope line is relative to the furthest one.

Also, do note that vertices "behind" the sloped line will go in the opposite direction of the vertices in "front" of the sloped line.


Just try making an odd-shaped sector, slope one of the linedefs of it, and change its height. You'll probably/hopefully see what I mean.

 

[glaber]

Ok it looks like the Z texture alignment issue is not with Zone builder, but with SRB2 2.1.15. I'll be posting this in a bug report for SRB2 itself too.

but apparently Zone builder is correctly displaying the z alignment in visual mode and SRB2 2.1.15 is not!

As proof, here's Green flower from SRB2 the Past's Beta Quest. (See attachments)

First off is how the level is displayed in Zonebuilder. Here everything looks just fine.

Next is how it looks in 2.1.15

and finaly, how the level looks in 2.1.14

All 3 pictures use the exact same wad file.

 

[MascaraSnake]

Does the linedef in question have the Lower Unpegged flag? If so, it's actually 2.1.15's behavior that is correct and 2.1.14's that is incorrect.

 

[MK.exe]

Honestly the 2.1.15 image actually looks correct and ZB and 2.1.14 are displaying it wrong.

 

[glaber]

they both have lower unpegged, but if this is correct, why do Even Doom source ports have better Z alignment than 2.1.15?
Taken from GZDOOM:

 

[Zwip-Zwap Zapony]

they both have lower unpegged, but if this is correct, why do Even Doom source ports have better Z alignment than 2.1.15?

Because it renders lower unpegged as some sort of "attached to lower ceiling" kind of thing instead of "attached to lower floor", when it's supposed to be the latter. Or something like that, I think. Maybe the exact opposite, I'm not sure.