Also I post messages on almost ten forums. Finally, with your help, I found it. Thanks a lot.
Best regards,
Ciprian 

then I posted the wad the same time on the Quake forum, Ciprian.

Those rats, could it be something with the MoveBox_Solid. As they vanish "into" the brushes? 

Is your email working? I haven't received anything from you for a very long time. 

It is, I just haven't been checking it for a long time, since Chapters dominated my communications, my sleeping patterns and my deteriorating mental state for several months ( I can't remember the actual penalty for seeing a polyp in the Call Of Cthulhu RPG, but I reckon both necros and I lost 1D6 Sanity Points just trying to make the damn thing fly )

Will check and respond. 

How can it be a model sinks in the groundbrush,
and when this brush is substracted it becomes visible? 

at http://user.tninet.se/~xir870k . All engines are updated with several features/fixes, e.g. improved demo playback handling. Light now includes multi target support and improved trigger checks. There's also a new demo conversion/validation tool; ConvDem. Please also see readmes for details.

Any comments are welcome. 

does anybody have half life textures converted for Quake? 

used something in his maps i think, you should be able to rip them. http://www.saunalahti.fi/zakaa/ 

OK, Quake question.

I have a very small map, < 150 brushes total, and yet I am having an issue where a brush is greying out in software/Winquake, and turning into sky in DP/GLquake.

The brush is a simple, 6 face rectangle, seen here: http://blitz.circa1984.com/fucking.jpg

I am using Tyrann's compile tools as well, if that helps.

Thanks for any help you can give. 

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.