> The beta or qtest used 44khz

I think I checked all of those distributions and TMK that was not the case.

If you have a version of id Quake with 44.1kHz sounds, I would like to see (or rather, hear) it. 

i always downsample my stuff to 11khz 16bit and 8bit if the sound has constant volume. if you leave the built in downsampler do the job itself, it does it on a similar level as the image resizer in glquake. (sucks) 

http://web.archive.org/web/20080408013326/http://www.stay.dsl.pipex.com/qsrp.htm

Then search for the filenames. 

I'm surprised how well some sounds and music can be at 11 khz 16 bit. Currently, I'm mixing everything at 44 khz 16 bit stereo, then make a final downsample copy at 22 khz 16 bit mono for glquake. Lower recording levels keep sound quality at par between the different sample rates. I'd say choose 11 khz 16 bit over 22 khz 8 bit though, 16 bit is more important. 

8 bit is really grotty.

I also think that the downsampling is done by the sound card, and hence the quality of that might play a role, but I don't know for sure.

I don't see the small loss by downsampling in realtime from 44 -> 11 kHz as a problem, considering the abysmal quality that comes with 11kHz anyway.

The result of downsampling *always* sucks. 

Ah OK, thanks. But I'm pretty sure I looked at all of the QTest sounds and almost none of them are 44kHz - a fair bit are 22kHz though. 

The result of downsampling *always* sucks.

I figure you'd better make sure your sounds are still acceptable when downsampled. For example if your sound is primarily high-pitched, it will be destroyed by 11kHz downsampling, and you should probably come up with a different sound. If it's mostly low with the high pitch adding just a crisper overall sound, then the people playing with 11kHz mixing will at least hear something appropriate. 

this are basically DSP (Digital Signal Processing) theory: you can over-sample, nor down-sample a signal without interpolation filtering..
For down-sampling it is straight forward as soon as the new sampling rate is a multliple of the original sampling rate (e.g x1/2). Additionally, it is obvious that human ear dynamic range has to be taken into account (that is in [20Hz:20kHz] range)... So sampling a signal @11kHz is quite crappy except if you are almost deaf, at 22kHz it can be acceptable if there are not that much high frequency (i.e above 11kHz)... and 44kHz is the best..
Furthermore, remind that each individual has its own ear dynamic that vary a lot with age: a children has a higher dynamic range than an gran'ma generally...
Anyway, there are no better method than never down-sample a sound under 22kHz if you want an good (or acceptable) sound quality... and also a good soundcard ;) 

how crucial is the 'too many lightstyles on a face' warning? will it crash old engines or just cause stuff to not light properly?

4 is an annoyingly low limit 

Extract from aguirRe's tool tips: http://user.tninet.se/~xir870k/tooltips.txt

"Too many light styles on a face, lightmap point near (x y z), tex, light->origin (x y z)"
Too many styled (torches, flickering etc) lights in the specified area. Reduce # styled lights or their range in that area. You can also try option "-gate #" to limit the range of
attenuated lights.

Actually the limit depends of your light tool, but as explained above it can be easily solved by reducing the number of lightstyle on a face... maybe you should contact aguirRe and ask his advices... and if you are lucky, he could do you a favor by sorting out a new light tool with increased limit regarding lightstyle... who knows ;) 

i don't think it's just a tool limitation or aguirre would have pumped it up higher.

what will happen is that the light on those faces from the extra lightstyles just won't be shwon. this can lead to hard edges between lights.

aguirre's light is better than most and will try to discard the least visible one or prefering to use the minlight/sunlight before anything else.

still, it's something that you should try to avoid.

as for old engines, the problem will look the same as in new engines (unless it's an engine with real time lights of course). 

cheers jpl but it is kinda obvious what it means & how to prevent it ;p just wanted to know what the negative impact on the map was.

what will happen is that the light on those faces from the extra lightstyles just won't be shwon. this can lead to hard edges between lights.

i see.. i usually get it when attenuated lights spill over into the next room and i don't think the effect has ever been noticeable. excessive compile warnings are never nice but until now that's been the only reason i've tried to avoid it.. 

Dumb question but where are those orange textures that I see people shelling L4D and HL2 maps with? Which WAD? 

rj: yeah, like you'll never notice it if the overlapping areas have only a small amount of light shining on it, but try placing several bright switchable lights like 128 units apart and you'll definitely see it. sometimes it can be ignored, and sometimes not. :S 

Negative effect in map is also straightforward: bad lightning on a face can simply gives somes weird shadow effects, making the lightning completely unrealistic... 

the effect wasn't visible so it seemed like it could have been a false warning that possibly only applied to old engines and/or may have caused problems loading the map in some setups...

i know now that isn't the case, however that was not as obvious as suggesting that a 'too many lightstyles on a face' problem can be solved by reducing the number of lightstyles on that face... capiche? ;) 

Well, I should have written ...bad lightning on a face may simply gives somes weird shadow effects.

Actually, if the tool generates the warning, it means there is a problem. It does not mean it is visible, as it certainly depends of each individual light strength on the face that generates the issue...
I remember having such warnings in my very first map, and that I never noticed any weird light/shadow effects ingame....

So you have to inspect the area ingame, and then:
- either you are lucky and you don't give a shit to the warning as nothing is clearly visible
- or you are in deep shit as you have to rework your lightning effects....

Experiment !! 

this is not an old engine vs. new engine bug. The bsp format only allows 4 light styles per face, so light.exe will pick four and if there was a 5th style, its light will not be present on that face.

What JPL says is true: if the extra style was contributing a very low amount of light to that face; its absence will not be noticeable.

If yo do need to fix it, you should reduce the number of switchable lights or styled lights in the vicinity of that face -- either fewer styles, or fewer targetnames (for switchable lights) or give those lights a smaller radius or something. (assuming the lighting tool gives coordinates of the face.) 

i gather that now. nonetheless i thank you for your detailed reiteration of JPLs reiteration of necros' answer to my original question ;) 

But what I remember more is one compiler giving the error, and not another, in exactly the same map. Any ideas? 

I sent some wads out to Quaketastic, not the stuff you mentioned though. Was too early to think staight also... 

different compilers compile differently? ^_^; 

When a scragg is killed and falls to the floor, how is the floor being detected i.e. time to stop falling, - is it within qc or is it an engine thing? 

scrag uses hull1 when doing collision. all collision is done by the engine. 

Is there a way (shortcut) to snap brushes to the grid in gtkr1.5?