Hmm I opened the file in the Trenchroom beta now and used the debug tools to see if I had brushes that had wandered off grid. I had 18 in total... grrr hahaha. Well thankfully I was able to fix them. The compilers is no longer making unexpected portal leafs and compiled in half the time! Sleepwalker kicks butt....

I used the stable TB1 for the level so far. But it does tend to make dirty brushes with some of my more elaborate edits. oh well. This looks like a clear case of USER ERROR... derp.

On another topic if I may? Is it a plausible workflow to have a map you run BSP and vis on and then just spend time lighting it without needing to redo the other 2 passes? Of course at that point would only be placing and moving lights around. 

Sleepy is a holy man for sure.
-onlyents compileswitch for qbsp just updates the entity lump of the bsp fle, even on vised ones. Run qbsp with that switch when doing lights. Saves a lot of time.
Note that when adding triggers or doors(brush entities..), a full compile is needed again. 

Hmmm I know how to do this in Quake 2.... is it similar in Quake 1? Make a bsp set breakable and switch state to another Brush arrangement? I want to shoot and break an object in my map as an example to progress. 

Without QC, you have to fake it.

Make the part that will break a func_button with "health" "1", this means it is shootable. Give it a targetname, and also target it at a trigger_relay. Give the trigger_relay a "killtarget" "func_button's targetname".

This set up will destroy the func_button when it is shot. There are no effects. I suggest you also make an explosion happen which will cover it up. To do this, target an info_notnull with "use" "OgreGrenadeExplode". This will create the same explosion as if an Ogre's grenade exploded. 

Nice. Yea I will give this a shot thanks! Games are all fakery anyways :) as long as it looks convincing hehe. 

make sure the button has 'speed' set to something high so it disappears.

optionally, you can create a broken version of the breakable, and make that a func_door. you can then set it to 'start open' and, if you have a fast 'speed' on it as well, the button and door will appear to switch instantly (you can hide that with explosions). 

Is it possible to increase the size of the cutting that is done to the BSP by the compilers?

Right now it breaks up large simple areas into tons of smaller chunks... but I know with for example KMquake2's BSP tool he added the option to increase chunk sizes to much larger pieces so outside BSP did not turn into a crazy mess. 

is to increase the size of the texture itself. A lot of mappers increase the size of monster spawn room textures. 

There's a reason world polygons can't exceed a certain size in the quake engine - anyone remember? 

 

cuts Faces greater then 224 units. This is afaik not changeable. 

I think it's a lightmap issue isn't it? They have a max size, therefore the surfaces have a max size ... which I think is what Lunaran said. 

Lightmap size sounds likely 

not quite. It cuts faces that size when the texture is 1x1 size.
It is relative to the texture size. I forget why though.

So scaling a texture to 10x10 will give you larger cuts. In the old days, you had to do that to sky textures because the compilers would cut up the sky into tons of faces. New ones do this automatically now though. But yes, if you are looking to get some extra faces, scaling up your textures will reduce the amount of cuts qbsp does.
It's rarely an issue these days though. 

an easy free one is to make all your triggers and other invisible brushes have scaled up textures cause you never see those anyway. 

240 units is the default, this can be raised in some compilers but then you Brel comparability with most engines. Dark places will still load it though.

It's has to do with light maps but also, the way software renderer does lighting calculations.

Anyway who cares about poly count anymore? 

r_speeds be damned! 

"Anyway who cares about poly count anymore? "

Careful, I've tried that argument before and gotten brutally chewed up around here. :) 

High poly counts break vanilla Quake. If you don't care that it won't play on GLQuake (which has the same limits as software Quake but who even uses software Quake anymore) and make sure that that fact is in the release notes then I agree, who cares? Even an old (10 years or so) POS PC should be able to do GLQuake using its on board graphics chip. 

I had a POS PC in 2004 and it was very much capable of running GLQuake. ;) 

who even uses software Quake anymore

I imagine vanilla WinQuake still has a following because of that very special je ne sais quoi that the software renderer provides.

Can't imagine many people are still playing vanilla GLQuake though. Ugh. 

I endorse Fitzquake with overbrights and GL_NEAREST for all your je ne sais quoi needs 

Also, if a lightmap is 16:1 and 8x8 it doesn't quite cover a 256x256 square. You need data points at the edges to interpolate from, but 9x9 is abhorrent and nonbinary, which is where surfaces split at 240 comes from. 

Yea Fritz and Spasm for me with Nearest filtering for me. I just like to see how pretty we can make the game look with these most recent additions without getting lost in all the nextgen madness. 

I imagine vanilla WinQuake still has a following because of that very special je ne sais quoi that the software renderer provides.

Nah, that's what the qbism super 8 engine is for. ;)

Except in extreme cases, you're safe to go to the Fitzquake doubled map limits at the very least.