One thing I found with terrain mapping (lots of wedge brushes) is that if it's a long thin wedge then it won't break, but usually breaks any thicker wedges nearby so that the leak goes straight through a solid brush. The only decent way to het round this is avoid thin wedges, or else have a big block inside your terrains, usually alot of em, though that's a ugly and wasteful fix.

Other than that turn all pillar / pipe / cable flanges into func_wall or else leave them 2 units from touching the wall or floor. The second can still produce vis crashes if you have lots of them but the first is completely safe, as long as you don't breach edicts.

As than says use the check for problems function, but don't auto-fix. If you do have invalid brushes you may not be able to fix them without creating from scratch, though that depends on how complex they are.

Can't think of much else (I assume you know about the pointfile command - type it ingame at the console and it's show a particle line pointing at the precise location of the leak).

Hope that helps. 

Yeah, i am using Worldcraft.

Than:
It appears i have been caught. I was using the method outlined in CZG's curve tutorial to bend a 3/4 piece of hollow pipe (roughly 256 in diamter, with 32 thick edges). When using this method, i found that the edges weren't aligning on the vertices with exact precision, so i using vertex manipulation to get it right. I then got lazy and started doing it purely with vertex manipulation. I'm guessing that might be the problem part.
I have used the "problems" feature, and it claims that the map is without error. It once had errors, but i fixed them manually, and then worldcraft seemed to like it enough to not give me an error.

Distrans:
Thanks, it's been a long time, my mapper's block had gotten so bad that i just decided to stop for like 6 months. Things seem to be going good now. Hopefully Travail isn't giving you splitting migraines.

aguirRe:
Thanks for the offer. I'm not going to be able to touch Worldcraft again until maybe tomorrow, most likely Friday, so if i still can't make the bad leaks go away i'll drop you a line.

ijed:
I wasn't specific enough in my post, but the "pipe" i spoke of is actually the hallway, so i'm not sure if making something like that would work as a function_wall. I may be mistaken, but i'm not sure if i could use a function_wall as a border to the void.
What you said about terrian is interesting though, since i do plan to use a good amount of terrain in my map. What do you mean by breaking brushes, wedges and leaks through solid brushes? I don't quite understand the explanation.

Thanks for the help all. 

Nope, you can't use a func_ to stop void ;)

The pipe thing (I use the czg method as well) is awkward, you've got to figure out the system of thinking in base 8 and even now I end up redoing it a few times to get it right for a corridor or whatever. I wouldn't recommend vertex manipulation for this - it'll drive you up the wall.

Also, you can just make a blocky corridor when seen from outside, then make it round on the inside with the 12 sided cylinder and double-wedge corner piece. Since the outside is void and not world nobody'll see it.

By blocking off broken brushes I meant putting a quad brush inside your terrain, sealing any hole it has from the void - but this is a big waste and will fuck vis.

When making terrain copy and paste a single unmodified wedge as many times as you'll need it then vertex adjust each piece seperately - WC tends to create errors when copying multiples of these. Either tiny misalignments (leaks) or a slight lip in the ground, so that you hit an invisible wall in the game when walking in a certain direction and then can't get unstuck. 

One other thing, probably something else you already know, but I didn't figure this out until a long time of using WC - you can move the camera (not just rotate it) in the 3d view with right click.

If that helps. 

Thanks for the heads up on the camera deal. I always found it annoying that the camera use was limited. That makes it better to use. 

they are great.

In addition to being able to move the camera around in both 2d and 3d views, you can create multiple camera views per map by holding shift and dragging in the 2d view when in camera mode. There might be a key to cycle camera views, but I don't know it if there is. Deleting a camera will return you to the last one create before that, or just the default camera (which doesn't have any icon in the 2d views).

In addition to the mouse controls, you can also move the camera around with d/c (zoom in, out - also works in 2d views) and s/f (roll, not very useful). Also, if you learn the shortcuts to switch between camera and other modes, the fact that controlling the camera requires you to be in camera mode (aside from moving it via the keys) won't slow you down anymore. 

iirc, it's page up & page down to cycle through cameras...been a while for me though 

pgup and pgdown work, but only in camera mode. In selection mode they seem to do something weird, like add the previous selection to the current one. Maybe you can use it to get the last selection if you lose the selection.

...hmm, just tried it, and in selection mode pgup and pgdown have very odd behaviour. This is what it says in the WC help:

PgUp - previous selection in "hit" list
PgDn - next selection in "hit" list

Whatever the fuck that means. 

I think that many WC and Hammer users should spend some time reading the users guide included in the program. It is an interesting read. There are many tips and pictures. All the features mentioned above are described throughoutly.
Here is a section from Hammer manual about the cameras:


Using Cameras

To take advantage of the 3D view, you need to be able to place cameras. Cameras determine your vantage point(s). Hammer provides you with precise control over the camera movements in your map.

A camera in Hammer (as displayed in the 2D views) consists of two parts: the eye, and the viewing angle, which is represented by a line extending out from the eye. The length of the line that represents the viewing angle is not important, though it can help you aim the camera exactly at an object.

While it is possible to move a single camera all over the map each time you need to look at something new in the 3D window, it is more convenient to have easy access to multiple cameras placed throughout the map. Hammer allows you to easily cycle through multiple cameras by pressing PageUp and PageDown.

Camera Placement
Placing cameras in Hammer is extremely simple. First, switch to Camera mode by pressing Shift+C, then hold Shift and with the left mouse button, click-drag a line in one of the 2D views. This will create a thin red line with a large dot at one end. The dot is the camera's position, and this is where the 3D camera view will originate. The red line is the camera's viewing angle. You can adjust either end of the line to change the view. Follow the above steps to create as many cameras in your level as you need.

Note: There are a number of options available to you when using multiple cameras. You must have the Camera tool selected to take advantage of these:

PageUp: cycle up to the next camera position
PageDn: cycle down to the last camera position
Delete: delete the current camera position
Shift: hold shift and click-drag with the left mouse button to create a new camera.

Tip: While in camera mode, you can adjust the camera position by moving the eye or viewing angle in any of the 2d windows.

Mouselook/NoClip Style Movement
Version 2.1 of Hammer introduced a new style of 3D View movement called mouselook movement. It is designed to be the same as when you are in the game and walking around with +mlook (mouselook) and the NoClip cheat both turned on. It can be enabled or disabled by pressing (lowercase) z.

Moving your mouse around will change the player's direction of focus, while W and S control forward and backward movement, and A and D control sided to side (left and right strafing) movement.

The old style keyboard shortcuts (listed below) still work. You can disable this new movement style by going into the 3D View options and disabling use mouselook navigation.

Keyboard Shortcuts
There are a number of keyboard shortcuts that you can use to quickly maneuver through the 3D view without switching to the Camera tool.

While holding the spacebar:

holding the left mouse button allows you to rotate your angle of view in any direction, while the viewing point remains stationary.

holding the right mouse button will allow you to move left, right, up, and down while keeping the viewing angle constant.

holding the left and right buttons and moving the mouse causes the view to strafe forward, backward, right, and left. (note that this makes the following behavior redundant).

While holding the spacebar and Shift:

the left mouse button acts the same as above.

the right mouse button allows you to move forward and backward, as well as from side to side.  

read the manual :) The manual will also have information specific to your version of the editor, be it worldcraft 1.6a full (what I use) or one of the more recent Half Life versions/ Hammer.

There is no noclip style movement in WC 1.6a, nor is there any decent hardware acceleration, but I like it's simplicity. 

the below isn't described in the manual though :)

if you merge two solid ents, one always remains and causes problems, but can be selected by checking for problems and deleting it manually

I didn't know about the above fact but it sems to apply for hammer also. If I knew it before I could solve some problems easily.
Than seems to know many WC features and tricks that aren't described anywhere. 

that is one hell of a nasty problem if you don't know what the cause is or how to fix it. Still, you know now, eh? :)

The absolute WORST problem you can get in worldcraft, however, is when you use the clipper on a multiple brush (or single brush if you are silly) selection and accidentally clip along one of the faces of a brush. This creates an infinitely thin brush which will crash compilers and is a fucker to track down if you have added a lot of other stuff since creating the problem. If you know it can be caused by the clipper, at least you know roughly where the problem might be and in which brushes it is in. 

In WC is using the carver - this evil tool tends to destroy everything it touches. There's no way to delete it from the toolbar which is a shame. Another problem is clipping across multiple brushes that aren't touching (such as when using the czg curve maker method). It'll crash maybe 15% of the time, so always save before doing this.

Never really used the pgup pgdn controls, they didn't seem to follow the order of creation for cameras and in a big map it's pretty creaky switching all over the place to find the one you want. I'll give that a try again, though. 

I beg to differ. I will agree that carving can sometimes cause a mess of brushes. But, if you know how to carve carefully, you can avoid most problems. Almost all of the complex brushes in my maps were made by carving. Why? Because I know what carving likes, and does not like.

And in my opinion, carving is much much quicker than manually adjusting the surrounding brushes, which is usually a pain.
As long as you carve carefully, you should never have any problems. I use it constantly, and do not plan to stop. 

The more you save, the less it crashes. I don't know why this is, but I tend to save very frequently (at least every 5 mins) and it almost never crashes.

Using the clipper can sometimes cause a crash, but if I take it slowly and save between clips when using the tool several times, I don't seem to have any problems.

The only time WC really ALWAYS crashes is when I've been using it for several hours, done a lot of work and then exit. It always crashes when it's closing after a long day of mapping, but otherwise WC crashes are incredibly rare for me these days. Maybe it's my pc, or maybe I'm just naturally avoiding the things likely to make it crash. Hmm. 

That it likes to crash at certain times, so I ended up saving before doing anything I know is risky. I also save compulsively and rarely get crashes.

The one you mention, than, seems to be the compiler crash. It always happens with a bigger than small map build or two. It's not a problem since it's shutting down anyhow, but annoying when it doesn't remember last map worked on on reopen.

Orl - I thought you used QuArK? 

Why did you think I used Quark?

Ever since day one of mapping, I have always used Worldcraft 1.1a. And sometimes 1.6.

And 1.1a can crash much more frequently than 1.6, if your not careful. 

;)

Always use 1.6a, tried the 3.3 conversion but it needs some stuff ironed out - the wad limitations mainly. 

I have my reasons for using 1.1a than 1.6.

And yes, I did try the 3.3 conversion, and after a minute I immediately lost my mapping erection. 

Also, an implant can help with the other problem. 

... certainly not related to hardware. I'm up to date with all that :) But here are my reasons why I prefer 1.1a to 1.6

1. Zooming. In 1.1a the zoom value is about .06 for each zoom in, whereas in 1.6 the zoom value is .50 and this frustrates me, because either its too close, or its to far away. At least in 1.1a, there are much more zooming values and I can map comfortably.

2. Slowness. 1.6's 3d view runs much slower compared to 1.1a. Even if it's the same exact map, 1.6 renders it much more slowly than 1.1a, thus making texture alignments a real pain in the ass, and I'm forced to use visgroups, which you don't need in 1.1a because it never slows down. And another weird thing. The wireframe 3d mode in 1.6 renders MUCH slower than textured or solid mode. But in 1.1a, Wireframe mode renders much faster than textured or solid. Whats up with that?

3. Selection handles. I hate these things. They not only distract me from the actual brushes themselves, but they sometimes get in the way of other items, normally entities. Thank god 1.1a doesn't have them.

I may have a few smaller gripes about 1.6, but these are the real main issues. However, I do have positive things to say about 1.6

1. No file size limit. 1.1a has a .map file size limit of about 1800kb. 1.6, as far has I know, has no limit.

2. Better shearing manipulation than 1.1a.

Thats about it really. All those extra features in 1.6 I do not use. Anything 1.6 can do, 1.1a can do as well, to a degree. And there you have it. 

I had no luck fixing the leak myself, so i sent it off to AguirRe. He said that he really couldn't do much, as it seem that my curves were not exactly snapped to the vertices, so it was causing the compiler all sorts of headaches. So i thought that perhaps if i scaled up the size of the pipe, that would make it large enough to have all of the vertices lie on the grid. I rebuilt, and tested, and was met with failure. Several times, to the point of my girlfriend imploring me to stop working on it.

(I didn't)

Well, since this wasn't working, i rebuilt the pipe example in CZG's tutorial, which obviously compiled without incident. I compared this to my failed ventures, to see what was different. I'm pretty sure i've isolated the issue.

In order for curved pipes to compile properly, it would appear that:

The diameter of the outer region of the pipe must be equal to the radius on the inner section of the pipe.

On the pipes i was trying to make, the above ration was not used, leading to a leak every single time.

I'm guessing that if the ratio stays the same, it betters the scalibility of the pipe, so when it's stretched in strange and unusual fashion, it causes for vertices to be formed off-grid. Or something.

Does this sound cogent? 

You have to think in base 2 (8 for doing the stretching). Basicly everything in games works on power of two and is sqaure. The textures in Quake that are rectangular slow down the engine because it basicly converts them to square before drawing.

The wedge used for the pipe bending is 2x4 to the grid, which means all subsequent structures are based off that ratio, if it's different or off-grid then it won't work, like you say, lots of holes and warped shapes.

Hopefully that makes sense, but usually you just have to sit there in editor and mess with it until it clicks. 

The textures in Quake that are rectangular slow down the engine because it basicly converts them to square before drawing.

Okay, this isn't really true. Video cards (except some of the newest ones) can only handle texture dimensions that are powers of two, but they don't have to be square -- a 64x128 texture is just fine, for example.

Second, non-power-of-two textures don't slow the engine down except perhaps for a few nanoseconds at load time when the engine resamples them to a power-of-two so that the video card will accept it. But there is no performance hit during play. 

Although I did mean power of 2 textures that are rectangular.

The problem with non power of 2 on modern cards is that a default colour is generally inserted to fill in the space and make them power of 2. Which can cause some strange visual effects, like a load of black lines marching down a wall or pixellated artefacts on eg. a fontsheet.