Q2 and Q3 (and Q1) .map are different too! Q2 has some extra fields for surface properties per face which Q1 and Q3 don't! 

ok, it was very simple actually, compiled, used quark to convert the map to q3 format (literally just copy/pasted from the q1 map into a new q3 map)

q3map2 is actually much worse than the q1 compilers in terms of handling insane geometry. looked like maybe 5% of the faces were missing in the q3 map.

oh well, looks like it's time to call it. it was a fun experiment, but just not meant to be... maybe i'll use this mesh for a doom3 map or something. 

Please don't tell me you were using the brush version of your terrain in the q3 version. 

Going for Q3BSP and not using meshes would seem a little pointless. BSP is not the way forward for terrain. 

i never made a q3 map before so.... i wouldn't know.

ericw told me about some misc_model thing though... which is apparently some magical way of turning a model into world geometry! 

-haltOnLeak

Stop compiling immediately after writing the pointfile and exit with error code != 0

This lets people detect %errorlevel% in batch files.

Thanks! 

because it was annoying me:
https://github.com/necros0/ne_q1CompilingGui/tree/master/Compiling%20Gui/Compiling%20Gui/bin/Release

just grab the exe file. hard codes the START /B /I /WAIT /BELOWNORMAL into all the compiler commands, so everything always has below normal priority.

At some point, i should probably make some per-compiler thing to choose what priority you want, but... meh, this works. 

I was under the impression that you can't tell if there is a leak until you traverse the entire tree, thus why QBSP doesn't end early when it finds a leak. 

when qbsp writes the leak file, is that not 100% a leak? usually what I do is I watch the output until it says 'writing point file' then once it's done, i Ctrl+C and plug the leak. 

Oh, I see what you're asking for now, ignore me.

I was thinking you just wanted time savings by ending the compiler earlier, but most of the hard work has already been done. QBSP has fully processed and portalized the tree when it detects the leak... but you just want an option to return an error to the console at that point so your batch file can detect it. 

that and so i don't have to actually sit there and watch the output (which I sometimes miss) waiting for 'leaked!' :P

Disregarding the current map, I rarely seal until the end where I do a leak plugging session. But it gets tiring to have to watch console output hoping it won't leak. Dunno if others do it that way or not though... 

Yeah, I don't bother to seal until the end of making a map, but it's really rare for me to get leaks when I don't expect them. 

Yeah, I don't bother to seal until the end of making a map, but it's really rare for me to get leaks when I don't expect them. 

I never work on a map that leaks. 

Sometimes you have to, Rick. Large scale retooling of areas or you're trying something out, etc. Leaks aren't an issue until you want to release the map, really. Only thing they do is slow down your lighting builds... 

I prefer to keep a map sealed as well.

There are so many ways a map can get weird phantom leaks, I like to keep the obvious ones plugged.

For tests I do the big box method - a giant box or two to remove areas from the compile, or just plug holes while I put other areas together.

Really it just depends on which brand of OCD you subscribe to. 

I agree, when doing major structural changes it's hard to avoid creating leaks, but once things are rearranged close enough it's time to plug any leaks.

So I guess said that wrong. I just meant that I don't start with a bunch of brushes and stuff floating in the void, I build with sealed areas from the beginning. 

i do the same: keep it sealed most of the time, with a solid black brush plugging any doorways/hallways that lead to nowhere.

However, when in the middle of building a large atrium/canyon type space, i do leave it leaky while the outer walls of that space are still in flux though (i'd rather leave it empty than place a box around it, i feel the box will influence the way the space is built and create boxy rooms! :)

Anyway i'm on an old computer and it seems that qbsp and light run a lot faster on a sealed map. It seems that all the outer faces being clipped away speeds up both processes. So i do it for my own productivity. 

anyone have any idea how to make gtkradiant1.5 ok with info_notnull being a both a point entity AND a brush entity? or maybe there's another good entity that can be used as a blank hackentity?

as it is, gtkr only considers the entity to be one or the other... if it's a point in the .ent file, all brush based info_notnulls lose their brush; if it's a brush, the points can't be edited in the editor because they have no brush (thankfully, they retain their origin). it's really inconvenient when trying to use both 

The newest version of Netradiant has the same problem. I had just deleted it entirely from the .ent file and my old 2012 version was fine with that, but the newest version defaults to assuming it's a point entity and deletes the brushes.

What would be nice is if the <point name= and <group name= were not locked into also being the classname. The classname should be a separate key something like:

<group name="brush null" ...>
<classname= "info_notnull>

<point name="point_null" ...>
<classname=<"info_notnull">

Also, I started getting sv_touchlink errors using brushed info_notnull triggers in the new Netradiant when. I had to go back to the older version (and older copy of the map for some reason) to get rid of the error. 

mm, think I'm just going to map with the point entities as info_null, and then find/replacing them before compile to be info_notnull... maybe should hack qbsp to do this for me... 

I could do without the point entity version, but when I made it a group I started getting those sv_touchlink errors. Couldn't figure out how to fix them, so I just gave up and went back to the old version of Netradiant I've been using for years. 

 

i don't use teh lunix