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. 

by calling setmodel or setsize you might be able to force it to disable lerps for that frame (not tested.) 

it doesn't occur in my actual map... only the testmap. The test map used >100 distances though, but not by that much. 

anyone know if it's possible to rotate torches etc. so that they appear upside down? I vaguely remember someone made a speedmap with lots of upside down stuff inspired by alice. Whether this included torches I dunno. I suspect negke knows how to do this if it's possible :) 

 

I was about to answer my own question there. Just figured it out, but thanks :)