Yeah, it should be a separate tool I guess, but for now I just added a "-convert valve220" flag to qbsp that makes it output a new .MAP and exit. It adds a suffix so it doesn't overwrite the input map file. Seems to be working so I'll post a beta soon! 

That's fantastic! I'm in the same boat as Pritchard, and have been hoping for a standard-->220 converter for about a year and a half now. 

See this is why people are still mapping for Quake after 20 years. Tools updated by people who give a shit! Amazing - I have had this affect me a few times as well so this would be a welcome addition. Thanks. 

I started my first map going for a claustrophibic castle look, and used Ik-White textures because I loved mapjam2's aestetic the most. Now I have noticed that my architecture isn't interesting enough to compensate for the small number of ik- blue/white textures, as architecture was strong with ikka's maps. To replace the white textures I want to go with some nice brick walls. I would consider going with default Quake, just write the texture name. 

quake.wad, try some grey city textures? Search "city". In ad_start, search "stone". knave.wad has also some really good choices. 

http://celephais.net/board/view_thread.php?id=61211&start=770

This new update fixes a bug where < 1 unit gaps could cause bugs in light generation. It looks like what's happening there.
The other option is to look at your brushes and figure out what's weird about them. It's usually not a good idea to have such tiny gaps anyway... 

I need to remember to refresh both my memory and my browser... That post was written as a reply to #18379 which is quite an old post now... 

So with the help of the compiling log and the point file I could avoid getting a pts after compiling. I need help fixing three last errors. Warning 19: No entitys in empty space no filling performed (hull 1&2).
Warning 16 Texture TB_empty not found. How do I find those damn entitys flying in outer space? How do I find the face which I didn't texture, that got the standard Trenchbroom texture? 

Warning 19: No entitys in empty space no filling performed (hull 1&2).
This can happen if you have almost no entities in the map, and all of them are near walls.
When qbsp builds hull1/2, it expands all of the burshes, and if they happen to cover up all of the entities when expanded you can get this error. 

Well that's probably the issue 19 solved because I just wanted to have a sneakpeak of the level ingame and I just started working on it. How many units should I elavate my info_player1_start? I guess 10 should do. I still have to find the untextured face(es). 

42 

 

Hi I was wondering if anyone had any information about if modern quake engines have any limitations with respect to brushes, vertices, entities etc...

I am trying to make a map but am getting a little carried away with it. I am worried that I am working on something that will never run because I've taken it too far or something. It's gonna be awhile before it's sealed up and am wondering if that time would be better spent simplifying the brushwork.

SS of map in editor:
http://i.imgur.com/riPcFnE.png

SS of map in game (from a few days ago:)
http://i.imgur.com/m128dD2.png 

https://quakewiki.org/wiki/Engine_Limits
and with BSP2 you can go with even higher limits 

Okay next question, is there a way to check if a map exceeds these limits without compiling? 

is there a way to check if a map exceeds these limits without compiling
no. pretty much all the limits are subject to qbsp's csg or bsp tree logic, which can even vary from one qbsp to the next.
While you could try guessing based upon brush count, quite often its what you did with them that counts.

For instance, if your map has no leaks then the outside part of your map can be completely cut away, the leafs are merged, the nodes are redundant, those faces can be discarded, etc - this significantly reduces the amount of data needed.
If you have a lot of surfaces all cutting through each other then you'll have noticably more nodes/clipnodes per brush. Stuff like that.

Do note that there's an unsigned variant/reinterpretation of the vanilla format which doubles the formats limits from 32k to 64k in various cases, which is incompatible with vanilla (hence how various engines claim various 64k limits where vanilla does not). Many qbsps will generate this without even realising it (although light+vis utils might then bug out if they're really old, depending on what you exceeded). 

So from what you say and what I've read, I understand that as long as I'm sensible with my brush work, seal the map, use updated tools and compile with BSP2 that I don't have much to worry about?? 

Don't use BSP2 from the start, switch to it only when you reach the first limit.
Check your bsp with bspinfo to get more precise data, but from screenshots you have posted, I think you're far from the first limit. 

 

You use tyrutils it will give an error once you exceed the limits. Then you can add "-bsp2" to the qbsp parameters. 

I'm in leak hell. Absolutely stumped :P

Using Tyrutils v15.4 & J.A.C.K editor

The map leaks through solid walls into the void. There are no entities outside the level. The map is sealed. I've meticulously checked everything. When I put giant brushes over half the map to leak hunt, the un-boxes part leaks, this repeats no matter where I put the brushes. I literally covered the entire level in giant brushes aside from the player start box and it still leaked.

Any ideas a very much appreciated :) 

Here's a brush from the map file
( 193.373 -320.665 600 ) ( 192.665 -321.373 600 ) ( 216 -343.293 600 ) COP1_2 [ 0.707093 -0.707121 0 -11.127 ] [ -0.707107 -0.707107 -0 -59.0101 ] 0 1.00098 0.999997
( 215.293 -344 632 ) ( 192.665 -321.373 632 ) ( 216 -343.293 632 ) COP1_2 [ 0.707114 -0.707099 0 -11.4788 ] [ -0.707107 -0.707107 -0 -59.01 ] 0 1 0.999997
( 216 -343.293 632 ) ( 216 -343.293 600 ) ( 215.293 -344 632 ) COP1_2 [ 0.707099 0.707114 -0 59.0142 ] [ -0 -0 -1 56 ] 0 0.999997 1
( 192.665 -321.373 632 ) ( 192.665 -321.373 600 ) ( 193.373 -320.665 632 ) COP1_2 [ 0.707099 0.707114 0 59.0139 ] [ 0 0 -1 56 ] 0 0.999997 1
( 215.293 -344 632 ) ( 215.293 -344 600 ) ( 192.665 -321.373 632 ) COP1_2 [ 0.707107 -0.707107 -0 -11.4797 ] [ -0 -0 -1 56 ] 0 1 1
( 193.373 -320.665 632 ) ( 193.373 -320.665 600 ) ( 216 -343.293 632 ) RUNE_A [ 0.707107 -0.707107 0 -11.4801 ] [ 0 -0 -1 24 ] 0 0.999999 1

Horray for guinea pigging new level editors 

In JACK you can free rotate a selection of vertices in vertex edit mode around a pivot point under your mouse cursor by right click -> dragging in the 2d view. Even if you go back and move the rotated verts back onto grid after the operation they will be off by a tiny amount, resulting in the crazy decimal points.

So : PSA - Don't use vertex free rotate mode!