CX1

I am not sure if I should post here or on Editing forum, since it is only slighty connected with DoomBuilder (but it is). Anyway: DoomBuilder allows importing external texture wads. But I also made my own texture in the wad I am editing. That caused quite a mess among patches used for building the textures - they are assigned incorrectly. I didn't use any name twice. I didn't even create new patch - just used existing ones to create new texture. So what may be a reason for that problem?

Tried the new 1.68 beta version (build 383), and it seems that DoomBuilder still have problems when drawing tiny sectors in 3D. It seems it is mixing walls, or something, creating strange artefacts. You can just ignore them, but if you want the project to be clean, it would be better if the artefacts were rare. Here is a sample problem: 3D view: http://www.ii.uj.edu.pl/~danilews/artefact-1.jpg (there should be no black stripe going accros the screen) 2D view: http://www.ii.uj.edu.pl/~danilews/artefactmap.jpg (The arrow shows from where, approximately, the previous screen was taken) Example WAD (map MAP01): http://www.ii.uj.edu.pl/~danilews/artefact.wad (to check there is no error in map construction) Not big deal, but sometimes, it may sum to something ocward (taken from the map I am currently working on): http://www.ii.uj.edu.pl/~danilews/artefact-final.jpg

My fault... guess it was written somewhere in the manual, and I missed... thanks

My videocard is not overclocked, and I have no problems whatsoever with other programs heavily using video graphics card (ie. Unreals, Q4) As I said, my DirectX and video drivers are up-to-date. Anyway, thank you CodeImp, that you looked carefully to the problem. If nothing can be done - let it be like it is. The editor is still great. btw. I observed that when you copy a Thing, it's attributes (i.e. Thing Tag) are not copied. Is it intentional?

I have DirectX 9.0c, and updated my video card driver (GeForce FX 5200, driver version 8.4.2.1, dated 2006-03-09) and it isn't any better :( Tried different nodebuilders provided with DoomBuilder (zdbsp, ZenNode, bsp-w32). Some of the cracks were corrected, but not all. I even applied slow, (and thus more accurate I think) method of building. But strange artefacts are still present... I just wonder why those problems are not present in the game itself. After all, they are processing the same data, aren't they?

Strange... the links work perfectly from my browser... I'll try different nodebuilder, but there are no cracks in the game - only in DoomBuiler's 3D preview.

I was using XWE to add MAPINFO into my wad. Because I added the new entry not as last but somewhere in the middle of file, it really cofused Doombuilder. Map, which was called MAP01 was now named MAPINFO. And after saving, XWE read some rubbish, simmilar to yours...

I found another bug in the doombuilder. In sector mode, if you have a sector 1-unit width, with all sides flipped inside, you are unable to select it. Flipping one of long walls outside, solves the problem, but I find it kinda funny. Here is an example wad with 3 sectors inside: http://www.ii.uj.edu.pl/~danilews/bug2.wad

Why 2 blocking linedefs are required?

The default nodebuilder caused the Doom Builder to crash and it wasted my wad I was working on for past few days. Fortunately, there were some backups automaticly created by Doom Builder. I was angry for those extra files showing up all the time, but now they are a miracle! Thank you for implementing those auto-backups!

I came to this problem too. When I explored the bug, I found that the error comes up when pressing TAB when "undefined texture" is selected. I guess the program is trying to put cursor on the list of the textures, and since "undefined" is not there, it gets stupified.

Thank you for the link!

Do you know where I can find tutorials on ZDoom-specific things for Doom Builder? The default manual (which is great) doesn't seem to cover that material. (or I missed something?) Thank you.

Hm.... strange indeed. Anyway, always do backup saves ;)

If your sectors aren't squarish, and you put vertices somewhere in the middle of a linedef, you may not hit the line. As a result the system might not split the linedef, but put another line next to existing one, sometimes causing a tiny overlap. If that's the case, I would suggest inserting vertices first, in Vertex Mode, to make sure, the lines are splitted correctly.

In 2D view, you can perform similar auto-aligment, but you can select linedefs where it should be executed.

I guess we don't need this separation, but adding buttons "move up/move down" might speed up things a little. As it is at the moment, if you have sectors, where ceiling of one group has similar height, as floor of another group, you have to "rotate up/down" often.