MAX_MAP_VISIBLILTY

(LaggingTom) #1

Grr. Damn maps. I swear, I’m being driven to insanity.

Okay, my entire map is detail brushes except for 18 brushes which are structural and keep my map blocked out from the rest of the world. Now, when I take out the largest hollow box and have just the two sections of my map boxed seperately, because one is tremendously huge, I get a leak, and I’m unable to do a vis compile. When that gigantic box is there, I get the max_map_visibility error. Is there anything I can do to make it work?

(Mark.C) #2

Make it smaller ?

(LaggingTom) #3

I wish I could, but it is a trickjump map. Every unit that is used NEEDS to be used.

(carnage) #4

hey its pretty bad practice but you could always turn off stop compile on leak

(Chruker) #5

You might want to adjust the _blocksize worldspawn key. Perhaps setting it to 0 to disable q3map2 from slicing your map every 1024’ish units.

(Ifurita) #6

You could also segment the large brush into smaller pieces. I remember getting that error because I have some very long railings. I cut the railing into 2 halves and the map compiled fine after that.

(pazur) #7

you might have too much structural brushes. this ends up in a too high visdatasize and you get the error message. i guess it aborts the light compile stage also

make brushes detail… or increase blocksize in worldspawn (as mentioned here before)

:drink:

(Ifurita) #8

Nope. If you read his first post, he says that he only has ~18 structural brushes

(pazur) #9

then “tremendously huge” means its just too big to be compiled. btw who is going to play a map of this size :bash:

(Ifurita) #10

nm, my other problem was a max_surface_verts error. Sorry for the confusion

(LaggingTom) #11

pazur, it’s a trickjump map. None of the rooms are actually connected, teleports will move you to the next jump upon completion.

Cheers, Chruker, _blocksize 0 fixed it. Thanks lots to everyone :slight_smile:

(LaggingTom) #12

Yay for recurring problems. It popped up again, and I’m using _blocksize 0. I only have 6 structural brushes, and they are the big box that surrounds my entire map. You don’t even want to know the dimensions. Anyone have any suggestions aside from making the map smaller? :\

(SCDS_reyalP) #13

Exactly how big is the map, and does it really need to be that big ? If you describe what you are trying to do, we might be able to suggest other ways of doing it.

Why does it leak ? If you can make it not leak, without enclosing the whole thing in a giant box, that may well solve your problem. Make sure you haven’t inadvertently reset _blocksize. Take a look in the portal viewer and see what is going on.

(LaggingTom) #14

portal viewer won’t work because I don’t have a .prt file. Vis won’t compile.

I made the giant box because I have seperate little levels that are inter-connected via teleporters. It leaks because of the connections between the teleporter entities.

The dimensions of the huge box:
17432, 98080, 15424

(Ifurita) #15

I use teleporters in decerto and tactical, the paths of which extend into the void. Neither suffered from leaks

(SCDS_reyalP) #16

BSP creates the .prt file, vis uses it. So yes, you can.

I made the giant box because I have seperate little levels that are inter-connected via teleporters. It leaks because of the connections between the teleporter entities.

That is not correct. It shouldn’t cause a leak, in my test, with a trigger_teleport and misc_teleporter_dest, it doesnt.

The dimensions of the huge box:
17432, 98080, 15424

(LaggingTom) #17

What is the switch that would save the prt file in BSP, because it didn’t work for me. I did a basic BSP from in Radiant and tried the prtview plugin to search for the file, it didn’t find it.

Also, I took out the big box, and instead, I had smaller boxes around each of the three sections of my map. On the biggest, I always get a leak, even when I put the leaking entity in its own caulked box.

(Chruker) #18

-saveprt

(Chruker) #19

Looking at my batch compile files, I see that I have the saveprt options when compiling the VIS stage.

(FireFly) #20

This is taken directly from the ‘default_project.proj’ file in etmain/scripts:

  <key name="bsp_Q3Map2: (single) BSP -meta" value="! "$TEMPLATEapppathq3map2" -v # -game et -fs_basepath "$TEMPLATEenginepath" -meta -mv 1024 -mi 6144 $"/>

  <key name="bsp_Q3Map2: (single) -vis" value="! "$TEMPLATEapppathq3map2" # -game et -fs_basepath "$TEMPLATEenginepath" -vis -saveprt $" />

So one would conclude that the prt file is only created during the VIS stage…

However (and I’ve just tested this) when you do a bsp-compile only, within gtkradiant, it also creates an prt file…I checked the compile log and it confirmed this.

LaggingTom wrote:
portal viewer won’t work because I don’t have a .prt file. Vis won’t compile.

BSP creates the .prt file, vis uses it. So yes, you can.

But if there’s a leak you will not be able to do a BSP compile, so no prt file will be created…