When I tried to load it up it would not compile. I waited over 2 hours. Also when I tried to use hints and area portal they don't work for me or I put to many or to little in other spots. Also with the no draw when I try to do it would always go into the playable area. I would have to recreate the entire map to put in no draw.just because your computer couldn't load the map you put it on here? you could just tried to fix it so it would load
i would just recreate the mapWhen I tried to load it up it would not compile. I waited over 2 hours. Also when I tried to use hints and area portal they don't work for me or I put to many or to little in other spots. Also with the no draw when I try to do it would always go into the playable area. I would have to recreate the entire map to put in no draw.
I don't want to waste those hours of building the map just to tear it down.i would just recreate the map
When I tried to load it up it would not compile. I waited over 2 hours. Also when I tried to use hints and area portal they don't work for me or I put to many or to little in other spots. Also with the no draw when I try to do it would always go into the playable area. I would have to recreate the entire map to put in no draw.
If I don't use big brushes that mean there will be more to compile.long compiles = bad optimisation and/or skybox brushes that are just a big box around the map
and that nodraw comes to the playable area means you use big ass brushes
Where do you even get all those weird statements of yoursIf I don't use big brushes that mean there will be more to compile.
Well I get these statements from myself. I am just useing logic. If you think about it. If there are more of smaller things there are more things to compile. If there is one big brush to compile then there is only one.Where do you even get all those weird statements of yours
Well I get these statements from myself. I am just useing logic. If you think about it. If there are more of smaller things there are more things to compile. If there is one big brush to compile then there is only one.
I used func_details correctly. I have textured the faces that players could not see but then on the other side from a different part of the map players could see the no draw. So I just changed it all back to dev textures.Kind of, yes. But the compiler is designed to be able to compile lots of small brushes quickly, thats what it does. Don't just use your own internal logic - look this kind of thing up. If your compile is taking a long time, this is probably for other reasons. Have you used func_detail correctly? Have you textured faces players can't see with nodraw?
I used func_details correctly.
The outside path are like the ones on Upward. It's suppose to be a cliff edge.The way you've designed your map - with players able to move around the outside - means that you can't nodraw a lot of it. You also can't have the skybox fit closely to the map, instead being forced to have it as a box around. This means compiles will take longer. You can definitely move the skybox floor up to the bottom of the map - look at the picture below. All of those faces are calculating light, all of those little bumps and edges are calculating visibility!
![]()
I'm not sure what these big outside paths represent or do, but I would seriously consider getting rid of them or turning them into corridors, they're an optimisation nightmare (And too flat and open to play very well anyway). Combine that with the sheer vast size of the map, and no wonder compilation takes a long time - you must practically have two maps in one file from a VVIS perspective.
Where you haven't used huge brushes (8500 units long!), you've split them up very strangely. Look at this:
![]()
That's probably not actually making your compile longer but it is baffling inefficiency.
You also haven't func_detailed nearly enough. Some things that don't block player visibility much so should be func_detailed:
![]()
![]()
![]()
![]()
![]()
![]()
Also how i made this map was i had a scrapped map that was very small. So i just that map and smashed them together. It was much faster then creating a entire part of the map.The way you've designed your map - with players able to move around the outside - means that you can't nodraw a lot of it. You also can't have the skybox fit closely to the map, instead being forced to have it as a box around. This means compiles will take longer. You can definitely move the skybox floor up to the bottom of the map - look at the picture below. All of those faces are calculating light, all of those little bumps and edges are calculating visibility!
![]()
I'm not sure what these big outside paths represent or do, but I would seriously consider getting rid of them or turning them into corridors, they're an optimisation nightmare (And too flat and open to play very well anyway). Combine that with the sheer vast size of the map, and no wonder compilation takes a long time - you must practically have two maps in one file from a VVIS perspective.
Where you haven't used huge brushes (8500 units long!), you've split them up very strangely. Look at this:
![]()
That's probably not actually making your compile longer but it is baffling inefficiency.
You also haven't func_detailed nearly enough. Some things that don't block player visibility much so should be func_detailed:
![]()
![]()
![]()
![]()
![]()
![]()