Yeah, the limited texture lock comes from the vanilla .MAP format; Quake itself/compiled .BSP's can handle full texture lock.

You can choose the Valve 220 map format when you start a new map in TrenchBroom 2, which has full texture lock, the only problem is I don't know an easy / reliable way to convert vanilla to 220 if you've already started the map in vanilla format. 

Yeah, not being able to convert really sucks. Someone should write a tool to do it, assuming it would be possible at all. I'm stuck on standard format because when I started the map 220 was broken-ish in tb2... 

Hm.. yeah I'm going to take a shot at adding it to qbsp. 

How would that work? QBSP outputting a new .map? 

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.