I didn't know about that. And that makes it easier for me now as Texmex did not correct one fullbright pixel in one of the problem textures even though it corrected the others.

Now, if I can just clear this packet_overflow problem a 'new' SP map is in the offing ... 

I am building my Q1SP in 2 parts for faster compile times and general convinience. Today I have realised that if I put both pieces together now and properly detail places which are missing detail, I will easily hit ~3500 brushes (without clip brushes and such). And this is Q1. AND both "pieces" are still missing many rooms. This puts my rough estimate of the final brushcount to 4000-4200 brushes. What kind of problems should I be expecting when I will eventually start merging both pieces together? 

Difficult to say with only those figures. # brushes is no problem for the compiler and brushes don't even exist in the engine (transformed into other objects).

Typical problems are clipnodes (especially if the map leaks) and marksurfaces, both related to complexity of architecture. Then comes entity overflows and vis problems if you're not careful with layout or brush amount/alignment.

Try to make complete builds as early as possible to get indication of problems. Then post here to get tips on how to proceed. 

My current Q1 map is around 7700 brushes and like aguirRe says, the brushcount doesn't really matter for the compiler - it's what the compiler turns those brushes into that can be a problem. Without clipbrushes, my #clipnodes is around 50,000. With loads of clipbrushes applied to out-of-reach areas I can bring the #clipnodes down to around 30,000.

#marksurfaces is another important figure. The limit here is again 32k, but you can exceed this limit in many engines and not have any problems. 

The map I showed pics of the other day is about 51oo brushes at the moment. It was started by joining 5-6 speedmaps I had lying around, a bit like you would like to do.

But as Kinn mentions it's the number of #clipnodes and #marksurfaces that matters.
Kinn mentions that #marksurfaces is limited to 32k, but some engines still can run it.
So far I have 41048 #marksurfaces and the map still loads in all the engines I tried it on, including the orig. GLQuake.exe.
Don't know about software Q since I cant run that! 

for the fence... i'm not sure what the technical problems might be, but you could try this:

rebuild the fence inside the func_wall, (make sure the texture alignment is identical to rule out z fighting) except cut off the bottom of the fence brushes just before they hit the terrain to stop them from splitting up the brushes.

i remember a while back, there was an article in pcgamer where some dude who mapped for half life gave "tips" to help map and he mentioned that in the desert maps, he had raised the catii 1 unit above the ground to not split up the terrain yet keep the shadows.

i remember suggesting that here before but it was not greeted warmly, so there may be technical aspects to this method that are negative... someone want to add to that? 

Single room map, player_start, single rectangular brush touching the floor but not the walls or ceiling = 210 clipnodes and 48 marksurfaces.

Add one default light = 125 clipnodes and 48 marksurfaces.

What principle is at work here and is it a useable feature when considering excessive clipnodes? 

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.