Max Clipnodes limit 32767

[ajay]

Just had this error hit me in my earthQUAKE large city map, after taking out a 'solid' building and replacing with a hollow accessible one. Is this an error I'm only going to fix by simplifying the map or are there other solutions (I'm certain there's no leak btw)?
I'm trying out filling empty space with clip brushes, but I have my suspicions that a combination of not-great-mapping and a very large, at times complicated map have finally exceeded Quake.


***EDIT***
Scratch the above (for the time being anyway) filling the space has worked for now... I've a feeling I may run into it again tho'....

[metlslime]

if there are any ares the player can't go, fill those areas with a giant clip brush. That will reduce clipnodes.

EDIT: I see you already did this. Well, it's a good idea, don't be hesitant about it

[necros]

[qbism]

[metlslime]

[necros]

[ajay]

Thanks for your replies everyone. All being considered and tried...

[ajay]

The problem keeps re-occurring and I keep fixing it by adding more clip brushes in empty spaces. I think that, with much more to add in the map, I'm going to run out of space to fill, and therefore my thoughts are:

- it's not a problem that appears to bother the engines; FQ, DP and DQ all run the map with no problems, so it's problem only during compiling (the map fails in most other engines for other reasons, so I'm just worried about keeping it running in those 3 anyway)
- it's an error flagged up in QBSP, so is there a QBSP that ignores it or has a (MUCH, hopefully) higher clipnode tolerance? (I'm using: "TreeQBSP v1.70 -- Modified by Bengt Jardrup")
- is it flagged in QBSP because of an assumed limit that engines would fail at? (Now no longer an issue for newer engines)

[mh]

Unfortunately you'll never get more than ~64k clipnodes from Q1 BSP as clipnode numbers as stored as 16-bit short integers in the BSP file itself. The format also needs negative numbers to be stored, so there is a further restriction that the highest positive clipnode number minus the lowest negative can't exceed ~64k.

This is a Q1 BSP format limitation, nothing really to do with the engine you're using. There are loads others (vertexes is particularly troublesome).

I'm actually surprised that more engines haven't gone down the high capacity route; I would have thought that it should be reasonably common by now.

FTE would probably run it too, but then again I have a feeling that FTE would probably run Pong maps if you tried.

[metlslime]

[ajay]

Thanks again. I've gone with the 2.05 version of TreeQBSP and it's compiled it with just a warning, rather than stopping with an error.

*Admission*
I hadn't realised there was a newer version until trying to run -hilimit and it not being supported, then read the readme.txt (above) and then downloaded the newer one.