Making slight changes to a map without rebuilding the nodes

Is this possible at all ?

(I'm assuming here rebuilding the nodes is what breaks demo compatibility, if that isn't the case please correct me.)

More details : I'm talking about either limit-removing or Boom maps, and stuff like changing, aligning, (un)pegging textures or change an action on a door. No vertex or thing changes of any kind.

Specifically, I've got a problem in this wad with Map01 ; the final door (sector 109) is set as D1 open stay on one side and DR open wait close (also monsters) on the other one, leading monsters to possibly block the door if they activate it after the player. I'd like to change the D1 side to DR.

Should be possible.

Worst case, you do the changes needed to linedefs, save as a new map, and then you simply use Slumped or equivalent to replace the old LINEDEFS lump by the new one.

If you change textures, do the same for the SIDEDEFS lump.

Keep all the other lumps the same as before.

Yeah, you can do that. Just make the change and don't apply the node builder on it when you save.

Alright. I'll make backups and give it a shot. Thanks !

Phml said:

Alright. I'll make backups and give it a shot. Thanks !

If the map is in DOOM format you could also try out the old BOOM tool called CLED - the "Command-Line Editor", provided you have a way to run DOS programs at least.

This is one of the reasons I have stuck to wadauthor for so long. It automatically recognizes when nodes need to be built and when they don't. So if you only alter some textures in a colossal size map, the nodes aren't built and you don't have to wait several minutes for the nodebuilder \o/

Good for lazy people like myself!

"Command Line"... These words are enough to scare me away unless absolutely necessary. :)

Anyway, I followed Gez's instructions and it seems to work just fine. Took a look at a bunch of demos just to make sure I didn't screw up, and didn't spot any desync. I like this method, it's simple and fast for people like me. Thanks again !

(For the record, I've tried myk's approach too but DB2 seems to overwrite/erase the old lumps when saving, even with [do not build nodes] specified ; I just ended up with new lumps lacking the nodes, at the bottom of the wad in SlumpEd.)

Phml said:
(For the record, I've tried myk's approach too but DB2 seems to overwrite/erase the old lumps when saving, even with [do not build nodes] specified ; I just ended up with new lumps lacking the nodes, at the bottom of the wad in SlumpEd.)

Hmm, yeah, I was wondering whether Doom Builder (2) would do something lame like that. One should definitely be able to align texturing or modify line types without having to mess with the base structure that has nothing to do with that. The only ways 0-size lumps should appear there is if a node builder is never run on the level, the node builder is always told to do nothing to the corresponding lumps, or it's specifically told to write 0-size lumps.

I'm fairly sure deepsea has intelligent node building...

Phml said:

"Command Line"... These words are enough to scare me away unless absolutely necessary. :)

It's actually really simple, and more or less walks you through using it. The only tricky thing is that you must know ahead of time the linedef/sector/etc. *numbers* that you wish to edit, as it asks you for the number of the item and then displays its properties that you can change.

It was a pretty well-designed piece of software, actually. I should make an updated version of it that is a Windows console app ;)

For the record, you don't need to build nodes if you just edit line/sector/thing properties, or add/move (but not delete) things.

Vorpal said:

This is one of the reasons I have stuck to wadauthor for so long. It automatically recognizes when nodes need to be built and when they don't. So if you only alter some textures in a colossal size map, the nodes aren't built and you don't have to wait several minutes for the nodebuilder \o/

Good for lazy people like myself!

Or you could tell it to use zdbsp and wait several seconds at most ;)

The Ultimate DooMer said:

For the record, you don't need to build nodes if you just edit line/sector/thing properties, or add/move (but not delete) things.

Deleting things doesn't make the nodes need to be rebuilt either. The absolute only things in a map that determine the structure of the BSP tree are the linedefs, sidedefs, sectors, and vertices. If none of those are changed, the BSP cannot possibly become invalid.

Some editors just do not wish to properly keep track of this information.

I think you only have to rebuild nodes if you move a vertex, change a linedef's vertex or sidedef (edit: not always, see below. thanks to GZ for clarification) references, or change a sidedef's sector reference. Doing anything with things is fine, as is changing linedef flags, specials or tags, sidedef textures or offsets, or any sector property you like. Try to find one of the modified IWAD maps made before there were nodebuilders, they're quite inventive :)

myk: you can get a zero-length NODES lump, but the map has to be completely convex so there is only one subsector. (but it will crash Boom because they took out the test for no nodes from R_PointInSubsector... (bug))

Quasar said:

The absolute only things in a map that determine the structure of the BSP tree are the linedefs, sidedefs, sectors, and vertices. If none of those are changed, the BSP cannot possibly become invalid.

... and even if some of these are changed it wouldn't matter.


The only things that really affect the nodes are:

- vertex positions
- linedef vertex indices
- a linedef's sector references. You can even mangle the sidedefs as much as you want as long as each linedef keeps the same sectors on the sidedefs it references.

Sectors are only relevant if some are added or removed. Their contents do not contribute anything to the nodes.

Things get a bit more messy if polyobjects in ZDoom maps come into play but that's another matter...

It should be noted, however, that adding or removing things will affect demo compatibility, because there's one more or less thing to be cycled through by the thinking code's pseudorandom number generator.