The brush next to it was causing the problem. 

is that? The sword looks huge. 

Is there any way to up the limit of entities with targets you can have in Quake 1? When I was working on PH8DM2 I wanted to have lights that you could shoot out. They worked fine, but I could only have about I dunno, several, instead of dozens. 

on targeted entities, but you can't have more than 32 switchable (=targeted) lights. This means unique trigger chains; you can use same targetname on many lights. 

So, might there be anyway to up the limit from 32? My idea is that you could voluntarily shoot out a light or 2 for effect, or maybe once you get into a firefight, your shots or enemies shots might hit a light and kinda play on the map's mood. 

both tool and engine/QC support, which may cause compatibility problems. They all use the entity style key to communicate this functionality.

If it's only QC, you might make it by adding new keys that are transparent to tools/engine but handled by custom QC. I may be totally off here ... 

Since I am too dumb to learn QC, I guess I am SOL.

I'll just have to do the cliche walk-into-room-lights-go-out-oh-no routine. 

in terms of "lightstyles." There are 64 lightstyles, and 32 of them are reserved for switchable lights, and the other 32 are for things like strobe, pulse, candle flicker, etc. To go past 64 lightstyles would require an engine change to increase, and might require a network protocol change, too.

But, since there are only about 12 standard lightstyles actually being used, you could change the quakec to use the other ~52 slots for switchable lights. 

I've tried to fix the bugs and improve the help/hints for the Q1 entity definitions in QuArK 6.x; DataQ1.qrk. This is similar to the work of CZG's updated Quake.fgd file in WC and I've also cross-checked between this file and other available sources, e.g. the actual QC-behaviour.

This is basically a work in progress, but I think most of the stuff is in place. The file is here: http://user.tninet.se/~xir870k/DataQ1.zip . Backup the original and just replace it with this version.

Any comments are welcome. 

Aren't killtargeted objects restored properly when just issuing an engine "restart" command?

I've an item that should float in the air and using a func_wall beneath the item that's killtargeted by a trigger_once surrounding the player spawn point, it only works properly when the map is restarted using the "map" command; "restart" or "changelevel" doesn't work (the item drops to the floor). 

i assumed these all caused the level to load the same way (with the exception that players carry over stats during a changelevel)

It may be a bug related to the order in which edicts are processed; if so, maybe adding a trigger_relay with a small wait will solve it. 

what's happening is almost certainly related to the very short delay - and variation thereof - occurring on map load.

The solution to your problem may simply be adding "delay" "1" to the trigger_once that surrounds the info_player_start. 

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???