Certain walls have become non-solid. DB2 bug?

Hello guys!

I've been building a large map for some time in Doom Builder 2. Been a while (15 years) since I last made a map, so there's been quite few advances since I see lol.
Anyway, I was using Doom in Hexen format and working away quite happily, I go to test out a new section and I find the outer walls aren't solid - I can walk and shoot through them. So I think I made a mistake in DB2 and abandon it. I go back a few versions and build it out again - being careful not to delete anything or merge things together that shouldn't be, and the same thing happens, only to different walls. The map is located at the center of the DB2 grid (if that makes a difference)

Does DB2 have this known issue? Is it a nodebuilder problem? (I tried using different nodebuilders to compile) DB2 doesn't report any map problems in the anaylsis beyond a missing texture here and there.
Sometimes the walls are nonsolid and can be passed across like you have noclip on, other times they block you, and bullets (with bullet hits), but then the wall lets bullets through again at certain angles.

I tried looking online for this issue, but couldn't find anything. I'm tearing my hair out because it's happening near the end of this map.

I appreciate any help or suggestions you have to offer on this.

Cheers.

If your map is really large, it could be breaking the blockmap and causing issues like what you're describing.

esselfortium said:

If your map is really large, it could be breaking the blockmap and causing issues like what you're describing.

It takes up about a quarter of the grey grid in the editor. It's less than about 500 sectors. Does that sound right?
Are the solutions around this limitation?

500 sectors is nothing, unless they're unusually large sectors (area-wise) which could possibly overflow the blockmap. If you're rusty or inexperienced, it could just be a mapping error/oversight. It's possible your map spans too great a distance from one side to another as well.

Can you give us some hard map stats and maybe list what sort of special map features you've used? Alternatively you can just upload the map and let us take a look. The problem will probably reveal itself if someone examines the wad.

EarthQuake said:

500 sectors is nothing, unless they're unusually large sectors (area-wise) which could possibly overflow the blockmap. If you're rusty or inexperienced, it could just be a mapping error/oversight. It's possible your map spans too great a distance from one side to another as well.

Thank you for the suggestion, and after a few tests I think I've narrowed the issue down to the dimensions of the map. It was quite long in one direction, I think this must be over loading the blockmap. I took the newer sections and bunched them up and the issue disappeared (as far as I could tell)

It shoots down my idea of having one very large map. I'll have to make each main section it's own level I suppose.

Are there any good tools that you can use to make sure you keep under these limits, blockmap size being my area of concern?

Or even the names of some large maps that push the limits so I can get a feel for the boundaries?

Cheers

scottymate said:

Are there any good tools that you can use to make sure you keep under these limits, blockmap size being my area of concern?

I think you should ensure that no two points in your map are more than 32k units apart.

For normal maps, a vertex must lie within -32768 and 32767 for each axis, but the width and height of the map shouldn't exceed 32767 units. This means the "normal map space" is 32767 x 32767, despite being in a 65535 x 65535 zone of "possible map space". A Doom- or Hexen-format map cannot be larger than the "possible map space", but anything larger than the "normal map space" is subject to strange bugs that affect collision detection among other things. Some source ports increase the "normal map space" up to the "possible map space", allowing you to effectively quadruple the available space for placing stuff though. I think Essel referred to these as "strong limit-removing ports".

From the DOOM specs:

  There is an upper limit to how big a BLOCKMAP can be. Even empty
blocklists require at least 3 shorts - the 0, the -1, and the offset to
the blocklist. The offsets are unsigned shorts, which would imply a
maximum value of short #65535 ( = byte 131070) for the start of the last
blocklist. At a little over 6 bytes per blocklist, that would be a maximum
of around 21000 blocks (145 by 145 blocks, 18560 in coordinates). But the
actual limit is less. Experiments suggest that the maximum total size of
all the blocklists, not counting the offsets, is 65535 bytes. This limits
a minimalist level to around 120 blocks square (15360 in coordinates),
or a realistically complex level to around 100 blocks square (12800 in
coordinates).

Note that blockmap compression, supported in numerous node builders now, can help increase the quoted sizes. Exactly how much depends on the map.

Is this wad for ZDoom? If so then I'm surprised it doesn't build it's own blockmap and not suffer the blockmap limitations.

EarthQuake said:

For normal maps, a vertex must lie within -32768 and 32767 for each axis, but the width and height of the map shouldn't exceed 32767 units. This means the "normal map space" is 32767 x 32767, despite being in a 65535 x 65535 zone of "possible map space". A Doom- or Hexen-format map cannot be larger than the "possible map space", but anything larger than the "normal map space" is subject to strange bugs that affect collision detection among other things. Some source ports increase the "normal map space" up to the "possible map space", allowing you to effectively quadruple the available space for placing stuff though. I think Essel referred to these as "strong limit-removing ports".

I don't think there are ports that extend that limit, actually. And with blockmap limitations you'll run into issues long before coming even close to the actual maximum boundaries.

I believe strong limit-removing ports are ones that double the segs limit from 32767 to 65535, allowing for a lot more sidedefs. (And I didn't coin that term, heh)

scottymate said:

It shoots down my idea of having one very large map. I'll have to make each main section it's own level I suppose.

A hub-based map is something you could consider, since you're already using "Doom in Hexen" format.

esselfortium said:

I don't think there are ports that extend that limit, actually. And with blockmap limitations you'll run into issues long before coming even close to the actual maximum boundaries.

I believe strong limit-removing ports are ones that double the segs limit from 32767 to 65535, allowing for a lot more sidedefs. (And I didn't coin that term, heh)

You'll only hit the maximum blocksize if the level covers enough area. Scottymate probably hasn't actually done that yet. From what I understand, he just extended his map past the "normal map space".

Interestingly enough, you can do this and at the same time make use of that space. The extended area should only be for eye-candy purposes though and shouldn't be accessible to the player. The drawback to this, is that the playable area is anchored to one corner of the map, which one it is I don't remember, but it looks something like this:



In each case, I start off with a 32767x32767 map (green square; ignore any blockmap limits), and start adding onto the map (dashed green areas). The red outline defines the "possible map space", and solid red areas are part of the map that are no longer within the "normal map space". The anchoring effect is what shifts around the "normal map space" and can cause parts of the map you've already built to start exhibiting collision problems. So if you prevent players from entering the red areas, there should be no problems with an map that is wider and longer than 32767 units. In the above example, I've assumed the "anchor" is in the top left corner. It might actually differ, but the concept is the same. I noticed this anchor effect when working on rjspace, and found that I could actually make the map bigger. Unfortunately, there seems to be a maximum viewing distance of about 32768, so parts of the extended area would become HOM at the other end of the map.