when they have a message field, unless it's completely empty ("" no space).
If yours also beep without, check the trigger/button firing them. 

OK, I have a single trigger_realy that causes the issue: it is generating a beep while triggering a sound, and it is not really the effect I wanted... I have this one to check particularly: thanks for the info ;)

BTW, as I already launched a fullvis run, is it possible to hack the BSP to remove the message field, or is it mandatory that I recompile all the stuff from scratch in order to obtain the wanted effect ? 

Set the trigger's sound field to an invalid value then, like 4.

You can easily recompile the map with -onlyents if you only edited entity flags. Remember to run light -onlyents too if there are switchable light styles in the map. 

I'll try it... and even if it doesn't "work" as I want, I can launch again my fullvis, as it was running only since 12 hours... so not a big waste of time...
Anyway, thanks ! 

Sorry for flogging a dead horse:
Would it be too much work to add support for detail brushes to Qbsp? After all, it has been done before by Alexander Malmberg - the source code is available too http://quest-ed.sourceforge.net/files/mapc/qutils_2_src.zip
Are there obvious reasons why this would be unfavorable, technical issues or the like?

Func'ing architecture does work, but it has disadvantages too. Detail brushes (not splitting geometry) might be better in certain situations. 

those versions, they're introducing new file formats (e.g. map and prt) and AFAIK require modifications of all tools (possibly engines too).

I don't like messing with the original formats; I want to keep the stuff open-ended so you always can use whatever step that works best for you.

There are already "Q1" maps/mods that require specific tools and/or engines to work. 

...could not be compatible with the stock quake engines, as far as I know.

One thing that could work is having func_walls or func_illusionaries that cast shadows on the world and on themselves. I guess you'd have to have a flag or key that tells light.exe which bmodels you want this feature for. Then, you'd need to run each light trace through both the world BSP and every shadow-caster entity's BSP, and see if it collides on any of them before reaching it's target.

Obviously this would only make sense for entities that don't move. 

recently i've noticed a few problems when lighting rocky/terrain areas:

http://www2.jameson-h.com/fr/ftp/rj9k/img/light1.jpg

http://www2.jameson-h.com/fr/ftp/rj9k/img/light2.jpg

using tyrlite v0.92...

anyone have any tips on how to avoid these? is it just a case of dodgy brushwork or are there other light utils that fix it? 

Had something similar when I did not add -etp to the Qbsp.exe 

Try updating to latest TyrLite, 0.92 is really old now. If it is what rudl suggests (i.e. you're using the QuArK ETP feature), then a more recent TyrLite will fix that.

If you want to try my Light (and still have the ETP issue), make sure to add -etp to the Light cmd line (not qbsp! ;).

If it isn't an ETP issue, then using 4x4 oversampling might help. If all else fail, it's probably a brush alignment issue and might be fixed by manipulating the brushes near the spot. 

not qbsp!!! 

figured i'd give your light util a try. the same result seems to occur (i use worldcraft, so doubt it's ETP related) but i've decided i need to completely rebuild that rock section anyway because the shadowing looks weird in too many places.. it could use neatening up too!

on a related note, i've been playing around with your util & quite like the "second sunlight" feature (as well as the -soft option). i have a suggestion though, i'm not sure how plausible this is, but is it technically possible to add some form of falloff to sunlight, similar to that of attenuation 1 lights? i ask as i've been using attenuation 1 lights as a replacement for sunlight recently (since until now i could only get sunlight in one direction) and have grown to like the effect they give, where the light starts to gradually fade out towards the ground (with a very subtle ratio). if this were possible with sunlight/second sunlight then it would make things an awful lot easier! 

It is still possible that its the -etp because when you open the quark .map file with worldcraft it does not delete the echanced texturing 

->aquirRe's convmap tool 

i've never even heard of enhanced texturing. based on that is there much chance of my map having used it? 

Quark always uses it when you have very complex structures (detailed oudoor-brush)
I always use -etp even if I don't have this problem 

Sorry I wrote enchancd texturing in my last post
ETP=Enchancd Texture Positioning 

Are those faces completely black or very dark
if they are very dark it can also be caused by the fast light option (is always activated when QuickGo) 

If they are not completely dark I'm pretty sure that it is caused by fastlight (it is not very accurate and does not calculate the detailed areas) 

You can't have attenuated sunlight, it would kind of defeat its purpose ... You can however change the way sunlight (and other lights) affects angled surfaces via the anglesense features.

Also, make sure to use sunlight3 instead of sunlight2, it greatly improves details in the sunshadow. See readme for lots of details.

ETP is just a name for any method of specifying texture positioning that couldn't be done in the classic Quake map format. For Q1 I only know of QuArK ETP (its default map format) and Hammer's Valve 220 (recommended for QuArK, too). With those formats, you can freely rotate textures in all three planes.

If you're using WC 1.6 or earlier there's no ETP. The bad shadows are then probably caused by complex or bad brushwork and they might be reduced by using -soft -extra4 in my Light.

However, it's rather common to have a few bad spots in terrain-like brushwork. I'd guess it's a limitation of the bsp format/tools and/or accuracy of float values. 

aww..

i was more thinking of technical limitations.. i'd disagree that it had no purpose. i made a little demo map & took two screenshots to compare:

http://www2.jameson-h.com/fr/ftp/rj9k/sunlight.htm

the first is with your sunlight & nothing else; the second is with attenuated lights & no sunlight info. whilst the shadows enhance the first screenshot, i think the second provides a much nicer & more realistic feel with the fadeoff. it probably shouldn't replace normal sunlight altogether but i think it might be something worth looking into at least..

btw, i turned -fast off and it seems to have reduced it a bit a few bits remain but they aren't so noticeable. i'll start doing extra compiles nearer completion.

and it's WC1.6 i use, oldskool bi-planar texturing all the way ;) (although admittedly the lack of freedom can be a pain in the arse sometimes)

thanks both of you for the suggestions! 

that attenuated lights have no purpose ;) I meant that there's no such thing as attenuated sunlight; the distance attenuation at any practical surface difference near the Earth is next to nil.

Since there already are attenuated lights in the light tools, the sole purpose of sunlight is that it's non-attenuated and with parallel rays. Before, mappers used to add many pointlights or "delay 3" (infinite) lights along the skyline to mimic real sunlight.

And while I may be biased here, I think the first shot is the most realistic one, although the 2nd is also interesting. In any case I definitely recommend adding subtle ambient pointlights to outdoor areas to reduce the somewhat uniform sunlight. Maybe some hint of a cloud effect ...

Btw, if you use WC together with TreeQBSP, I'd suggest adding the -oldaxis option to handle 45 degree textured surfaces correctly. 

what you say about sunlight in reality is very true, but if the sunlight in question isn't direct (ie, it's a cloudy day) and you have a fairly enclosed chasm environment (like my maps tend to be quite often :p ) then the further down you go, the less sky the rock is exposed to. maybe it could just be called 'skylight' as opposed to sunlight.. or something. i dunno. i guess i should just figure out a way to combine both methods & stop moaning about it :p

and thanks for the oldaxis tip, i've noticed quake renders diagonals differently to WC.. 

if you look back in the screenshots thread at the 'numen' preview i posted up, you can see the skybox i'm using and can hopefully see why i don't consider sunlight appropriate, since the sun is pretty low & the majority of the sky is a flat orange shade.. infact i've already got the sunlight at a low z-angle (-15ish) in the first map since it really makes an impact in the 2nd shot 

I worked some time with qmle and imported dxf files. Is there a way to foresee the excact shape of the model?
I mean, let's say I want a cube of 64x64x64 as new imported stand model in qmle.

Point is that when I import a dxf file it is imported in qmle as a random shape. I can never tell the excact measures. I could use the transform tool, but in this way it won't become the cube I need.

My solution seemed to created a 64x64x64map, compiled it to bsp and try bsp2mdl and try to load it in qmle.
But the dxf files I draw from it change shape when I import them to my CadCam programm.