Impassable linedef issue in WA

There's really nothing wrong with the WA nodebuilder... more likely something else is causing it. Onet thing Deepsea DOES do better than WadAuthor (one of the few things IMO) is error checking; WA doesn't always pick up on unclosed sectors in certain cases (such as the lines used for 3D bridges or transparent doors, etc.). I dunno what you're doing to cause an impassable area. Are you sure it's not just something lik what I described above for 999cop's problem? Try using idclip and walking through the line, see if you seem to walk on air or something. That could be a linedef facing the wrong way as described above by Ultimate DooMer.

netnomad312 said:

There's really nothing wrong with the WA nodebuilder... more likely something else is causing it. Onet thing Deepsea DOES do better than WadAuthor (one of the few things IMO) is error checking; WA doesn't always pick up on unclosed sectors in certain cases (such as the lines used for 3D bridges or transparent doors, etc.). I dunno what you're doing to cause an impassable area. Are you sure it's not just something lik what I described above for 999cop's problem? Try using idclip and walking through the line, see if you seem to walk on air or something. That could be a linedef facing the wrong way as described above by Ultimate DooMer.

Not an argument, just the facts. There is something wrong with the WA nodebuilder. Just read the docs. It's a port of an old old version of BSP that had the "wrong" side error (and is pretty slow). This causes "blocking" lines. There's a web page about this by Killough somewhere (maybe somebody can find it for me).

Adding an external nodebuilder to WA is pretty simple. I think the only thing you have to worry about is not having long file names in the path, especially NO BLANKS in the path.

If one wants the greatest compatibity with ALL ports including stock DOOM, then the suggested directory names for ALL Doom projects should limit themselves to 8 character per directory with no blanks. The reason you get in trouble with blanks is that if a utility does not put quotes around the file names, the utitily being launched sees the blanks as separators for different parameters and nothing then works (that includes DOOM and ports).

netnomad312 said:

There's really nothing wrong with the WA nodebuilder...

AHAHAHAHAHAHAHAHAHAHAHAH

hah

edit: oh yeah, so set wauth to have an external builder (or none like I have it), click Tools->Options and then the Files tab. Set node building to 'None' or 'External'. If you use an external builder then put the path of the builder (or just the exe name if it resides in the same dir as wauth) followed by $_Wadfile which is a variable that represents the currently open file. So if you use Zennode you'd do: c:/games/doom/utils/zennode.exe $_Wadfile or just zennode.exe $_Wadfile.

There are also a couple other vars but the only one of any use really is $_Mapname which specifies the mapname (MAP01, E1M1 etc) so you can build nodes for only one map in a multi-level wad.

netnomad312 said:

There's really nothing wrong with the WA nodebuilder...

...until you start building big maps with a lot of sectors/linedefs, then it becomes too slow...

(ZDBSP is the quickest I know of)

I have been building big maps, but WadAuthor doesn't seem to have much problem with size. I don't know really what it's doing, just takes more time to save - building nodes.

I'll just set to "none" for building nodes, then run through ZenNode.

Well there has to be something causing the errors besides the nodebuilder. I'm building the 28th map of my megawad right now (more "off" than "on" though), and through all the levels I've not once encountered a problem like that. Either he has some kind of unclosed sector (and there are people who NEVER use the error checkers), or it's just a line facing the wrong way. Call it a node error, maybe, but making the offending line face outward usually fixes it.

netnomad312 said:

Well there has to be something causing the errors besides the nodebuilder. I'm building the 28th map of my megawad right now (more "off" than "on" though), and through all the levels I've not once encountered a problem like that. Either he has some kind of unclosed sector (and there are people who NEVER use the error checkers), or it's just a line facing the wrong way. Call it a node error, maybe, but making the offending line face outward usually fixes it.

This is not a debate - just the facts. Find Lee Killoug's page since he gives a very good description. He's the one that discovered this around 1997? I ran into this on occasion myself, since I copied the orginal mistake. Do NOT use the internal node builder .. period. It's duck simple to use an external one, so why invite a problem. Besides that for large levels you'll be glad you did.

Btw, flipping a line should make absolutely NO diffence in a level (assuming everything else is ok). If it did make a difference then what you encountered was the bug I just described.

You'd have to see many many levels to realize this occurs. It does not happen very often in an area where it matters. IOW, I believe you when you say that in 28 levels you got around it. Although if you had to flip the lines you actually ran into the bug :) The only way you'd realize this is to leave the line unflipped and use zennode, etc. ZDBSP does not support "fake" bridges, but does work better for ZDOOM, but not all ports (GL stuff is not good).

Depending on the level DeePBSP and ZDBSP are about the same. Sometimes 1 is 2x faster than the other and sometimes not. Uusually not enough difference to matter. For smaller levels ZENNODE is fine and actually preferred for LEGACY.

That's not saying the original problem is caused by this. I don't even know where the problem is. I'll look if somebody gives me a linedef number so I don't have to run'round the level trying to find it.

Facts, yes... but then there are opinions we make from them. I, for instance, do not see an extra line-flip as a cause for a change in nodebuilders.

"Fake" bridges are among the tricks I'm using for this wad (in fact the level 28 I'm working on has quite a lot of them). I've long since given up on making it compatible with GL ports. GL will screw with the bridges sometimes as well as my other tricks (laser bars for instance).

netnomad312 said:

Facts, yes... but then there are opinions we make from them. I, for instance, do not see an extra line-flip as a cause for a change in nodebuilders.

"Fake" bridges are among the tricks I'm using for this wad (in fact the level 28 I'm working on has quite a lot of them). I've long since given up on making it compatible with GL ports. GL will screw with the bridges sometimes as well as my other tricks (laser bars for instance).

WA's nodebuilder should not be used for exactly the same reason you should not use the obsolete bsp2.1 (or something like that - just read the WA docs since he gives credit somewhere in there). It's exactly the SAME old code for god's sake. You can run into situations where you nothing will fix it. But go ahead and make life harder for yourself with the facts I've given you:)

As far as GL ports go, try RISEN3D. That works for fake bridges and scads of levels that no other GL port will display properly. And that's why I know ZDBSP screws up on GL levels too :)

http://risen3d.newdoom.com/

deep said:

WA's nodebuilder should not be used for exactly the same reason you should not use the obsolete bsp2.1 (or something like that - just read the WA docs since he gives credit somewhere in there). It's exactly the SAME old code for god's sake. You can run into situations where you nothing will fix it. But go ahead and make life harder for yourself with the facts I've given you:)

Yes, I'm sure it will be hard living with the fact that I'm using a slightly obsolete nodebuilder. But who knows, maybe I'll live. ¬_¬

deep said:

As far as GL ports go, try RISEN3D. That works for fake bridges and scads of levels that no other GL port will display properly. And that's why I know ZDBSP screws up on GL levels too :)

http://risen3d.newdoom.com/

Thanks... but I'm a bit more concerned with the GL ports more people know/play (such as Legacy). I plan to have in the text file a note not to use it or similar ports, at least in GL.

netnomad312 said:

Yes, I'm sure it will be hard living with the fact that I'm using a slightly obsolete nodebuilder. But who knows, maybe I'll live. ¬_¬

Notwithstanding your sarcasm, it really makes no sense to use obsolete code with bugs. Do you realize how old that code is? Try 1995! This is like still wanting to use DOOM when all these terrific ports are available. Besides that, that old code builds the BLOCKMAP like a slug, does NOT support large BLOCKMAPS and is the slowest code by far. Last time I checked DeePBSP is something like 50 times faster than that code. Only if you have small levels/fast machine is this not noticable. By small, I mean levels under 10,000 linedefs.

What I don't understand is that changing it to a modern BSP is just a few entries in WA. Seems very odd to not want something that's a painless change and avoids all these issues.

Thanks... but I'm a bit more concerned with the GL ports more people know/play (such as Legacy). I plan to have in the text file a note not to use it or similar ports, at least in GL.

RISEN3D is extremely fast for the largest level you can throw at it. Uusally up to 2 to 3 times faster than the next fastest GL port on large levels. Plus it has full BOOM compatibility, extended ambient sounds, it's own 3D floors and in the end will have exactly the same texture and flat options as ZDOOM, plus external hires/hicolor graphics support.

Things change and as more people become aware of what it can do, you can bet it will be among the top GL ports out there.

LEGACY might become ok with the next release, but probably not. Mainly because it doesn't use GLNODES which is a requirement to avoid sky bleeding (unless the code wants to do that internally - which is possible - seems they were mentioning doing an internal builder too). I prefer externally linked builders from a port and RISEN3D will stay that way. Makes it much easier to change and test various options.

Well I am really ignorant with most things about ports and such. many old timers say OpenGL is not a concern, and that most players don't use. I personally love GL! JDoom added a whole new dimension to my old gaming experience. I am addicted and can never go back.

JDoom is fantastic! ZDoom GL comes close, but doesn't have the 3d models yet. Legacy will run almost any wad I put in, but GL mode sux.

Just my opinion.

I am not smart enough to use any map editor but WadAuthor though, so can take my opinions with a grain of salt.

deep said:

Notwithstanding your sarcasm, it really makes no sense to use obsolete code with bugs. Do you realize how old that code is? Try 1995! This is like still wanting to use DOOM when all these terrific ports are available. Besides that, that old code builds the BLOCKMAP like a slug, does NOT support large BLOCKMAPS and is the slowest code by far. Last time I checked DeePBSP is something like 50 times faster than that code. Only if you have small levels/fast machine is this not noticable. By small, I mean levels under 10,000 linedefs.

What I don't understand is that changing it to a modern BSP is just a few entries in WA. Seems very odd to not want something that's a painless change and avoids all these issues.

When I want an alternate nodebuilder, I just use my frontend. Other than that, I have zero problems with the WA nodebuilder. And to date, the largest level I've made is 4,523 linedefs.

deep said:

RISEN3D is extremely fast for the largest level you can throw at it. Uusally up to 2 to 3 times faster than the next fastest GL port on large levels. Plus it has full BOOM compatibility, extended ambient sounds, it's own 3D floors and in the end will have exactly the same texture and flat options as ZDOOM, plus external hires/hicolor graphics support.

Things change and as more people become aware of what it can do, you can bet it will be among the top GL ports out there.

Sounds nice, I wonder why more people don't use it. Does it show tricks (like fake bridges and such) correctly? Because I have yet to see a GL port that does.

deep said:

LEGACY might become ok with the next release, but probably not. Mainly because it doesn't use GLNODES which is a requirement to avoid sky bleeding (unless the code wants to do that internally - which is possible - seems they were mentioning doing an internal builder too). I prefer externally linked builders from a port and RISEN3D will stay that way. Makes it much easier to change and test various options.

It's funny... sometimes I get skybleeding in Legacy when I play my levels. But this also counts for levels that I've run through Zennode on occasion, because they were Legacy levels (I used glBSP at one point but this failed to fix some of the GL holes). In software I always see skybleeding. But the last time I played my megawad in Doom95 (what I originally started out with) I didn't see any. Hmm.

netnomad312 said:

When I want an alternate nodebuilder, I just use my frontend. Other than that, I have zero problems with the WA nodebuilder. And to date, the largest level I've made is 4,523 linedefs.

But why bother going to a frontend when you can do it all inside of WA and get both a better and faster node build for 0 extra effort? It's a nice feature to be able to do that. Historically many people have had probs with the internal code. You've just been lucky :) The problem happens most frequently if you have lots of angled lines.

Sounds nice, I wonder why more people don't use it. Does it show tricks (like fake bridges and such) correctly? Because I have yet to see a GL port that does.

Yes! Even plays BLUDWRKS. No other GL port can handle either of these. More people don't use it only because he's not fond of promotion and such. So I hope to help that along as time goes by since it really is a terrific GL port with all the BOOM features, JDOOM features and then some added 3D stuff that is a bit difficult to do, but the results are astounding. See the sample level supplied with RISEN3D to see what I mean.

Legacy does not use GL nodes, so using GLBSP won't help one bit. The problem is purely one of code here. ZENNODE is the preferred node builder for Legacy levels since Mark worked to make it specifically work for that port. True, it won't fix all sky issues and won't fix any of the various "tricks" in levels. As I mentioned, only RISEN3D successfully plays these PWADs in GL mode.

Making all DOOM and BOOM levels work is Graham Jackson's number 1 priority and goal. Sometimes I disagree<g> since some levels have serious mistakes and happen to work in software mode totally by accident. I wouldn't bother attempting to write code to work with levels that are plain wrong. But that's why we are all different.

I get confused with quotes and who wrote what where.

Who said what port plays BLDWRKS? and What port!

deep said:
There's a web page about this by Killough somewhere (maybe somebody can find it for me).

Here you go.

Making all DOOM and BOOM levels work is Graham Jackson's number 1 priority and goal.

That's excellent.

um, well, yes thanks to netnomad312, I have figured out where the problem was, which is lack of the height between the ceiling and floor...wow I really did bring up a lot of discussions with one tiny problem on my part

netnomad312 said:

Sounds nice, I wonder why more people don't use it. Does it show tricks (like fake bridges and such) correctly? Because I have yet to see a GL port that does.

Most of the time yes. It does screw up though, like making fake ceilings transparent.

Szymanski said:

Most of the time yes. It does screw up though, like making fake ceilings transparent.

Please send me the level. Only with examples can he see what else needs to be checked. All BOOM stuff should work. If it's not a BOOM or DOOM feature, then it doesn't count:) If Graham doesn't know about it then he can't possibly fix it.

And sometimes (since it's a WIP), a release will not work and then work again as the code progresses. This has just happened and will probably happen again just as for any other developing project. Current release is something...46.