the more it breaks... Ok I thought that cleaning up the map I made in TB v1.0 using TB v1.05 would provide some kind of solution. But the more I fix the tri-soup the bigger and more numerous the holes become. I might go back to TB v1.0 and clean up the holes there instead.
It's becoming an issue to an extent where I may just release a buggy .bsp file and the .map src for people to mess around with.

SleepwalkR, I love the editor and I hope you manage to fix whatever the problem is. The real concern for me now is I may have to resort to Worldcraft again until it's fixed, which I really *dont* want to do. 

Tb is not magic, so the limitations of the map file format still apply. It would be interesting if you could post the map file and let me know which brushes are problematic. Then I can see where it's going wrong.

Vertex handling is different in 1.0.5, it will mask less errors. But it still suffers from problems related to floating point coordinates one the map file.

I would generally suggest to always seal your map even if it's work in progress. That way you'll see immediately if something breaks instead of getting overwhelmed by a sea of errors. 

No that's understandable and to be honest this was a test/learning map that got out of hand and became a real map. I think my best option may be to remove all the fancy terrain style geometry (and box it up), and then fill all the normal leaks first. And *then* I can retry making that geometry with a more robust approach (or even starting that part from scratch in 1.05). Basically I thought I was pretty much done with map but it looks like we have to spend a little more time together before we move on. 

did you mean to say mask or make? 

TrenchBroom generally tries to hide the fact that vertices often don't have integer coordinates, but that approach is flawed and I'm working on removing it. 

I noticed stuff like tetrahedrons or brushes with a lot of vertices lend themselves well to map corruption in TB. For rocks or terrain just mashing deformed cubes together is more work but seems more stable at the moment. 

my terrain is completely cube-based. I didn't consider making it any other way.

A lot of the problems have come from my work method of basically making the level in an open room-by-room fashion. I could have avoided a lot of problems if I had blocked the layout first and then added all the details second. Maybe... I dunno, I'm still learning. 

He has the most experience with mapping with TB. 

Ok, I chopped out *all* the terrain brushes, blocked in those areas to stop them leaking, fixed all the pointfile problems and got a build that vis'd... I have a couple of HOM's (that don't leak for some reason) and that's it.

So my todo is simply to try and remake the terrain without getting any leaks. I have a couple of ideas on how I might achieve this, I think the problem was the void-facing terrain were misshapen rather than nicely boxed and uniform.

It's a bit of a nightmare but I have definitely learned a lot in the last couple days. 

Quake is ooooold and rickety. Expect problems. :) But it's fun... 

If you can pull it off and learn some best practices, make sure to write them up on the QuakeWiki or here, please! 

The whole process has been a big ol' practice! That's what the map was about. I have keep a lot of the different stages of the map, so I can easily do a mapping retrospective.

As for the writing I don't really have a desire to write it up on the wiki, but I really want to have a go at making some youtube videos on the process I took, lessons learned etc.
I'll start pestering my film-maker friend until he caves in.

Pro-tips:-
-box out your map/layout
-use trenchbroom 1.05 from the start
-get your hands on TreeQBSP from http://user.tninet.se/~xir870k/
-become best friends with the "pointfile" command and "r_showtris" 

*does* seem to have better vertex accuracy for more standard shaped geometry, after I did all my pointfile detective-work I selected all the brushes and did a correct vertices & snap vertices... seemed to sort out the last remaining HOM's on the map.

Only trouble now is I have no terrain in my map after I brutally removed them all. I'm going to do it bit-by-bit and *hopefully* the map will have it's finalised geometry! Then I can get back to the fun stuff, testing, item placement etc. :) 

I was talking about what to avoid specifically for TB. Apparently there are some things which will lead to bad brushes etc. and I'd like to know how that happened. 

The map design videos would be TB-centric.

In terms of how to avoid bad brushes, who knows? I never took off grid snapping and I almost never went below the standard 16 units. I think some brushes just "become" malformed if you play with the vertices too much or you make shapes that are just too crazy!
Even some of the (very plain) curved walls which were grid aligned had become very very slightly nudged off the 16 unit grid. It wasn't until I did the correct/snap vertice trick that it was fixed.
Again, the tools used for pointfiling and treeq really helped me to get to a water-tight map. Though I think whatever you fixed between version 1 and 1.05 obviously helped a lot. I just hope I can redo the terrain, that *IS* after all one of the big selling points of TB ;) 

A QuArK in disguise!!! 

I was using the co-ordinates and the pointfile to find leaks (as is the standard procedure), and to locate them easier in TB I was dropping in a monster_boss entity and entering the co-ordinates in the "origin" key, then when the entity moved I would delete and replace it with a shambler (again with the same co-ordinates), and then with a rottfish. Only last night at 3am when I was looking for the leaks I had forgot to take the shambler out the map when I compiled the fixed map... It scared the bejesus out of me! I decided that was a good time to stop mapping and sleep. :D 

those problems are mostly the result of imprecisions when loading the map. I'm working on an improved version of the vertex generation algorithm that will do a better job of avoiding degenerate edges and faces.

An edge is considered degenerate if it is very short (shorter than 0.5 units) and a face is considered degenerate if it is a triangle and contains such an edge. This should help avoid such problems, however I can't predict whether QBSP will do the right thing, too. But I think everything will be much better if I can switch TB to use only integer plane points. 

You're not too far off there, sadly. 

those problems are mostly the result of imprecisions when loading the map. I'm working on an improved version of the vertex generation algorithm that will do a better job of avoiding degenerate edges and faces.

That might explain why some problematic brushes (one that caused a crash for instance) look completely different when reloading the map?

In terms of how to avoid bad brushes, who knows? I never took off grid snapping and I almost never went below the standard 16 units. I think some brushes just "become" malformed if you play with the vertices too much or you make shapes that are just too crazy!

Pretty much my experience.
One thing I think can be problematic is adding new vertices, in certain cases those can create strange n-gons that almost certainly will get screwed up after a while. Also dragging planes on a non-grid-aligned plane tends to end up badly a lot of times (especially in conjunction with above case). I guess that kind of makes sense when you think about the floating point issue... 

That might explain why some problematic brushes (one that caused a crash for instance) look completely different when reloading the map?

It might ;-). I can't say without seeing an example. 

you're running into the same type of problems that plagued Quoole 0.99 (creeping brushes). I hope that you can figure it out and fix it. 

I promise that I will find a solution, even if that means that vertex editing has to be dumbed down a bit. 

That would be a great shame because this is one of the best features of the editor. It would be a shame to fall into the trap of GTK 1.5 and force mappers to only create limited brush shapes because of vertex problems. Personally I prefer the ability to push brushwork to the limit and then have tools that look for problems afterward.

I personally use SDRadiant 1.8.3 and when I get issues with brushes I take the brushes and cut them. This forces the editor to re-generate all the planes and this usually fixes most of the problems. One other solution is I use an editor plugin called Bob's Tools. This goes through the whole map looking for potential brush plane errors and re-creates any brushes with problems. When it is finished it highlights what has changed (selected) so I can decide if to save/carry on. 

I liked how Quest would allow me to make invalid-shaped brushes which I could sort out afterwards, whereas in GTK 1.5 I always have to go out of my way to create properly angled (rotated) or abstract stuff, because its validation system is so overly rigid and limiting.