Unless you only need a very simplistic platform, it's better (but a bit more complicated) to use a door. 

Yeah, plats kind of suck. Doors are MUCH more controllable. 

@ShoTro: func_plat is an odd entity, it's sole use is to make platforms that lift you upwards when you stand on them... you can't make them lift downwards.

You can make it a 'locked' platform, where it starts at the top of it's movement disabled, and then lowers down into the lifting position when triggered. You do this by giving it a targetname and target that from a func_button or trigger_multiple or something like that. You can only do this triggering once, after the platform is 'unlocked' by targeting it, it will stay at the bottom and only act as an upwards lift.

If what you want is to make a downwards elevator, what you want to do is to make a func_door that opens downwards, and then have it be triggered by a func_button or a trigger_multiple. That will make a brush that moves down when you trigger it, and then return to the top after it's "wait" value. If you want it to toggle between top and bottom positions, set the 'toggle' spawnflag, and put something like a func_button at the top and bottom of the elevator. 

@unbirthday: yeah, don't recommend using deviance lights willy-nilly. Like you found, they turn the 1 light into multiple lights. Best used for special cases rather than as part of a lava surface light. 

Doorlevators are great because you can enter them. Just build a full blown elevator made of brushes and turn the whole group into a func_door. A func_plat is triggered when you're on top of it only. 

Cool, that was the conclusion I was coming to. I thought I was just not getting something... nothing else hasn't worked without a small amount of tinkering. 

Glad you sorted the max lights problem. Having the limit is just laziness on my part, and it could be removed.

I'm disabling the _deviance feature for surface lights in the next build because it's overkill to use two different light-duplicator methods together. 

Necros, did you dirtmap? 

Heck yeah, I love me some dirtmapping! 

65,536 lights is a lot of lights!

If you set your grid to 256 and placed a light at every intersection (including up and down) in the entire player accessible area of a Quake map you would only use half that amount. 

yeah, what happens is the surface lights are already spawning arrays of lights, then each of those lights gets another array of lights. I ran into the same thing, but when you think about it, deviance on surface lights is only necessary if it is a single light (eg: a small wall texture), but not in the case of lava.

i wonder if you could track how many lights have been spawned as part of the surface lighting and if it is over a threshold, do not apply deviance lighting. just some internal tracking, nothing added to the actual map or anything.

because you would want to use deviance lights for small 32x32 lights, for example. 

sorry. should have posted that in the tyrlight thread... please ignore this. :) 

What I've been trying to do, is control the height that the surface light casts out to. It gives such a glorious colour, and interacts in such a natural manner - whereby blue metal turns violet when at an angle (like it would) and turns red at the bottom, as if its heating up, like it also would. I also get this gorgeous red light bouncing on my columns - but the effect is too strong, and there's just too much red. So I've fiddled with wait/delay/intensity/colour/deviance etc, and the light either goes too high and saturates everything in red, or ends up in discrete lights that are obviously lights, and *gasp* often both of these things at the same time. 

http://shoresofnis.com/post.php?postID=2

Except, you know, with tyrutils and not mhlight..... 

You know, I've never really understood the delay thing. You would think that no matter what the delay is light at the source should remain the same, only the distance it drops to a give value would change. But that is not the case.

64 units from the source, with the same exact value for light, delay 2 is far, far brighter than delay 0 (no delay). Delay 5 on the other hand, with the same light value, is noticeably dimmer at 64 units than the default, yet appears be be attenuated even less than delay 2. 

another way to tweak lights without touching their settings is with the colour! just make the colour darker while not affecting the hue. 

Yeah I've tried changing colour to incredibly low values in small steps right down to 0.001 - I have a lavaexperiments.map project just for tweaking this xD It's actually almost the same as changing light, as the intensity is actually the brightness. It's hard to correlate because changing attenuation means you need to change the number entirely - as Rick has begun to notice :). Only difference is, as it states in onetruepurple's link, that light also controls the radius. Unfortuntely you can't give _surface_offset a negative number - as that would pull the light down and might solve the issue (it will still cast through the lava, as it is treated like water). I'm not sure how others aren't having this problem.

If you use delay 0, then you end up with an effect that looks like it's painted red, as natural light is not attenuated linearly. Also, you end up with a sort of wave pattern which truly makes it look spray painted on (i.e. bad) xD Delay 1 is just useless, in that it casts very very far and doesn't attenuate fast enough. Delay 2 and 5 are of course the natural inverse square light, which looks the best - but as I say, set too high and they cast such intense red light that it's overbearing, especially with a red sky too - and set too low, you get discrete blobs of light that looks even worse. If one changes the colour to a darker red to offset this problem, then one ends up with something that is then too subtle near the lava (i.e. not very red), and fades perfectly. The opposite :/

I think a delay 6 might be best, which attenuates AND is additive, so that you can get an intense red right at the bottom, which quickly fades out to a lesser red, which itself then has a long smooth fade out. Or just a light that you can control its z attenuation independently to its x and y. Or just allow a negative _surface_offset.

Anyway, I've got a set-up now that I'm quite happy with (using delay 5), but it still means I'll need to put discrete red lights in some areas, to fill in the blanks.

Anyway anyway, I'll shutup about surface lights now and let the jamming continue. I also want to end this large post by saying that tyrutils-ericw is the best lighting I've ever seen in Quake 1, and is just phenomenal, even on standard settings with just _sunlight2, where it compiles stupidly fast. So thanks to tyrann, ericw and ydnar (not present; for q3map2) and others who worked on it.

PS. I was secretly trying out a combination of long fadeout red light and fast fadeout intense yellow light - as you can apply more than one light to a surface. I must say that this combination looks very good, but sadly you end up with discrete yellow blobs of light in many places. It can be seen working on the right hand column in my earlier screenshot: http://imgur.com/FMJtZcb (screenshot is out of date btw) 

Useful info for us who have not looked into it as much. 

delay 6 does not exist in tyrutils ;). if you use an invalid delay you get delay 0 (linear).

I would advise against lowering the brightness by scaling down the colours right now. I should fix this, but if you do it right now, the .bsp lightmap and the .lit file will have different brightness levels, and some engines don't allow that (MarkV) and will give you artifacts in the lightmap.

Instead, I believe halving both "light" and "wait" will give you the same effect.

Make sure to play around with "r_lightmap 1" in Fitz/QS - of course, you have to judge the final look with the texture in place, but this can be really helpful to see what's going on when you make subtle lighting changes.

I can allow "_surface_offset" to be negative in the next build, neat idea.

glad you're enjoying the tool unbirthday :D 

Try putting these in your autoexec.cfg

bind "key" "toggle r_lightmap"
bind "key" "toggle r_fullbright"
bind "key" "toggle showbboxes"
bind "key" "toggle r_drawviewmodel"
bind "key" "noclip"
bind "key" "notarget"

There are probably more that would be useful. I just realized I don't have a bind for drawflat or showtris. 

eh, hit submit instead of preview - should be r_showbboxes 

@ericw the paragraph referring to delay 6, was suggestions for an improved tyrutils-ericw xD And yep, I've been using r_lightmap 1. --- I think controlling z attenuation independently of x,y would be awesome, as it could be used for other interesting lighting and not just for surfaces. 

I have basically a big cave and surface light from the lava is just about unusable with delay 5. Using light 100, delay 5, wait 8, and -gate 15 switch, It looks like I still get too much light on the ceiling (over 1024 units above).

I need to check with no lights except the lava though, because I have some other lights using delay 5, and delay 5 goes on forever.

I think I'll try delay 2 because it'll be brighter down low, close to the lava, but it looks like it gets attenuated faster than delay 5. I don't want the lava to be a light source, just want a little glow from it.

The default setting (no delay) isn't terrible but the abrupt light cutoff looks pretty bad. 

If you're using low settings and the light near the lava is low but the ceiling is too bright are you using -addmin ?

Try turning it off and seeing if it's any better. 

No, wasn't using it. The more I think about, I need to just take out all other lights and then adjust the surface light from the lava. There are other lights using delay 5 and I'm thinking they're part of the problem.