Full: 52.13%, Elapsed 47h59m, Left: 331h33m, Total: 379h33m, 12%

I've got patience, but 2days left and 14days to go is a big heap. 

MadFox u must reduce many things... map is not that big for so many vis time... :\ guess u got to many errors in map! tchak is much bigger and just take 2 hours...
something is wrong... i�ve got almost 8.000 brushes! 

My current map has around 3,000 brushes and will VIS in under a minute. Seriously, turn some stuff into func_walls or something. :) 

There are 318 errors, but for vising it never took that long. P4 3Ghz.

http://members.home.nl/gimli/QBSPLOG.TXT 

that�s your problem MadFox u�ve got to many outplaced textures!!! you should fix then all...

I use to have these kid of problems... now in my maps i always have 0 errors!!! this is very important for the compiler...

will give you a pain in the ass for 2 or 3 days... but will compile real fast, you will see...

last map i try to compile with errors was wbase... i ~had also a lot of errors~becouse of rotating peaces of map and gave me many errors... took me two days to fix then all but after that was all pleasure!!! :) 

That's a serious number of errors indicating lots of not-so-great geometry in your level. I would agree with Trinca here. Take a day or two and see if you can clean it up and get the error count reduced. I'll bet you speed up some after that since you won't have little cracks and slivers in the BSP anymore. 

Doesn't a mixed face contents situation even prevent the map from loading? Shouldn't be too hard to get rid of those.

As for the "healing point.." warnings, you should check your map for HOMs and clipping issues (nonsolid brushes). Use gl_clear 1 and set r_clearcolor to something salient - BJP's engine defaults to a bright red, for example. This way you can easily spot problematic areas.
The issues are most likely caused by floating vertices or deformed brushes. If there are odd rock formations for example, it might be better to build them from triangle brushes, for they are more flexible than cubes. 

It is also generated by very tiny brushes, like clip brush used for ladder, rather than using func_ladder when available... Generally not a big problem...

Mixed face content is more problematic, as sky/water/etc... could then become solid on one face... (particularly sky)

And now go map ;) 

Your need to simplify the map SOMEHOW.
Maybe make some things func_illusionaries. Anything you can make an illusionary will help.
You can make something an illusionary and put a clip brush over it so that hull 1/2 are simpler, and marksurfaces and clipnodes are less.

Your vis will go from 13 days left to 1300 days left in 650 days.

Remember - 90% of vis time happens in the last 10% of progress. 

Wasn't the map leaked and boxed? I'd really try to fix the leak, it will make compiling much faster, result in a more performant .bsp file and maybe even teach you new approaches or ideas. I always hate it but the feeling of having a "proper" bsp afterwards always makes up for it.

http://user.tninet.se/~xir870k/tooltips.txt has a lot of infos on leaks. 

Oh, you might be right. I don't see a message in that error log about a "prt" file being written.

Is the map leaking? If so, drop everything, full stop, fix the leak. It'll compile WAY faster once you seal it. 

Sorry, that sounds dumb. What I meant to say was ... is the map boxed because it has a leak? If so, remove the box and fix the leak. You're processing a ton of stuff that you don't need to be outside of the play area. 

the map have many leaks i saw many of then when i beta!

Madfox u must fix then all... 

??? 

Main problem with leaks is they are sometimes very difficult to solve... furthermore when you are not cleanly mapping (i.e poly and textures off-grid !!!).

The only way to verify you are not generating garbage is to compile a sealed map very often, in order to progress very safely... And when I say "sealed map", I mean a sealing done by huge boxes that occluded the non-finished areas... like "hole-fillers".

If it does not prevent from HOMs (it happens sometimes), it helps a lot anticipating issues before the latest complete map compilation with the tons of warnings/leaks/HOMs/whatever fucking problems you might have onto your final big map...

Believe me, it unfortunately slows down your mapping speed, but it gives more safety in map result...

You should consider make iterations of compilation using occluding huge boxes in order to isolate your leak problems, and solve them one by one... or more ;)

Good luck ;) 

And/or newest version of Wally?
Thanks 

Haha, shit. 

JPL speaks the truth, IMO. I regularly stop and throw in temporary walls to block off new passages and doorways in order to verify that I'm still in "valid map" land. If I can get a clean compile and VIS, I'll remove the blockers and carry on. But not before.

It's too painful to do a huge map and then get one of those oh-so-wonderful leaks where it doesn't generate a pointfile. Good luck fixing that! Grr... 

this is actually an interesting point. When I made my early maps (chaos, rubicon) i just left openings to the void, and it was no big deal. Since i used software quake, the grey looked nice anyway.

Then, switching to quake2, the compilers wouldn't even calculate lighting without a sealed map (if i recall correctly) so i got in the habit of capping off any doorways/hallways to unbuilt areas.

Now that habit stays with me in any engine. And it definitely helps reduce leaks. 

sorry for that, just cut the vising after three days random vacuumcleaner sound. I only had 400 houres to go.

I had to give the outside box a heap of 16, before it stopped leaking on b_models.
After I could seal the box compact to the map without leaking I thought it would be ok.
Fastvis when fine and there were no homs.

And to be serious, if I point to the so called bad area's I end upon somewhere between brushes I can't get a hold which one's ment. 

I thought the corridor blocking was standard practice, but I remember now I learned it from HL1 and Q2. 

http://www.quaddicted.com/wads/
Great to see you GOing to MAP! 

.. it is time to open a Best Mapping Method Thread :P 

are there people who want to test a fastvised map, or is it against the rule to publish a not best vised map? 

For beta testing: I always send fastvised map.. fullvis is for final release ;)