yeah, q3map2 vises and lights map fine.
i think it's some q3map b0rkage or something indeed. good thing that q1 compilers eat this .map fine, this is what important :)
i just worry a bit about that phantom leak, but seems like i shouldn't. 

well, i was trying to fix that cutnodeportals thingy using coords that qbsp printed. well, it pointed to some spot in the void. no misaligned brushes nearby... there are some edge manipulated brushes tho, but they're all aligned to the grid properly... when i edited some nearby brushes, reported spot coordinates moved slightly, but still coords are in the void... 

CutNodePortals warnings can be pretty tricky to fix, especially if they're in hulls 1/2. I assume that this is your case and that's why you get coordinates that are not near any edges/vertices.

If you remember my ramblings about the expanded brushes, you'll have to visualize this expansion and try to imagine where the brush junctions might be then and then track back to which real brush it might be.

I've done this extensivley for a couple of days and it can be rather time-consuming to track down the CutNodePortals warnings for hulls 1/2, but so far I've managed to fix them.

It should be noted that AFAIK, they're still non-critical warnings; you probably don't have to fix them. They might be regarded as potential problem spots.

If you need more help, send me the zipped map+wad and I'll see what I can do. 

I've thought about this myself, I have the source for DuBSP so it's more of a decision whether I want to add and maintain this functionality in my versions.

IIRC there were a number of issues to consider regarding map file format, wads and even an extra crouching hull(?). There is also the problem with testing; I don't have or use Hammer myself.

I dismissed the idea then, I might take a look into it again as I see there are a number of Hammer mappers. No promises though ...

Then there's the question if Riot's going to maintain DuBSP or he's through with it. Maybe he could answer that. 

wouldn't it be easier to make a seperate program to simply convert hl maps to q1 map format like sleepwalkR's mapconv.exe does for q3/q2 to q1? that way you don't have to worry about any of the ducking hulls and such, it seems more straight forward that way...
mind you, i really don't know anything about that... :P 

yeah, i generally ignore this warning. i just thought that maybe for some reason these tiny brush misalignments can cause q3map2 generate phantom leak. so i hoped that by fixing this warning q3map2 will start compiling my map w/o errors. but as glassman said, i can ignore and that q3map's phantom leaks too. well, for me qbsp output is much more important of course, so while everything is ok there, there's no need to worry much ;) 

That's a good idea. I've already in my ConvMap utility the ability to convert Q2 map format into Q1 (similar to mapconv).

There's an additional problem here though. Hammer (like QuArK) can probably generate more variants of texture positioning than the standard Q1 map format can handle.

This means that either there still needs to be changes in the compilers to accommodate a new format or the conversion must go via the QuArK ETP format.

Any suggestions are welcome. 

Can you please confirm which hull the warning appeared in? 

and corresponding wads (zipped, please) to test a quick fix I've just made for my compilers. It looks promising on the few Hammer maps I have.

At this time, it only enables my compilers to interpret the Hammer map files (with its native texture definitions), wads must manually be converted into WAD2s using e.g. TexMex and there's no support for extra hulls or other frills. I hope this is not a big problem.

Since [Jimbo] and MisYu have showed interest in this issue, maybe you could send me some test material? 

here goes the paste from qbsp output:

---- MakeFaceEdges ----
----+----+
---- GrowRegions ----
Processing hull 1...
----+----+
----+----+
Processing hull 2...
----+----+
----+----+
*** WARNING 12: New portal was clipped away in CutNodePortals_r near (428 2400 -800)
---- WriteBSPFile ---- 

as I hoped, that's why it's more difficult to fix. My usual method is to look in the nearby area for brushes with non-axial planes and delete them and rebuild to see when the warning disappears (or changes). As I said, it can be quite time-consuming ...

Thanks for the info. 

the prob is, the whole map is built mostly with brushes with non-axial planes ;)
anyway, i'll ignore this warning 

I emailed you a link to a zipped rmf map and
wad.
Let me know if the link works. 

Please don't include the rmf files as I can't open them anyway (I don't have Hammer). 

vondur, you don't need to worry at all about that. call me sloppy, but on average per map, i get about 2 dozen of those warnings... :P 

RPG100B1 had at least one, and maybe two cutnodeportals warnings. 

I found a strange effect/bug.
I launched quake, then started e2m5 map, after that I started my sm57_pulsar_se map, and I saw that one texture was replaced by another one through all the map. I restarted quake and this effect dissapeared.
But now I know, every time I start e1m5 before sm57_pulsar_se one texture changes.

Anyone knows why? 

..it's because one of the textures in your map shares the same name with one in e2m5. It's a bug in standard GLQuake, is that what you're using?

The one in e2m5 has the same name so GLQ thinks it's the same one and doesn't reload it; just loads the old one from its cache. 

its a "feature" 

it gives replay value! never play the same level twice! 

the only reason i started worrying was inability of q3map2 to compile the map properly. but ppl explained me that i shouldn't worry about that :) 

yeah, what xen said.
use fitzquake, it has this bug removed.
http://celephais.net/fitzquake/files/fitzquake075.zip 

I used glquake, simply it's the first time I saw this bug. Thanx for info.
vondur: I already have fitzquake, but it doesn't work with my videocard (voodoo2 12 mb) 

I just downloaded FizQuake, and it works great!
Then I tried it on my own convertion, in which I have changed the Enforcer for a selfmade Orb.
And although it works good in normal Quake, I found my Orb back as a shapeless jellyfish in FizQuake.
I have seen this before with MercBabe, which I had converted from Malice.

Whatever happened to the texture shape? 

i found that most every engine except standard glQuake displayed the malice models incorrectly, when running the TC itself.