I also suspect some race problem, but it's surprisingly consistent. Also, most engines behave the same way, but DP always fail to suspend the item no matter how the map is loaded.

I'll try adding the delay. 

.. 

Cheers aguiRe, very useful!

I'd gotten so used to some of the item_*s being positioned off center in game, makes a change having them sit where they should be.

The light attenuations in a drop-down menu and mouseover hints for _sunlight values in worldspawn definitely beats keeping an open text file of the light.exe -h output around.

What else is left to update or add to the definitions? 

it'd be things that I've missed or that I've decided not to add for various reasons. I've tried to strike a balance between completeness and clutter. I've also avoided keys that only exist in one tool or engine. 

If a player is on a walkway high above lava, and immediately in front of him is a laser trap (or a Drole firing whatever it is he fires), what are the critical dimensions to allow him to side-step the laser (or other nasty projectile) and not fall off the walkway.

So:-

what is the player's width and at what point will he topple?

is the weapon's collision detection based on the size of the laser model (or nail or rocket etc), or is it more to do with the bounding box of the player?

I am trying to work out the optimum width of the walkway to allow a side-step but with the proviso that it must be done carefully to avoid going over the edge. And it's not actually lava underneath so death will not be inevitable if the player goes too far and does fall off.

In experiments, I can go to the edge of a ledge and move sideways to the point where I expect to fall off but don't. Looking down, I am in mid-air. I don't want the player to have too much room but I want it to be only just achievable. That way death or injury is quite possible but not guaranteed.

Sounds awful, I know, but I am trying not to give too much away. 

the Q1 player bbox ( also the bbox for all small monsters e.g. scrag, knight...i.e. the second collision hull size ) is afaik 32x32x56. Could be a couple of units taller, not sure.
Because it's a box that slides around the map always oriented the same way, the player will not fall until the very edge of the bbox has passed beyond the edge of a surface beneath. So you can be standing with 31 units sticking out over thin air and you won't fall because 1 unit remains in contact with the walkway.
Just as a useful guide, textures that are 32x32 ( e.g. the E3 glowing rune plates, each of the chequer flagstones in the knave wad ) are the equivalent of the bottom of the bbox - what I refer to as 1 player footprint.
Projectiles, except in some very unusual cases perhaps, are points not volumes. Collision is calculated for a point hitting a volume. So as long as the projectile whooshes past even 1 unit away from the bbox it will miss, even if the polys of the projectile model in question ( rocket, drolebomb, vorepod ) pass through the bbox.

So, technically, you could build a very narrow beam - say 8 units wide, and that is fucking narrow - and as long as the incoming projectile was fired almost exactly parallel down the center line of the beam, the player could sidestep to hang over thin air by maybe 30 units without falling off and leaving a couple of units between their bbox and the projectile.
In practice, this would be essentially impossible to achieve. The determining factor here is not really the physical dimensions, but the movement. Try it and see - manuevering to an accuracy of anything under about 32 units is rather demanding in combat. 

Thanks for that. Now I understand - my 64 units is plenty generous enough then.

And I whistle while I work.... 

you can bunny zig-zag and use air control to stay over the void most of the time. ;) Ok, best not to design maps for that, but still, works vs vore balls on a beam. 

How was this Q logo shadow done?
- http://www.phait-accompli.com/q/shadow_1.jpg
- http://www.phait-accompli.com/q/shadow_2.jpg 

made entirely out of SKY* textured brushes. Inside, some solids and a few powerful lights.

At least, that's one way I know of doing it. 

Actually it's not a room, just a single thick skybrush with the Q inside. I did the same in kdma, with a pentagram. Newer light compilers may deal with skybrush permeability differently though. 

That wouldn't work with my idea. See the light texes here?
http://www.phait-accompli.com/q/op/2.jpg

I was gonna have light emit from inside them, essentially, so that even the little bits that make up the frame cast a shadow. At least that same idea with something more... I dunno. That's just an idea. 

the logo is placed above the sky texture, which is in this case a func_illusion.
http://members.home.nl/gimli/shadow00.jpg
the screenshot shows a picture with the func_illusion invissible because the viewer is in it.
http://members.home.nl/gimli/shadow01.jpg
standing on ground, it would look like:
http://members.home.nl/gimli/shadow02.jpg

has anyone yet a solution for my rats which got lost in a brush??? 

What kell said. See that floating brush in your second screenshot? Noclip inside there and see what you find. 

And saw nothing. :| 

Can someone help MadFox as I do not quite understand his problem and would therefore benefit from knowing the answer - you know, reverse logic.

Besides which, I was thinking of using rats in my next level. 

It depends what engine you use. In a software engine the Q brushes are visible. In FitzQuake they're not. I assume this is related to the more efficient unseen face culling thing. But take our word for it, the brushes are there at least for the compiling of the map and therefore shadowcasting. 

I'm afraid I don't quite understand the rat problem either. Sounds like it might be to do with the position of the model relative to the entity origin, but I dunno. It may also be a qc thing, which ain't my field of expertise :P 

oops, yeah, i guess they're not actually visible in fitzquake, unless you set r_oldskyleaf to 1. 

Have you downloaded the rat model and .qc from somewhere or have you created them from scratch yourself? 

I have this really neat idea that I want to implement in my hangar:

as the bay doors close, there are 10 light entities that successively turn off. The 1st light turns off at 3 seconds (it's 2500 bright), the 2nd one turns off at 4 seconds (it's 2300 bright) and so on, for 10 lights that each decrement by 200. The effect would be vanishing light inside the hangar, since the doors are closing. While it works with smaller light values and less lights, I'm getting a bunch of:

WARNING: Too many light styles on a face
lightmap point near (-1032 -833 -152), tech04_8
light->origin (-2560 -1024 128)
WARNING: Too many light styles on a face
lightmap point near (-1102 -837 -175), crate1_top
light->origin (-2624 -1024 128)
WARNING: Too many light styles on a face
lightmap point near (-1102 -837 -175), crate1_top
light->origin (-2592 -1024 128)
WARNING: Too many light styles on a face
lightmap point near (-1102 -837 -175),

I guess I'm not surprised, but might there be any way of implementing my idea without error? It would be a dramatic effect I haven't seen used before. 

I made the rat.qc partly by observing the progs.dat from Malice, partly myself.
Just went on untill friqqc did.'t give errors.
Then Necros helped me with a part.

The model just sinks in the groundbrush, like
http://members.home.nl/gimli/rat00.jpg

I first thought the rat.mdl wasn't well placed.
But I think it has something to do with the rat.qc
It also has a bite function, but apparently something in the rat.qc went wrong.

I placed it as a file, maybe somebody can take a look at it?
http://members.home.nl/gimli/rat00.zip

thanks. 

You can't have more than four light styles (including ambient) on each face. Too many switchable lights in one area saturates this very quickly. 

brighter lights reach farther, so they are more likely to overlap. 

Do you know any QC? If so it could be easier for you to simply make a new light style which is a single light which starts off bright and gradually fades.