I'm about 70% done with a fairly large map, and I get "MAX_MAP_VISIBILITY exceeded" at the VIS stage. The .ase models all have their spawnflags set to 4. Anything that isn't a wall, floor, or ceiling is a detail.

Is there any way of getting around the MAX_MAP_VISIBILITY limit short of turning everything into detail brushes?

(and why is that limit there in the first place?)

Why it is there - simple. There has to be SOME limit, because it costs memory.

divVerent wrote:Why it is there - simple. There has to be SOME limit, because it costs memory.

Well, no doubt.
Is this limit hardcoded in radiant or can it be overridden in a .cfg or .def file? The limits in radiant were set back when Q3 was new, weren't they? So it should be safe to increase them at least a little.

Backup you q3map2 binary (/usr/games/q3map2) and replace it with this:
https://cat2.optus.nu/cat2/q3map2.bigvi ... oreplanes2
(make that q3map2)

(source: https://cat2.optus.nu/cat2/q3map2-bigvi ... ant.tar.gz)

Or you can use netradiant's q3map2.

Oh, Div: I hit a 32k brushlimit in netradiant q3map2. Could you apply my greater limit from the patchfile (I think it's all Fs)?


The limits in q3map2 were so the mappers of ID wouldn't generate so much data in the bsps that the maps couldn't fit on the CD I assume.

Remeber: when your map won't compile, don't fix your map (it's not broken), fix the compiler .

The limits were set to reduce RAM usage.

take_this_cup_of_poison wrote:Backup you q3map2 binary (/usr/games/q3map2) and replace it with this:
https://cat2.optus.nu/cat2/q3map2.bigvi ... oreplanes2
(make that q3map2)

(source: https://cat2.optus.nu/cat2/q3map2-bigvi ... ant.tar.gz)

Or you can use netradiant's q3map2.

Do these work on OS X?

try to add:
_blocksize 2048
to worldspawn, it might produce worse vis but should make map compile

Morphed wrote:try to add:
_blocksize 2048
to worldspawn, it might produce worse vis but should make map compile

Yeah, that worked. Thanks.

Now I see why the limits were there.

For 32bit users (e.g. Win32), q3map2 no longer worked after the limits raising patch, because it allocated more than 2 GB even on moderately sized maps (that would compile with a regular q3map2).

So for now, NetRadiant has the limits raising UNDONE. Anyone who wants to exceed the limits has to build his own q3map2 executable.

However, anyone who succeeds at making some of the limits dynamic (so they can be either specified on the command line, or even better, so they automatically extend themselves when reached) is welcome to submit a patch - that then won't break 32bit platforms.

divVerent wrote:Now I see why the limits were there.

For 32bit users (e.g. Win32), q3map2 no longer worked after the limits raising patch, because it allocated more than 2 GB even on moderately sized maps (that would compile with a regular q3map2).

Yikes!

Regardless of the size of the map?

Well, good thing I found another solution.