randy wrote:...a critical bug introduced in 1.16 that caused it to write garbage for normal nodes.
Did ZDooM v2.5.0 use zdbsp v1.16 as its internal node builder? If so, that would explain why th polyobjects in one of my maps kept messing up upon start-up. [But then, it would not explain why an external node build using the same zdbsp version straighened things out.]
Gez wrote:I don't think the internal nodebuilder ever creates normal nodes.
I'm not sure I understand you. Do you mean that the internal node builder never creates "proper" nodes, i.e., it has some type of deficiency? Or do you mean that the type of node building it does is different from the type that is done externally, but it works sufficiently well for the map to run?
ZDBSP can build a variety of node types. "Normal" nodes are just one of the types of nodes that can be built. So, it's not "normal" as opposed to "abnormal"/"improper" nodes, it's a type of node structure.
While perusing the wiki for zdbsp, I came across this:
--extended or -X This causes ZDBSP to write extended nodes instead of normal ones. Extended nodes have a greater precision and as a result create less slime trails than normal nodes, and they are also the only way to save nodes with more than 65535 segs. (New from 2.5.0)
How does this reconcile with:
--gl-only or -x This option causes ZDBSP to build only the GL nodes.
In other words, if I am building the nodes for a GZDooM map that has polyobjects, etc., can I use both those options together?
Gez wrote:It's case-sensitive. -x is not the same as -X.
Yes, I did realize that when I first read the description. It just sounded like using -x would only build GL nodes as normal nodes and not extended nodes. Therefore, using -X as well might result in a conflict. Thanks to NeuralStunner for clarifying.