i was never a fan of the q1rad compilers. maybe i was just using it wrong, but i found that, while it would get rid of ugly harsh shadows, it tended to wash stuff out too much, giving more of a rough ambient occlusion look. getting nice contrasting shadows was usually more work than it was to make fake radiosity with the regular light compilers. also, it took longer, which was another big reason. :P 

when using q1rad which allowed me to control the lighting a bit more.

My recollection is q1rad can't support switchable lights though, which is a big negative for many single player maps. 

My recollection is q1rad can't support switchable lights though, which is a big negative for many single player maps.

That is correct... it also crashes out on large maps before it finishes. 

Yeah, I remember back in the quake2 days thinking that -bounce was another one of those command line switches where a bigger number meant your map would be better. All of my quake2 maps were very bright and yellow. 

I'd be interested by the use of rotating stuff in Quake: So, is there any tutorial, or any map example that explains the use of <*>_rotate stuff (Quoth)?

Thanks in advance 

Yes, CZG's tutorial is in the Quoth manual:
http://kell.leveldesign.org/quoth/quoth_tutorial.html#rotatings
http://czg.leveldesign.org/q/czg_rotate.txt 

Thanks, I already know that one...

Nevertheless I'm really interested about a map example... It will be more helpfull I think.. ;) 

The two posts at the start and end of this link give a method to make a func_rotate in a way I reckon is easier.

http://www.celephais.net/board/view_thread.php?id=4&start=6148&end=6153

No example map, but I think it's easy enough to experiment with. 

look in the "GPL map sources" thread, maybe one of the GPL'd maps has rotating stuff in it. 

Thanks for the infos ;) 

http://shub-hub.com/files/tools/hipprogs_doc.zip 

Anyone know anything about lightJuniors? I've got them in a RTCW map to keep the baddies from being blacked out, but they don't seem to be working? Anything I have to do other than simply have them in there? 

After scouring related forums and sites (and not finding a damned thing), and even hitting up the folks at #splashdamage, it took me a good soak in the tub to come up with the idea that my single-room map (and lightgrid) was too small to make the lightJuniors effective.

And I was right. 

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"