Thanks necros! That's some pretty interesting stuff there. So, to clarify, I would have to make sure that the required sound is always precached in world.qc, (preferably near the beginning, so I can keep track of it more easily) for it to have a consistent soundnum.

Something else I did try, and I'm not sure if this is good practice or not, is just calling the regular sound() function on a looping .wav - once the sound starts, it seems to loop automatically ad infinitum, which is more or less what the ambientsound() function does is it not? 

yes, you can do it that way, however, when the player is too far away from the sound emitting entity, if it is not an ambientsound(), the game doesn't bother to keep track of it in some way, so the sound will stop playing. (i think this happens when the ent's volume reaches 0 from attenuation) so when you get near to the ent again, the sound won't play.

another hacky way of doing it would be to have a looping sound. find out the exact length of the loop up to the second decimal.
ex: length = 2.39 seconds.
use the play function to start the sound, and keep restarting the sound every 2.39 seconds without the autoloop feature.
the sound will be interrupted if the player goes into the console or menu or whatever though. also, if host_framerate isn't 0, then the rate at which the sound is called will be different as well.
you could also leave the autoloop markers in the soundfile in, and keep overriding the sound on it's own channel everytime but that's just ugly. 

Thanks again. The best solution I guess would be the one in your first post, which incidently I wouldn't call particularly "hacky" - it's just making use of an already existing network message that is otherwise unused in the QC. 

Do stereo .wav files play correctly in Quake 1? Or should I turn them into mono? 

use mono. 

Nothing in aguirRe's Tool Tips

Can someone give me an explanation. I have just run into this error after adding the final brushwork to FMB100. The brushes are not important and I can leave them in or take them out (although it looks much pretier with them!)

It is only a warning and I can not find any problem in the vicinity of the brushwork e.g. random clip_brushes, non-solid brushes etc.

But I would like to understand what is happening. 

ok. 

I think I remember getting this in Bastion at some point; is it associated with any hull in particular? IIRC, it didn't seem to cause any detrimental effects when I had it. 

The first thing qbsp does to a brush face in the map file is to transform the three points into an infinite plane. These three points are all on this plane with only minor float precision offsets.

If I understand it correctly, qbsp then starts to figure out how this plane is limited (clipped) against the other planes in the brush. In this process, more points (vertexes) will appear in the positions where the planes meet.

When these new points are checked against the original plane, they might be slightly off and when the distance exceeds a certain limit (0.05), a warning is printed.

In my latest compilers, I've added an automatic healing of such points, i.e. adjusting them to the plane. It appears to help a bit, but I'm uncertain of the theory here ...

In any case it's usually rather easy to find the problem spot and align the vertexes, at least in hull 0. 

In qbsp, I get a warning during LoadMapFile:

*** WARNING 03: Line 60471: Brush with duplicate plane

would it be possible to print the origin/location of this brush, so that I can chase it down? 

with a one button click if you use GTKRadiant (sniff, sniff), Hammer user! 

AFAIK it's an editor error; you shouldn't be able to produce such a thing. Therefore I doubt that you can fix it manually in the editor other than deleting/recreating the entire brush and hoping the editor won't do it again when generating the map file.

Also, at the time of discovery, the location of the brush isn't known yet. The extra plane will just silently be dropped with no side effects. 

so I can safely ignore it? 

and I forgot to mention that if you can enable some brush numbering scheme in Hammer that will add line comments to each brush/entity, you might be able to backtrack from line number to editor brush that way.

In QuArK I can do that and I guess GtkRadiant has something similar.

Btw Kinn, your choice of emoticon is a bit odd ... 

and I forgot to mention that if you can enable some brush numbering scheme in Hammer that will add line comments to each brush/entity, you might be able to backtrack from line number to editor brush that way.

Hmmm...I don't think I can do that. Can any other Hammer users confirm this?

your choice of emoticon is a bit odd ...

lol, the wink? I dunno, it kind of makes sense to me, almost as if qbsp is taunting me with a wry "I know something you don't know" warning, without actually telling me the source of the problem.

^_~ 

I thought the little guy was leaning down to his left side to snort a line. I guess your interpertation makes more sense. 

er, I was humming 'dosey dotes' while writing that. 

The classic examples of that would probably be Mixed face contents or Bad contents.

Somewhere in your 10k brush map, there is something bad. Go figure ... 

I've just downloaded the latest version and it seems to have support for Quake1. It loads .map files and shows the Quake1 entity list. I haven't tried the compile routines as I cannot get the editor to show the textures.

Does anyone know how this is done - there is nothing in the Help files on Quake1 texturing. 

Place the .wad file in your id1 folder. I think that's it, I don't have it installed anymore. Unlike the earlier versions, 1.5 will read the textures straight from the .wad file.
For what it's worth, I would use GTK 1.4 or earlier rather than 1.5, a bit more messing around to get it set up, but far less buggy etc, and IMO, just better to use. 

I have a similar problem with GTK1.5. I have the .wad files in the id1 folder, but when I compiled the map nothing showed up.

When I asked about it, they said to include the path to the .wad file in theworldspawn, but that did nothing either. So, I still dont know how to get it to work. 

Thanks, that's a start anyway.

Zwiffle: are you compiling from within GtkR or are you using some sort of 'tweak'?

I am still using BspEditor with BspBuild and have no problems apart from using the 3D view, which is extremely slow (I have a decent system). Also, you have to be careful not to hold your finger on the forward/backward key because the keyboard buffer fills faster that the screen can draw and there seems to be no way of stopping it moving once it's started.

Hence, I am looking at changing editors. 

Ok, i'm using quark and don't know how to get a "quake" key to turn into a key card. 

do not use quark 

It depends on worldtype value into the worldspawn of the map ... see below.. So to have a jey card instead of a key use value 2

"worldtype" "#" // Describes time of environment (changes appearance/name of keys)
// 0 == Medieval (medieval)
// 1 == Runic (metal)
// 2 == Present (base)

You can take a look at http://www.gamers.org/dEngine/quake/QDP/qmapspec.html for further details about QuakeC specifications..