Ah thanks - I'd forgotten about that technique. I may just leave it as purely func_wall though, considering how the lighting in that particular area is fairly flat (also I'd imagine having a world model fence there would give vis a fair bit to chew on ;) ). 

I'll try to dig a bit deeper what the issue is about marksurfaces. At least I now think that the warning about them being >32k is probably not correct. 

The warning for marksurfaces <32k seems right after all, but there's another limit that should be checked too; #faces must also be <32k in normal engines. I've now added this warning to tools/engines.

I haven't been able to find out why some maps can exceed the 32k marksurfaces limit and still run OK in normal engines, it appears to be just "luck" ... 

that might be interesting: http://www.gamedesign.net/node/view/639 

Hmmm...I can't seem to call ambientsound() midway through the game - it only seems to work at level start - is it supposed to be like that? 

limitation of the engine. :P

there's a hacky way to get around it... frikaC explained it to me a while ago.

basically you can use my code:


float SVC_SPAWNSTATICSOUND = 29;
void(float soundnum, vector org, float ambvolume, float atten) spawnambient =
{
WriteByte(MSG_ALL, SVC_SPAWNSTATICSOUND);
WriteCoord(MSG_ALL, org_x);
WriteCoord(MSG_ALL, org_y);
WriteCoord(MSG_ALL, org_z);
WriteByte(MSG_ALL, soundnum);
WriteByte(MSG_ALL, ambvolume * 255); //translate this into a value between 0 and 255...
WriteByte(MSG_ALL, atten * 64);
};


soundnum, in this case, is actually the numerical value of a precached sound. the number is equivalent to when it was precached. so the first precached sound is 0, then 1,2,3, etc...

look through the qc files and you'll find the first sounds to be precached are the ones found in weapons.qc.

ambvolume * 255 is so you can use a 0 to 1 value and it will be converted into a number between 0 and 255.
same for atten, but in this case, it needs to be multiplied by 64.
don't ask why... i don't really know. something to do with bytes and whatever... 0 to 255 is 8bit or something, a short is 64... meh. :P 

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.