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. :) 

Hi.

Could somebody point me to a good tutorial that would describe curved surfaces for me? Not the ones in Q3, I mean using angled brushes to round off a corner so it wouldn't be so, 90 degrees.

I just need a little help with the geometry of it all.

Thanks. 

czg wrote this http://www.quaddicted.com/stuff/curv_tut.htm

There was a more recent one by someone else (ijed?) but I don't know where to find it. 

http://web.archive.org/web/20050308151558/http://czg.spawnpoint.org/curv_tut/curv_tut.htm

There is a curve tutorial by CZG, where he shows you how to make pipes and stuff on the grid... in the archive version, the images are missing though. :-/

I guess I could whip something up as well for radiant, maybe I'll do it today, it's easy...

It's hard to explain without pictures. Let's start with an inward corner, like in doorways. Imagine a 90 degree corner of a doorway. To round it off, you basically put more angles in there, for example you can create a 45 degree corner by putting a little triangle shaped brush in there.

This is all that id usually did in the original Quake maps; you'll find lots of doorways that have little wedges in them.

To round it off more than 45 degrees, you'll have to put more brushes in. The next step is putting two little wedges in, and make it so they don't overlap (pull the edges around in Radiant until both little triangles look the same size, and always stay on grid). That will create two additional surfaces in the corner and make it *very* roughly rounded.

For each additional surface in the curve, you'll have to put in an additional little brush. This is the part that is easier to explain with pictures. It will usually look OK if you have three additional surfaces in a corner/curve (this translates to three little brushes), where the middle one is at a 45 degree angle and the outer ones are at a lesser angle.

A 45 degree angle is created in the editor by going one step down, one step sideways on the grid. OK?

Lesser / sharper angles are created by going two steps down, one step sideways. Or four steps down, one step sideways. It's done like this to ensure everything stays on the grid.

http://www.quaketastic.com/upload/files/screen_shots/24sided.jpg

Observe very closely how the angles are done in this 24-sided circle. You don't need so many sides in the beginning - doing the "three angles/brushes per corner" method will yield a 16 sided circle if you do it "all the way around", since 4 X 4 surfaces = 16. It's 16 and not 12 because you have to add the sides that aren't angled. ;-) hard to get without pictures, I know.

This 16-sided method is good enough usually, but sometimes you may want 24 sided to make something look even more smooth. More surfaces in a curve = it looks rounder, smoother.

Now for out facing corners, like the corner of a corridor, it is much the same method, only the curve goes in the other direction... the angles/brushes are on the inside of the curve in this case. The methodology is much the same.

Maybe someone has the pics from the CZG tutorial, but I guess I should put that in my radiant tutorial as well.

You can of course simply use (ex.) Radiant's functions to create cylinders. I'd strongly suggest to stay at a reasonable amount of sides, like a 16 sided cylinder, and be very sure that every corner is on the grid, snapping the thing to the grid (Ctrl-G in radiant) to make damn sure. You can then use the clipper to chop the cylinder into half-and quarter cylinders. This method works best if you set the grid to like 32, and make the cylinder from a relatively large brush like 256x256. For tighter curves, you'll need a smaller grid, or less sides in the curve.

If you look at handrails in games like Quake 4, the corners are often only using two sides. It looks crappy, but for small things in a large/detailed environment, you can get away with it. Also, curves eat performance.

A map full of curves will run slower and slower and take longer and longer to vis. The higher the number of sides in your circles, the slower it will be. Don't go overboard. 

nice, Spirit has the version with pictures. :-)