Now that I've gotten the lightJunior stuff figured, my walls seem to be lit oddly:

http://biff.leveldesign.org/pics/map_shots/rtcw/light_test1.jpg

Yes, those are patch curves on either end, and yes, everything is caulked -- both behind the curves and on the unexposed faces of the wall brushes.

But wait, there's more! Soon after that cropped up, I ended up getting leaks through solid brushes:

http://biff.leveldesign.org/pics/map_shots/rtcw/solid_brush_leak.jpg

Have no idea, what's going on -- mebbe my comp will be a pool of goo before morning... 

I was exactely looking for this ! Thanks a lot: you rock ! ;) 

but I never had any such problems when making my wolfenstein map. What compiler are you using? I was using the one that shipped with gtkradiant 1.1 or so, and then switched to q3map2 for the final compile. The compile tool versions are listed in the text file for the map.

The source is included with the map if you are interested in having a look anyway http://than.leveldesign.org/files/mp_checkpoint.zip

Not really any similar instances though, as I'm pretty sure I only used curves for pipes. 

Another n00b problem. I made a bridge that's supposed to come out of its "locker" once you push a button. However, the bridge is all dark once it gets out. The same with door frames (the inner parts).

Before:
http://i7.photobucket.com/albums/y259/msandt/dark.jpg

After:
http://i7.photobucket.com/albums/y259/msandt/dark2.jpg 

Move the bridge into its open position, reverse the move angle, and check the "Start Open" spawnflag.

Dark insides on doors can't be fixed in the same way because then the door fronts get dark, and that's even worse. Can't think of a way to fix that unless you've got a compiler that has entity minlight. (I don't know of any compiler that has that.) 

Dark insides on doors can't be fixed in the same way because then the door fronts get dark, and that's even worse.

They CAN be, if you're willing to fully light the recess in which the doors reside when they are open. 

I'm using Worldcraft 3.33 for Quake 1. I want to make a button trigger multiple doors which open at different heights. How do I do this? 

Hmm, I have fixed it by making two buttons that overlap 

two buttons is not necessary.

You can give the button a "target" and both doors the same "targetname" and it will work. 

OH I see, that's obvious. Thanks

Can I put a button on a door? I wanted to have a block rise out of the ground after pressing a button and there be another button on the block. 

I wanted to have a block rise out of the ground after pressing a button and there be another button on the block.

Unfortunately this is not possible (at least with standard quake entities.) You can probably fake it, though, as follows: (Note that this entire thing will only work once; once you push the button and it dissapears, it can't come back for another push.)

First, make a func_door that looks like a block and also includes a "pushed-in-button" as part of the block geometry. Second, make another func_door that looks like an unpushed button. These two doors will rises up exactly at the same time and travel the same distance (this requires careful use of the "lip" field on both doors.) Third, create a trigger_multiple which covers the space where the button will be after it rises. This trigger will point to a "logic gate" which will then trigger two things -- 1. it will target whatever you want, and 2. it will "killtarget" the func_door that looks like a button, making it disappear. When it disappears, it will reveal the "pushed-in-button" that is actually part of the block, making it appear that the button actually moved.

Finally, becuase you want to killtarget the fake button but not the block, they need seperate targetnames. Becuase of this, you will also need a trigger_relay so that one event can make both func_doors rise at the same time.

The logic gate will ensure that when the block hasn't risen, the trigger_multiple does nothing and players won't realise it's there. (A logic gate, in case you didn't know, is a spike shooter pointed at a shootable button, with a door in between. It will only pass on the signal if the door is open.)

So here's a list of entities you need:


1. Input: this is whatever makes the block rise.
"target" "block"

2. Block: this is the func_door block with the pressed-in-button added.
"targetname" "block"

3. Relay: this is the trigger_relay.
"targetname" "block"
"target" "fakebutton"

4. Fake button: this is the func_door which looks like a button.
"targetname" "fakebutton"

5. Trigger: this is the trigger_multiple that users will touch when they are attempting to push the fake button.
"target" "logic"

6. Logic gate shooter: this is a spike shooter that attempts to shoot the logic gate button.
"targetname" "logic"

7. Logic gate door: This is a func_door that is closed whenever the block hasn't risen, and open whenever the block HAS risen.
"targetname" "block"

8. Logic gate button: This is the func_button that the shooter is aiming at. (Hmm, does anyone know if the same entity can both target one thing and kill another? If not, we need another relay to kill the fakebutton.)
"health" "1"
"killtarget" "fakebutton"
"target" "whatever"

9. Output: This is whatever the risen button is intended to trigger.
"targetname" "whatever" 

... AFAIK target OR kill, not target AND kill. So, the extra relay is required. 

But I ended up rebuilding the test map, and all seems fine now. Have no idea what was causing that sort of thing -- but if I have any more probs, I'll look into that link. 

Thanks for the help. I wish I understood. 

if it seems too complicated, you should probably go with something simpler for now. For example, have some bars block the button or something. 

like here:
http://shub-hub.com/files/images/Screenshot-2.png

It might be QuArK floating point gayness but I know I found such edges on many maps. 

neg!ke just answered me:
qbsp bug, move the vertices or clip.
:) 

it's clip hull expansion logic. angled faces are expanded at an angle, and straight faces straight, so brushes that line up visually will end in different places after being expanded differing amounts on differing axes. 

visually inspect the player clipping hull by using the -hull 1 qbsp option. The map will probably look a bit different ... 

I just made the /^\ part 1 unit smaller on each side. Looks the same and got rid of the problem. Now that I think about it I simply could have made the one part a func_wall I guess. 

I thought (almost) all brush expansion problems were fixed in the most recent aguirre/tyrann tools... 

That fucked THF in some area, and I had to clip these corners... and it seems expansion problem are not completely solved... 

I used the clipping tool after doing some vertex editing and now I'm getting all kinds of errors with QBSP.exe whenever I try to compile.

So - what's wrong and is there any safer way to build a structure like this?:
http://i7.photobucket.com/albums/y259/msandt/vittua.jpg 

Clipping can cause alot of problems under the right circumstances - minor foibles of the various software that can mangle a map.

An important one in WC1.6a is that clipping across more than one brush in a window where those brushes are not adjacent causes it to crash - but not if you clip from a window where they're touching / stacked.

From the screenshot I'd say you need to rebuild the corner, but sticking to the grid; when you make the angle lock it to the grid as well - at 45 degrees. So all the brushes will have compass rose angles.

It an enclosed brush (not a wall against the void, ie. no leaks) so what errors is bsp giving - is it removing faces on any of the brushes?

Anyhow; the basic answer is rebuild it, hanging onto the grid for dear life - when cutting, scaling or whichever manipulation you make. 

A clarification - you don't need compass rose angles, just to snap to the grid size of your choosing. 32x2 or 16x2 in that case I reckon.