me 2 lol

Ok doing it that way just took seven minutes Lol where the anticipation it tnat Hee Hee, so what does the vis do then if its ok without it One other thinggot some warnings during light faster bit any1 got clue

--- IlluminateRawLightmap ---
0...1...2...WARNING: Hit per-surface style limit (4)
WARNING: Hit per-surface style limit (4)
3...4...5...WARNING: Hit per-surface style limit (4)
WARNING: Hit per-surface style limit (4)
WARNING: Hit per-surface style limit (4)
WARNING: Hit per-surface style limit (4)
6...7...WARNING: Hit per-surface style limit (4)
WARNING: Hit per-surface style limit (4)
8...9... (29)
0 luxels illuminated
--- IlluminateVertexes ---
0...1...2...3...4...5...6...7...8...9... (3)

DiVeRSion. What is found is this:

you have too many styled lights hitting a single surface


So if this is the case remove some of the lights which could amount to 4 maybe.

Let us know if you fix it with removing some of the lights.
If you fix this problem by removing some of the lights we can add this to our Common Mapping Errors. Don't know how common this is though, it's the first time I had seen it.

Here is some more info from the GTK Bug Report. The Google search engine is one of the best troubleshooting tools around.

Quote:

Your map either has one of the following: - Light entities with too many different "style" keys OR - You set up spotlights incorrectly, targetting the light instead of the info_null/target_position. Unless you want a switchable lightsource, *a light entity should never have a "targetname" key*. If it does, Q3Map2 assigns it a style. Every unique targetname used on a light entity becomes a unique style, and will quickly overflow the limit.

it'll be the style thing and i bet some got mixed up on the chandeliers will delete a few think ive got to many models and not all are turning up in game.
didnt think it was that many but id rather lose fancy bits than sandbags placemants also not all windows smashing seems to just be the security ones.

Right even though a bsp meta and light faster ( ty for tip) has given me working map some sound threads seemed to say they didnt work right until a final was done. S I have done another also some might be interested by lower compile time.

9 hours 30 minutes, nearly halfed. Righ as to how I believe This was done using the research from this thread and site.

as this was 2nd map some stuff was learnt during its process so some odd places came to be

1st Underground first time was structural all round to meet with skybox at edges but kept getting a leak that the editor would not show so dropped skybox to below all and shut off with easy flat surface (leak resolved) but in the process had made an open air section below my map. with lots of jutting out bits and the main part of map a hill the underside probably had as much space as above so I proceeded to make caulk brushes to fill in the gaps in a rough way then some vaguesmaller grid chunks to do some sealing( there is still open air down there but is now chopped up into small pieces) before you could have put the map raven down there 3 times poss by only crossing 2 of my corridoors.Lol

2nd During all this I learnt the ctrl-alt-shift surface selection (which I had missed in my haste to enjoy this overgrown lego set) a bit late. but went down and painted all surfaces with caulk then went above and scoured every where in map for mistakes , there were a few (shafts from underground - above) so fixed that.

3rd some threads point (poss this one) to placing stronger lights around as darkness is harder to compile so as this had been highlighted in playtest anyway as main building to dark I added a plethora of lights many shapes and sizes (some l8r to be checked and a lot of style checking see earlier posts).

4th skybox lowered and angled slightly so as to meet potential snipe lines from tallest points. not as much as I could have done b4 I did step 5 so this may not have helped as much.

5th removed my ugly crappy tents i made and replaced with larger more interesting structures which block some longer views but was careful with their height so as not to give to far extended view from above.

6th final pre bsp checks ran bobtoolz brushcleanup fixed 4 brushes pressed ctrl d to hide detail and was shocked to see part of main outdoor hill floor was gone (poss the prob that led to leak I mentioned b4) so checked all structural was there and then started adding detail again ( I found it handy to leabe detail hidden during this so things dissapear as you do it so even tually you have a barebone version of map)

With all that done a final compile was halfed how much each thing did I cant be sure. But it was passagportalflows point 8 and 9 that take longest, My map has vast open air and the main building that splits map in two has more than a few points where you can snipe through windows from far sides so this long time is normal it seems. (my next map is gonna be tight and crammed and claustrophobic with one room of open space to fight for i think) thenmaybe it will do a final in an hour Lol. to the point though why do a final compile when youdont have to my sound still did not play and I dont want to do a final compile everytime to check sound is configured right Ive read as many posts as I can on it and was sure it was right before doing a long final but hey I'll keep searching and if its not done in a week the question will be posted here you can bet (I'll give as much detail as poss, vague questions annoy {as much as vagueanswers}).

VIS shouldn't take more than a few minutes to process. If it does, then your probably going to get excessive and unnecessary portals as a result of having too much structural complexity. Light should be the only stage than can take hours to complete, depending on your settings.

The BEST WAY to SEE what's taking so damn long is to use prtview plugin (included with GtkRadiant). This way you can see where all that compile time is going.

When you compile, ALL the empty space inside the hull of your map (structural brushes) is going to be filled with shapes...the sides of those shapes become portals. If vis is taking too long its because the compiler is having to create too many of these "shapes" using small or irregular geometry. If you can simplify structural brushes and make complex details into "detail" your VIS compile time should go alot faster.

Again, if you really want to see why it's taking so long then use prtview. That's what it's there for (and it's not hard or scary at all).

P.S. Did you say hill? Like as in a gensurf, or other terrain? That should be DETAIL!!! You DON'T want a node to be created for every single trianglular brush in that terrrain. That would be bad for performance and very bad for compile time. Make a structural brush under a terrain to seal off the hull, and make the terrain detail

I dont use gensurf as I wanted hill built perfectly to my liking or as near as the math would make easiest. is 24000 odd portals excessive Lol i think thats how many it ws , cheers 4 info it would explain alot.