SLADE issue: Won't build nodes on one level

[Stormwalker]

Hello there, apologies if this is posted in the wrong subforum.

I am currently working on a levelset using SLADE as my primary map editor. SLADE version is 3.2.0 beta 1. While there are a few small new bugs that have been introduced in recent updates, the editor more or less works well. However, out of my seven maps, it will build nodes correctly for all but one. SLADE knows where BSP is on my system and uses it to build nodes on the other six levels flawlessly, but never does it on the one map in question. It's the weirdest thing. I have no idea why. I'm wondering if there is a debug text document somewhere that would give a clue why it's doing this. Any help would be appreciated!

[Gez]

No error message in the console?

If the other levels get their nodes built correctly, it's not a configuration issue. So I figure the one level that fails to get built is too much for the node builder. Is it a very big level? Maybe you should switch to ZDBSP for it.

[Stormwalker]

No error message in the console?

If the other levels get their nodes built correctly, it's not a configuration issue. So I figure the one level that fails to get built is too much for the node builder. Is it a very big level? Maybe you should switch to ZDBSP for it.

That's interesting. I wasn't aware that BSP might have trouble with larger levels. It makes more sense now because the level's nodes were building fine for a while and then suddenly stopped.

When I highlight everything, it says the level has 19,939 linedefs. Perhaps that crosses an upper threshold. Lately what I've been doing to get the nodes to build is opening the level in Doom Builder and moving something small a few pixels and then moving it back and saving the level. Doom Builder builds the nodes just fine. I just checked and Doom Builder is configured to use glBSP to build nodes, maybe that expands the upper limits?

[Gez]

Lines are not, in themselves, the limit; however segments are -- and nodes will split lines in segments, so the more linedefs you have, the more segs you get. There's also a limit on vertices, because the nodebuilder will add more vertices so as to split lines in segments. For all of them, the wonders of signed arithmetics means there's a maximum set at 32767 for vanilla-compatibility nodes. Limit-removing ports switched to unsigned, doubling the limit to 65534. (The value 65535, or -1 in signed, is reserved.)

There's also several flavors of extended node formats, including GL nodes v5 which may be what glBSP is building.

Note that while not nodes strictly speaking, nodebuilders also have to handle generating the blockmap, and there too there can be limits if your level is very large (in total surface area).

[Graf Zahl]

doubling the limit to 65534. (The value 65535, or -1 in signed, is reserved.)

0 is also a valid index, so you still get 65535 valid ones.

[Stormwalker]

Thanks for the info! I wasn't really aware of how lines and segs factored into the nodebuilding process.

I installed glBSP and set it up in SLADE. I tried saving the map in question, and now it seems to be building nodes, so that's good. But now when I look at the wad contents in SLADE, I see listed after BLOCKMAP a series of six entries which weren't there before and were obviously created by glBSP, which are GL_MAP01, GL_VERT, GL_SEGS, GL_SSECT, GL_NODES, and GL_PVS. I don't mind them being there, but I'm trying to ensure that this wad will be playable in Boom -complevel 9. Those new files won't cause problems, will they?

[Gez]

No, Boom will just ignore them. As long as the map lumps it expects to find are there in the proper sequence, it doesn't matter if there are more lumps afterwards.

[Stormwalker]

No, Boom will just ignore them. As long as the map lumps it expects to find are there in the proper sequence, it doesn't matter if there are more lumps afterwards.

Interestingly, I tried running the wad in PrBoom-Plus and it actually does crash if those entries are present! The error reads:

P_GetNodesVersion: found version 2 nodes
I_SignalHandler: Exiting on signal: signal 11

When I remove those entries created by glBSP from the wad file and retry it, it works fine.

[Gez]

PrBoom+ has code to load them. Dunno why it crashes, though, it shouldn't.

Version 2, though: that means the map wasn't so big it needed version 5.