Apparently it's the ceiling this time, the ledge in the shot. Works fine in other areas, though. 

Maybe that face is in the bounding box of the light? 

or a derivative.
i believe it was established that this is a bug with the engine? something to do with metl's new light code or something.

i believe it is taking light values from outside faces (when the map isn't sealed, at least). if it's not sealed, try sealing it to see if it goes away, otherwise, you can try reshaping the brushwork in the area. :S 

Luckily, I could fix it by simply moving the torches a few units up. Strange issue. The map was sealed by the way. 

metl did mention it might be an enigne bug but i got that problem in glquakebjp too 

In my case, it was.

I also had another black torch elsewhere that seemed properly placed and all. Turned out a rogue space beneath the floor and wall brushes was responsible there. Possibly related. 

looks like it's more than i thought. :S
come to think of it, if it happened in glquakebjp, than it's probably in glquake as well. 

... when monsters walk through a floor that is made of func_breakable (i.e Quoth)...
Maybe it could be solved by adding a light just on top of the func_breakable... I Ididn't tested it yet... wait and see ;) 

that's a different problem from the one above.
light info is only taken from world geometry btw, so that won't help, unfortunately.

you could put a light on the world geometry beneath the breakable though. if it's a sky texture, bury a non-sky textured brush inside the sky texture to transfer light info. (sky texture does not transfer light info) 

if you need to make a pitch black pit with a func_door bridge or something over it (ie: you can't put lights at the bottom of the pit) you can place a 16 unit high func_illusionary (or even a func_wall) at the bottom of the pit.
then make a spotlight below the top of the func_illusionary brush at the bottom of the pit with the following settings:

'light' '150'
'wait' '0.1'
'delay' '5'
'mangle' '0 -90 0'
'angle' '180'
'_softangle' '0.01'

this creates a spotlight that will point downwards and light up all the area that's hidden by the func_illusionary thereby transferring light info to entities over the pit without breaking the illusion. 

not _softangle, but rather _anglesense

my bad. :P 

that was post ten thousand!

nice way to mark it :P 

i only noticed after. :P 

Scratch that. So Fitzquake is the new DP now?! 

Thanks for the tip: I'll try it ;) 

I have an ambush situation where a Shambler teleports to the location of another monster (which acts as the destination for the teleporter). The problem is the Shambler doesn't face the direction as the monster but arrives at angle 0. Can I override this with a hack? Preach?


Nice idea for a level gimmick or secret: a monster roaming through the map that the player can teleport to. It could be a Scrag, and the player would have to get it to become angry at another monster in an unreachable place to be able to get there himself. 

i don't know if that's possible. the teleport code uses mangle to set the player angles.

the very first line for info_teleport_destination is

self.mangle = self.angles;
quake automatically converts the 'angle' key to 'angles' by just placing the value in the y part of the vector. in fact, 'angle' isn't even declared in the progs. this is only done at runtime, i believe.

i had to add a special case into my own progs for monsters teleporting to other monsters to get it to work.

just make sure the monsters spawn in angry is the best you can do. :S 

Anyone: frikdos.exe isn't compatible with 64-bit. Any suggestions? 

Build a new one from source for your platform. http://www.inside3d.com/frikbot/frikqcc/frikqcc27src.zip

Just delete the "plock=blah;" line in qcc.c (how'd that get in there?) 

i've always wondered, do people who suggest it seriously believe that Build a new one from source is a viable alternative? i've seen that 'solution' thrown around a few times now and it seems absurd to me.

that said, i don't know exactly what's going on, but i use frikqcc.exe without any problems in w7 64bit. 

fteq even a smaller progs.dat bitcount and some errors just overide.
I don't know if that's on 64-bit.

http://www.fteqw.com/ 

There's a simple way to work around this issue without sacrificing the decorative value of torches and flames. Just replace some of them with dummy models and add a few extra point lights. The func_illusionary hack comes in handy here, because it doesn't require messing around with the modelindex, creates a static entity, and preserves the animation.

"classname" "func_illusionary"
"origin" "x y z"
"model" "progs/flame.mdl" // or flame2.mdl

If there's no other real light_flame around, place an additional sound hack entity for the fire ambience. 

I use Gentoo, so "build it from source" is in principle a convincing solution to me. If the guy gives me a makefile, I'm unlikely to complain.

Even Ubuntu comes with GCC. You could say that Linux is a car that comes with a full set of tools to repair it, and the owner is supposed to know how to use them. That's why Linux is cheap.

Windows on the other hand... I guess on Windows, users aren't supposed to know what a compiler is, so telling them to build something from source is outside the rules for that platform, basically. Windows is a car where the user is told to call the customer service when it breaks (and then wait outside in the snow for it to arrive).

Same for Mac. Mac will just drop a new car at your doorstep and charge you money for it, and users will simply pay for that, because they're pretty rich. The old Mac car gets discarded, even if just the radio was broken. Mac users don't compile stuff. Slaves back at the factory do it for them. 

OR WE WILL BEAT DEM! 

i suspected it was something like that. i don't even know what a makefile is. :P

just something to keep in mind for you code monkeys out there. :)