is there anyway to change this value?

No, you have to learn detail and hinting :p

So many people for some unknown to me reason want to avoid ever learning this!

http://www.nibsworld.com/rtcw/tutorial_detail_and_hint_brushes_part1.shtml)

Enjoy:cool:

I KNOW DETAIL GOD DAMNIT, please dont insault me like that........

I need to make the visibility larger as I am making a flight map as in you fly around in ships and stuff, and the normal max visibility map size is WAY to small for a ship fight map, SO anyone know a way to change the value.

If you ever say max_map_visibility in forums, expect that reply. It is the most common one, replying with capitals and "GOD DAMN IT" won't help. You didn't specify it was a large map and I am no trans-internet telepath. Any insult was unintentional on my part...your part however is a different story.

Worldspawn
key:_blocksize
value:16384 16384 16384

sorry for the whole misunderstanding as I got that impression....so ok all is fine and dandy now :D

Hey wade, thanks for all the help youve been giving me recently, been helping me allot. Also I was about to ask you about this, but seems youve already answered it for me. Thanks again.

lol been helping you so much it's becoming pre-emptive ;)

Uuumm..Wade, is that not the default size that Radiant uses anyhow? Or do you ACTUALLY have to put the blocksize and number in? Making large maps like these cause framerate drops. Trust me I know what I'm doing. I think KOTOR map is about the maximum size you can go without the FPS dropping like a rock. Mr. Jay must have made some of his flat ground areas structural along with some structural asteroids. I don't think you can have PORTALS without them.......

Please let me know if anyone knows different.:rolleyes:

Default block size is a mere 1024x1024x1024, you can imagine the vis data for large maps if it's split that frequently.

Trust me on this, large maps do NOT cause frame rate drops if done properly. It's a matter of finding a way of working around vis data and distance culling. On planet maps this is easily fixed by using a fog hull or large structures to block off vis. Space is harder. Kotor's problem is not that it is big, it is that there is no vis blocking at all and too many NPC vehicles. Vehicles that have effects such as rocket blasts are FPS killers. They rely of excessive efx file usage which pile on the CPU and the GPU.

my ausome space_fight map I am making is at least 20 or more times larger than kotor and i have yet to have any slowness at all what-so-ever and it has lots of ships as well.

The REAL answer is, don't try to make a flight sim with a first-person-shooter engine.

why you say that the flight engine for JA is great VERY VERY fun and with my map will be more fun.

Originally posted by WadeV1589
Worldspawn
key:_blocksize
value:16384 16384 16384

Yeah, way to make the framerate fall through the floor, especially if you have a lot of brushes or terrain. Try something like 2048 2048 4096.

Emon I know you're a resident expert but I have to disagree, I've used that value in my map which has detail galore but it runs at full FPS for me. This is even with terrain and models in view. I have an old GF MX420 that can push 90fps (my limit) on my map and anyone who knows me will tell you that I never spare detail.

Originally posted by Emon
Yeah, way to make the framerate fall through the floor, especially if you have a lot of brushes or terrain. Try something like 2048 2048 4096.

I am agreeing with Wade here. It all depends on how your map is built. And having a lot of brushes actually will help (if they are structural) since they will add extra leaves and portals.

It has nothing to do with leaves or portals. It has to do with collision detection. The engine only checks for an entity's collision inside the leaf nodes that it's inside. Wade, your map wasn't really that complex, I'm talking about when you start to get thousands of triangles in a leaf node. Besides, if you have fast CPU (video card is irrelevant), there isn't any way for you to determine if it would run worse on a lower end system, because r_speeds' output isn't going to change.

And making all your terrain brushes structural is, uh, kind of stupid. It'll take massively long to compile, and then the PVS will grow to be monstrously huge, which will eventually affect in-game performance.

Wade, your terrain wasn't very complex, it wasn't tessellated much more than the original Q3:TA terrain. I'm just saying when you get into having thousands of triangles in a leaf node, it does get slower. Collision detection will be happening against thousands of triangles every frame.

In your first post all you said was "big blocksize is bad", which you have to admit is wrong to say. Your further explanation is far better..if not debatable still on some levels. You have to admit though your first post was far to vague to be correct on any real level.

Yeah, it was. But it's bad to go shouting to use big blocksize, without a reasonable explination, because he'll end up having the problem I was talking about somewhere along the line.

Originally posted by Emon
And making all your terrain brushes structural is, uh, kind of stupid. It'll take massively long to compile, and then the PVS will grow to be monstrously huge, which will eventually affect in-game performance.

I'm not talking about making the terrain structural. You can place large caulked structural brushes inside terrain. It gives you the necessary control to change the visdata of the map. If you got a lot of structural brushes your visdata should be split up nicely and you would get a good balanced portal size.

Actually, you should use antiportal for that instead of caulk.

caulk, antiportal.........wow am I confused :)

also my space_fight map has a fair amount of detail and is super massive in open size, for all that space fighting :), and I experence no slow down in compile times and no slow down in fps ingame so I dont see why Wade's block size thing is bad.

It depends on the amount of crap you have in your level. In my Hoth map, I had terrain that was about 13K polygons for a single mesh, and I set the blocksize to be 32K, and the framerate went through the floor.

If you're doing a space level, you should probably set blocksize to straight 4096 when you compile, maybe 2048 (turn off vsync, and compare framerates on both). You can use a higher one for tests, because it'll compile faster.