how exactly are you cancelling out the spot light... as in, what values are needed? do you guess it and tweak or can you just figuring it out based on the current values?

I should have mentioned - make sure the spotlight uses a different style to the surrounding lights, then you make the antilight use the spotlight style and it will only cancel light of that style (i.e. the spotlight) - this is a mega useful property of antilights.

with it only affecting the spotlight it makes it a lot easier to to just make an educated guess for the antlight values, eyeball it, adjust, eyeball it, adjust...I don't have a formula for this but I've found it doesn't take too many iterations until it's "good enough". 

I stuck the antilight off to the side of the window, so it flooded the wall with antilight of only the spotlight style, but the angle was such that no antilight came through the window. 

ohhh interesting. didn't know you could use style like that for antilights. that makes it much more useful.

btw, like the fake hdr idea. that's a great way to make interesting light without relying on sunlight to do the job for you. 

you can often use antilights to mackle up some passable blob shadows to make a func integrate better into the world geo. 

btw, like the fake hdr idea. that's a great way to make interesting light without relying on sunlight to do the job for you.

Indeed - I alway go for a rather dim "twilight" sun effect these days - Quake was never supposed to take place during the day :} 

Did you check with BJP's light readme for possible addtions/corrections? 

are there any? admittedly, most of that is from memory, but i did quickly check it over for any blatant errors.

actually, now you mention it, i should probably link to that as there is a lot of info in it. i just find it's not very easy to find it, being buried at the bottom of a massive changelog (some info is actually in the changelogs too...) and being mixed in with both light and vis tools.
and some info came during the development of the tools when we talked over email.
bengt is a tool genius, but his documentation is not very accessible. :) 

I use filler lights too. Pretty much every light in any of my recent levels has a bright source light with short falloff and a lower intensity (50-175, sometimes 200) light with a long falloff, which tends to look more realistic than just one light with 300 intensity placed at the source.

However, I should probably try experimenting with the different falloff types, since it's probably possible to create the same thing using a single light with an inverse falloff or what have you.

I also used inverse lights for integrating funcs, but that's about all. They are useful in some situations for sure, but I don't find myself using them that often.

minlight is useful for doing very rough level work without having to make everything fullbright. It's good for quickly testing the angle of sunlight without having the sun cast thick shadows (you want to see the underlying architecture) and a very very low minlight can look ok I think. However, in most cases it's best to not use it since I don't think you can get the level any darker than that value - even using negative lights. 

aguirre's tools do allow negative lights to go below minlight, so you can darken a pit or something. 

I didn't realise that. I think the last time I looked in the readme it didn't allow them to go below minlight. 

Although I don't desperately need to save precache slots
, I was wondering about the teleport using entity only flag. In worldcraft there is no entity only flag for trigger_teleporter and I'd like to know if it's actually a hack or, if there is a flag, which number it is.

Anyone know? Negke? 

You need to create a point entity, e.g. trigger_relay, set all the necessary fields (targetnames, spawnflags + 2) and change the classname to trigger_teleport. 

thanks! 

Ok, this works, but in Worldcraft you need to set the classname in smartedit mode by adding it as a new key, rather than just change the classname from the drop down list.

Awesome tip btw!

We really should write a new guide to Quake mapping that includes all the hacks and tips and tricks to let people get the most out of the game. It would be awesome to have a nice clean guide instead of having to wade through this thread or the hacks thread to find stuff. 

I made a little Shambler teleporting test map. There is a weird little problem...

When the Shambler is teleported, you can see him move very quickly between teleporter and destination. I've never noticed this before. Is this a problem with this hack or a general teleporter quirk?

https://docs.google.com/open?id=0B2HO-DwxAPCnYUpSOHdSSHBPMFU 

I can't explain why this happens exactly, but it seems to go away if you move the teleport_destination entities 8 units up. 

Actually, I noticed it wasn't happening at one point, but I didn't know why. I guess it was when I moved the teleporter_destination up to access the teleporters and didn't move them back. 

maybe because FL_ONGROUND will be set when it's setorigin'd to the new position and then lerped?
that's really weird that just moving it off the ground fixes that. 

Seen this happening with blinking scrags.

It seems to be caused by modern engines showing the space between the smoke and the mirror, which the old engines weren't precise enough to reveal.

But, it sometimes happens, sometimes doesn't, and I'm not sure why. The position is just moving over the duration of 0.1 seconds, seems that sometimes this is visible. 

Can you check if it's an interpolation issue by replicating and then toggling r_interpolation (or whatever it was called in engine of choice). What might be needed is for interpolation to be reset for any entity which has Setorigin called on it. 

this seems to be the culprit. Turning it off fixes the issue. 

If it was a constant problem :(

I've noticed it affected by framerate fluctuations, although sometimes not.

So I'm going to try the hit it with a hammer approach of nulling the mesh of the monster for the duration of a teleport.

Shouldn't cause anything untoward, although come to think of it, it could break !walkmove checks, especially for custom bbox monsters. 

which engines is this happening in? i thought fitzquake and variants had this fixed. 

are you teleporting the shambler less than 100 units? There is client-side code in quake (and extended in fitzquake) that detects moves greater than 100 units in a single frame and treats them as teleports. In regular quake this affects the demo playback lerping, in fitzquake it also affects the r_lerpmove lerping. 

Your post than.

In RMQ we see it in RMQEngine, which is a fitz fork, so the less than 100 units thing should be what's affecting the self-teleporting enemies by the sound of it.