No matter what happens, keep going. Nobody expects miracles in your first map and neither should you - this is your first test bed for ideas. 

plugging bsp holes and bug fixing takes a while. I had problems where entire areas would scrunch into a mess with weird shapes.

I ended up redoing whole areas and brushes. Also I found that when you have too many overlapping brushes it tends to cause serious problems. 

offcut.wad by sock (found in ivory tower pak)
Quake101.wad
kdmtex.wad found here:https://www.quaddicted.com/webarchive/kell.quaddicted.com/
idbase_ultimate.wad 

https://www.quaddicted.com/webarchive/kell.quaddicted.com/ 

Make sure to go to Map Properties, then check the "Force integer plane points" check box. 

It keeps on error20.
E
ven a big box around it keeps args on the non-convex face. I can't compile it.
I'm afraid there are too many shape-brushes that are used as hull-brushes. Then there's always a leak-error. 

I used TxQBSP 1.13 to compile the map, and I thought it worked fine. 

>>> Parts of the map are outside the 4096 limit.

txqbsp_xt generated 33 warnings, mostly point-off-plane but some r_cutnodeportals also 

There are two convex shapes on 3288 -1276 608 and 896 -1572 128.
If I delete these brushes, (after surounding a box round the map) my compiler errors on leak.

I see you use convex brushes for the outer site of the map. (empty void) Not sure if that's a good idea, as the outsite brush becomes one of the three hulls.

I have no good experience with convex brushes in the outsite of a map. Even if they're well ligned, I alway seal them off with a cover brush. 

This only my personal opinion but I don't think anyone should use skip or detail brushes on their first map. This map is small and it's mostly one big open area, I see no need for either at this point anyway.

BTW, the part of the map that's outside the 4096 limit is the side with the waterfall.

I subbed some textures and ran it with no vis in fitzquake. Looks fine, I'll see if it will vis next. 

What do you mean by convex brushes? All brushes are, by definition, convex. 

with non-euclidean geometry of course. 

wvis.exe wouldn't vis the map with an error "LoadPortals: Not a portal file". I figured it was because of the detail brushes, so I downloaded the latest Tyrutils.

Well, the vis in that set of tools wouldn't vis it either

"LoadPortals: unknown header: PRT1-AM".

Why? I thought txqbsp_xt should work with it, it does detail brushes.

Oh well, I went back and BSPed it again with the qbsp in tyrutils. That one only generated 4 warnings, one about no deathmatch starts (!) and three of "WARNING 12: new portal was clipped away in CutNodePortals_r". It's been vising for over 30 minutes and "Calculating Full Vis" is up to ...7 should been done pretty soon (I hope). 

I have an email (obviously Gmail) but I don't show it here because I'm afraid that I could get hacked or have my personal information posted somewhere on the internet. 

Seems to be a problem with the Jury-Rigged Tools.

I've isolated the water-area and the vis glitch only occurs when a detail-brush is intersecting the water surface - in this case the crate.

TyrUtils does not show this glitch ( because Tyrann actually knows what he's doing ;) ), so i'd say use it instead.

You'll probably have to make some fixes to other parts of the map first for it to compile in TyrUtils though, i got quite a few leak errors in it and only the isolated water-area compiled on first try.

I'll investigate the problem tomorrow and hopefully come up with a fix. 

The detail-brush implementations of TyrUtils and the Jury-Rigged BJP tools are not the same and write different portal-file formats when detail-brushes are used. 

and no leaks with the Tyrutils qbsp. I wonder if this is because the map was modified then saved in Netradiant? All I did was change textures though, none of the brushes were touched. 

I never thought you guys would do all of this for me. thanks for your help. 

Wow, that thing took almost 2 hours to vis.

I looked carefully but I didn't see any terrible problems except - everything below any water surface is gone. Once you drop below the water surface it comes back. From inside the water looking back up everything is fine. It's very easy to see if wateralpha is set to something low like 0.01

I've isolated the water-area and the vis glitch only occurs when a detail-brush is intersecting the water surface - in this case the crate.

I compiled the entire map, the disappearing geometry problem also occurs at the first small waterfall and small pool of water. There are no intersecting detail brushes there. It definitely appears to be a vis issue because with r_novis 1, the problem goes away.

I'd like to remove the detail brushes and see what happens. I can't do that until tomorrow because it would probably take 8 hours to vis on my work/dev/internet computer and I can't tie up the living room computer for another 2 hours on Sunday night because that's the home entertainment machine. 

 

Once you drop below the water surface it comes back. From inside the water looking back up everything is fine.

I have to take the above statement back. Apparently I just wasn't deep enough in the water. When you're barely below the surface, it's okay, but go just a little deeper and everything above the water disappears also. I don't think you can get deep enough in the first small pool of water to see this.

Also, for the record, I used tyrutils version 0.14 for this (well, except for Light). 

Did you compile with -transwater switch in the bsp phase ? 

I just plugged the different exe and map names into the same batch file I've been using for years.

Seriously, that's not the default? 

With txqbsp and txqbsp_xt the switch is -nowatervis to disable transparent water, with qbsp it's -transwater to enable it.

I probably should have read the docs, but I've been using txqbsp since 2007 and it never occurred to me that any newer version of qbsp would not have transparent water on by default. 

Here are three screenshots. In your original five I actually wasn't sure where the problem was in a couple of them, but I could see the problem in the two shots taken from in the water near the crate. The last of your screenshots illustrates what the player sees when they cross one of the 4096 unit map boundaries.

In the water near the crate:

http://quaketastic.com/files/screen_shots/bre01shot1.jpg
http://quaketastic.com/files/screen_shots/bre01shot2.jpg

As you can see there are no problems.

Crossing the 4096 unit limit (this is normal):

http://quaketastic.com/files/screen_shots/bre01shot4.jpg


I have no idea if saving the map in Netradiant magically fixed something, but I was too lazy to download the texture wads you used, so I had to load the map in Netradiant so I could change them to regular Quake textures.

I used the Tyrutils v.014 qbsp and vis to compile the map.

I don't see any reason to give up on the map at this point. You do need to move the map away from the 4096 boundary. The map is basically one large open area, I doubt you're getting much benefit from detail brushes, but from what I see they're not the cause of any problems either.