ZenNode - Fast (No Reject) Builder Breaking Rocket Splash and Making Geometry Disappear (Tested in PrBoom+)

[Fonze]

Hey all, recently after picking back up a map after getting a new laptop, I've encountered a strange bug that is probably best shown than described:

 

General node builder problems:

https://i.imgur.com/7ldvjcT.mp4

 

Rocket splash not working:

https://i.imgur.com/JelP2eS.mp4

 

Wad File:

https://www.dropbox.com/s/b2caej2wbpdjzoj/E1M9bugged.wad?dl=1

Apologies that I haven't curated the map down; don't do something dumb and try to play this.

 

Format: Limit Removing Doom: (Dume in Domb)

 

This is mostly a curiosity thing; I have a working version of the map and will experiment with node builders for the working version, but I have never seen or heard of anything like this before. It should be replicable by others with just the wad file above, though the wad file above also already shows the bug on startup in prboom+ and doom retro so one would have to rebuild the nodes using their own version of ZenNode - Fast (No Reject). To be sure, simply adding a small sector anywhere will force a fresh node building. Can anyone replicate this, what is going on, and why? (beyond the general answer that it's the node builder)

 

So for some background info, as that's always good when troubleshooting:

This map, while not being particularly large, does have a lot of lines tightly packed together and at arbitrary angles, so it seems to make node builders sweat in general; BSP-W32 crashes the editor when trying to build nodes and idk if the node builder plugin goes off the "testing" builder, but with zennode-fast(no reject) selected as the "testing" node builder, the node builder plugin crashes the editor too. So this likely isn't something that would be common for most maps; prolly just one's built as inanely as this one. It takes about a minute for zennode-normal to build nodes and maybe 10-15 seconds for the fast version to work.

I have been using a very specific version of gzdb-bf and had problems transferring stuff, so I redownloaded it off my dropbox for a clean start and it behaves the same. I also started it up in DBX to try another editor, but DBX wasn't having it and it gave me these error messages, which may help to shed some light on what's going on:

 

 

 

Note that these screenies were made by adding a new sector to an actually working version of the map (forcing a fresh node building) then hitting the test button.

 

On to questions and comments:

My main question is what exactly is the cause of this? I mean clearly it's the node builder, but why is this the result?

I don't see this as being anything a mapper could exploit or design around. (like as a map's gimmick, for lack of a better word) For one, the conditions are likely strange enough to be not worth trying to replicate, though I suppose one could boil the map down to it's most basic form of still showing the bug, but the biggest issue with it is that it doesn't fully negate splash damage; it seems to just forget about it most of the time. Maybe it has to do with a blockmap thing? Idk sometimes it works, but most of the time it seems to not work, even against monsters. (you can see they take more rockets to kill than they should) Barrel splash still works. I would posit that distance could be a factor, however that also has been proven false by testing as rocket splash just sometimes seems to work and other times not from all distances. Perhaps it's related to positioning on the map; if in a "corrupted" sector? Additionally, I notice that monsters don't seem to attack as much, which is odd and also probably important.

If anybody can shed some light on this, the nerd in me would be very interested to hear what's going on. Cheers y'all happy dooming :D

Edited January 26, 2020 by Fonze

[Urthar]

I don't know what format this map is, but I loaded it up in vanilla format

and attempted to rebuild the nodes using ZDBSP Normal (no reject).

[Fonze]

Ah my apologies; I forgot to mention the format in the op. The map is limit removing format, so for loading it in an editor your choice would be correct. Interesting that there are too many segs for it; I hadn't realized that was the case. I wonder if that's related to the issue.

[Ribbiks]

yeah zennode can be wonky and temperamental for big complicated things. I rebuilt the nodes in zdbsp extended and it loads without error in prb+. as a side note nodebuilders aren't associated with editors themselves, doombuilder runs a command line to call external nodebuilder exes when saving the map.

[Kappes Buur]

ZokumBSP is an improvement of ZennodeBSP

ZDBSP is essentially geared for G/ZDOOM features, but is also good for DOOM format maps.

[Fonze]

Ah my apologies y'all that I may not have been clear in the op; this is not (necessarily) a problem holding the map back from development. (other than from a time-efficiency standpoint) I'm more-so looking for more info on what's going on as a curiosity thing, as I've never even heard of rocket splash damage doing this, ever.

 

Wrt node builders, ZenNode - normal works well, and iirc may have been the builder that seemed to handle this map best in terms of limiting general slime trails when I was getting it to its rc forms, though I'll absolutely cross the bridge of choosing and researching a node builder to use for the final version before I retackle all the slime trails appearing since reopening this map, so thanks for the info to get that part of the puzzle started as well :D I like to aim for the lowest compat possible so if nothing else is holding this map back from running in say, doom+, then I'd fight a few more slime trails from a 'lesser' builder to make it happen.

 

3 hours ago, Ribbiks said:

yeah zennode can be wonky and temperamental for big complicated things. I rebuilt the nodes in zdbsp extended and it loads without error in prb+. as a side note nodebuilders aren't associated with editors themselves, doombuilder runs a command line to call external nodebuilder exes when saving the map.

 

I get that node builders are their own thing, but if they ship with doombuilder then I think testing different editors (gzdb/dbx) should result in at least different node builder files (of the same thing) being used: (?) in the case of wondering if maybe the node builder file my editor was using got corrupt in a file transfer to the new comp or something. I just wanted to be able to cross out that it isnt a bad copy of an editor or node builder by testing multiples. So in theory it should be replicable by others with nothing but the map.

 

On that note, I'd be more interested to hear if somebody else can make this happen on their comp, rather than building them in a way to work, since I at least know ZenNode - regular works, if rather slowly. (of course I will still have to look into other node builders moving forward and thanks for the advice to do so y'all)

 

And thanks for the info on those two node builders Kappes, I havent actually tried zokum on this, it'd be interesting to see if it handles the map better, though that's a bit tangential to what I'd like to know here.

[Kappes Buur]

Finding out why the nodebuilder quit may take some doing.

I ran your map through the error checker of Deepsea and after that UDB

with these results.

 

Maybe that wil help.

 

Error_Checker_DS.7z

Error_Checker_UDB.7z

Edited January 27, 2020 by Kappes Buur

[Fonze]

Thanks for that Kappes! I had a good laugh that there were like 6 or so pages in each that were nothing but missing textures. In a way that's a reflection of all the hard work I put into making the map, as probably every one of those are a floor or ceiling recessed in and left untextured to make the flat bleed over the gap, like with lighting stuff. As I have no life, I thoroughly looked through both of the error lists. On one note it's cool that deepsea's error checker checks for more things, that's super interesting and potentially useful to know for general knowledge. I have checked this map in the error checker but I turn stuff off if it flags something I do carefully and consciously, like missing/unused textures and overlapping lines. For the lists: UDB is 8 1/2 pages of missing or unused textures then a half a page of vertex overlapping lines, which are all related to faux-3d floors. Deepsea's list is all the same, plus a bunch of unclosed sector errors on the single self-referencing sector, errors on ceilings lower than floors, teleport tags across multiple sectors, no dm starts, and a stuck demon (282) in sector (1898) except that he's not actually stuck nor is he in that sector so I'm not sure about that last one. 

 

There's definitely some good information in there, but nothing that should make a node builder fail or otherwise do weird things. I would suspect the seg number as urthar pointed out to possibly be closer to what's making stuff go wrong, though even then it would have to be perhaps some difference in the limits of segs/etc that zennode - fast (no reject) has to even zennode - normal, but I have no idea what the difference is between the two other than building a reject table, which is more for monsters than anything, though on that thought that could have something to do with the mobs being far less aggressive than normal.

Edited January 27, 2020 by Fonze