I know Sin behaves bad and all. It's a real sin that shipment made turn out the game that bad to handle. But I must admit maps like "mansion" are done very impressive.

I had the pakfile converted to extracted files, but I couldn't find anything to use the *.sam files. There are Q3 compilers to make new sinpak files. But it feels as if the structure is hardly to work with.

As if I have to install all garbadge to extract Q3 files. 

The sin files aren't always the same as id ones, I know that at least the pak files are different and can't be extracted/created with normal tools... maybe ask here:

http://www.ritualistic.com/forums/forumdisplay.php?s=da26c1f506ef14877848c952341bef7a&f=10 

http://negke.quaddicted.com/images/blacklight.jpg
It can get even weirder...

In other news, fuck those random black triangles! Another totally unnecessary obstacle. 

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.