Does anyone know whats going on with this bridge?

[Ashurion Neonix]

So i was trying to create a floating brigde using self-referencing sectors and for some reason upon raising the bridge there was an area above the moat that for some reason I could stand on. It's not the same height as any of the other sectors on the map and it moves relative to the bridge. This happens everytime I try yo make a floating bridge. Also If someone could explain how to fix the flat bleeding on the transparent door that would be great. Thanks.

(Map is Map02 by the way)

Download link:

https://drive.google.com/file/d/1QJbZPu9yk-vo3JnsZ0MtyDZXIDIzZW9p/view?usp=sharing

No, I'm not using the fly cheat, This actually counts as solid ground for some reason.

[Doomkid]

Make sure you do all your testing in software mode, the doorway looks like this on my end:

 

 

Oddly, I couldn't replicate the bug you're demonstrating, but if you really want to be sure the bridge in no way bleeds into the water sectors, you could make a slightly smaller square sector within each water sector, just indented by a pixel or two.

 

The borders of this "useless sector" will actually always serve as a barrier for bleeds, meaning even if the self referencing sectors do end up bleeding, the bleed will be cut off after just one pixel, effectively fixing the problem.

 

[Ashurion Neonix]

Thanks. I was inspired to make the floating bridge by valiant (map 28) Also I checked and the bridge bleeding doesn't carry outside the room. Still have no idea why this happens but it somehow manages to appear every single time I make a bridge.

[Doomkid]

Using an empty smaller sector as a dummy to simply block the bleeding should hopefully be a bubblegum fix that works every time. If you have any more troubles with it just give a shout. Self referencing sectors sometimes (but not always) bleed beyond their own linedef boundaries, though I'm not sure what's the technical reason behind it.

[Fonze]

My experience aligns with what doomkid has said; just line the self-referencing sector with a thin sector(s) to stop node bleeding.

[Ashurion Neonix]

On 9/23/2020 at 4:12 PM, Doomkid said:

Using an empty smaller sector as a dummy to simply block the bleeding should hopefully be a bubblegum fix that works every time. If you have any more troubles with it just give a shout. Self referencing sectors sometimes (but not always) bleed beyond their own linedef boundaries, though I'm not sure what's the technical reason behind it.

It got worse.

[Aurelius]

Looking at the first map, the issue was present only in GZDoom. So, like Doomkid said, you should be testing your map with the intended port. No other source ports besides GZ had issues, and I believe that in most cases encasing your self ref sector within another sector that prevents bleeding is the best way to go. To figure out the effect in the last shot, I'd need to look at the map itself. Could you share the wad?

 

Just to make sure, what is the format you're aiming for? If it's supposed to be vanilla, then self refs for sure. But if you're making a non-vanilla map (Boom or UDMF) then I suggest you use either line action 242 Create Fake Ceiling and Floor (for Boom) or line action 209 Transfer_Heights for UDMF, which can create an invisible platform effect much better than self referencing sectors. An invisible 3D floor in UDMF is also a good option if you want to be able to travel under it.

Edited September 27, 2020 by Aurelius

[Ashurion Neonix]

1 hour ago, Aurelius said:

I'm making it for vanilla. Sourceport in lower image is crispy room. As for the wad link, I don't have access to a computer at the moment (I'm typing this on a tablet) but I should be able to post a link later on in the day. (I have a shared computer and someone else is using it at the moment.)

 

[Aurelius]

Crispy is good for testing functionalities etc. for vanilla, but also remember to regularly take it for a spin in Chocolate Doom to make sure you're not hitting any static limits. Here's a list of those limits (scroll down for a more in-depth explanation on the more important ones.)

 

What you're experiencing is probably not a difficult issue to fix, but with self refs it's hard to pinpoint the exact problem without seeing the actual wad. Here's a quick example I whipped up which you can check out and see if there's anything you're doing differently. One of the lesser known tricks is to use a line action on the self referencing lines to force them on the blockmap, which reduces collision issues quite significantly. I usually use an unknown line action, but I suppose some existing one referring to a non-existing tag works just as fine.

Edited September 27, 2020 by Aurelius

[Ashurion Neonix]

7 hours ago, Aurelius said:

Crispy is good for testing functionalities etc. for vanilla, but also remember to regularly take it for a spin in Chocolate Doom to make sure you're not hitting any static limits. Here's a list of those limits (scroll down for a more in-depth explanation on the more important ones.)

 

What you're experiencing is probably not a difficult issue to fix, but with self refs it's hard to pinpoint the exact problem without seeing the actual wad. Here's a quick example I whipped up which you can check out and see if there's anything you're doing differently. One of the lesser known tricks is to use a line action on the self referencing lines to force them on the blockmap, which reduces collision issues quite significantly. I usually use an unknown line action, but I suppose some existing one referring to a non-existing tag works just as fine.

I'm not really worried about static limits as it's designed to run in limit removing ports. (At least ones that remove the visplane and sectors limit.) As for the wad I should be able to upload it tomorrow. It's kinda late and I should probably sleep.

[Ashurion Neonix]

On 9/27/2020 at 1:34 PM, Aurelius said:

What you're experiencing is probably not a difficult issue to fix, but with self refs it's hard to pinpoint the exact problem without seeing the actual wad.

Sorry for the wait. (I really didn't have access to a pc)

Here art thy holy wad link.

https://drive.google.com/file/d/1WuZlbPE5xGWcsTopeXUZo-CqKpUIbIvG/view?usp=sharing

Map is map 02. bridge is located slighty south east of player starts.

[Aurelius]

After doing a quick test, it appears that your issue is not necessarily implementation, but rather the nodebuilder you use. Rebuilding the nodes (so practically just opening it an editor and moving a vertex back and forth to force node rebuilding) made it work for me.

 

If you're using UDB, GZDB or DBX, the nodebuilder can be changed from Tools -> Game Configuration -> Nodebuilder (I suspect it's not hard to find in other editors either). For vanilla, you can choose ZDBSP (zero reject) and it should work fine. I've also had good results with DeepBSP, but the real best thing for vanilla would be to use ZokumBSP. It doesn't necessarily come bundled with the editor, so you'd have to download and set it up yourself. But for starters I believe that ZDBSP should work for you and get rid of the bleeding effect.

[Ashurion Neonix]

I had this problem in the first bridge and deleting it and replacing it fixed the bleeding.