It's in client.qc, line 160.
If you don't know how to compile a new progs.dat or you don't want to include one with your map, there is no way to change it. 

Can I learn how to compile a progs.dat? If so.. where do I get started? 

modifying progs is a fairly advanced task - from a mapping perspective anyway, and it sounds like you're learning - I wouldn't advise going for coding just yet.

Having said that it's fairly simple to find the specific message and rewrite it as you please; though it does mean you'll have to release a pack instead of just the .bsp and compile the thing in the first place. 

Ok, I think I'll just stick to mapping for the time being. 

This thread is active, I must say. Have everybody figured everything out by now, or what..? Well, I sure have not. For instance, is it a problem to have two brushes occupying the same space - like, say I want to make a column appear to support a wedged ceiling.. so I simply create a brush from the floor to the ceiling, only that brush "collides" with part of the wedge. Should I carve the ceiling with my column, or just leave it the way it is...? 

QBSP will sort it out just fine.

Be careful with having two faces overlapping though. 

No or big overlaps = OK
Small overlaps = very bad

Usually, neat brushwork pays off in the end. 

...avoid "carving". Your tool of choice will make far worse decisions about breaking up brushes than you, with a bit of planning, will. 

Why? What's "small"? 2 units? 32? 

 

I have a weird issue in my current project: ingame, I have 2 monsters ( i.e Scraggs) and an entity (i.e a Quoth crucified corpse) that are completly pitched in black... To see their color, I have to shoot them very closely (i.e with DBS)... otherwize they look like shadows, full black, without any colors, even if in a lightned area... Is there any explanation for that ? 

So if either of these are hanging above somewhere dark, (as one often does with scrags and corpses) they won't be lit even if you place a big bright light right next to them. 

... because Scraggs are teleported into a wide-open area with a sunlight value of 150.. so I was expecting them to be lit... The more weird is that I have already 2 other teleported Scraggs in an other area that don't have any problem ... Any idea so ? 

There is a limit in the engine as to how far below the model the brightness trace is run, I think it's around 1000 units or so, but metlslime turned it up in fitzquake. Don't know how big your level is, so if that's not the problem I really don't know. 

OK, your informations gave me 2 different ways to follow in order to solve my problem and have a correct diagnosis. Thanks a lot: it was really helpful ! 

You might try lighting the box the Scrags are teleporting from to see if there is any difference.

Also, with crucified monsters, if they are placed slightly inside of other brushes, I have noticed they aren't always lit properly. Try nudging it around a couple of units to see if the lighting changes. 

You've probably already done this, but, if your corpse is crucified (ie. in the map ;) then make sure the spike is a func_wall or illusionary to stop it appearing black like you describe. It only turns up black if it's origin is inside a piece of solid brushwork - then light assumes it is outside the level and doesn't consider it. 

ijed: you are rigth, the origin of the crucified corpse was located in the wall: I moved it by 0.1 outside the wall and the isuue was solved....

czg / generic: In fact the Scraggs were correctly lit. The issue came from the fact they start to fly from a zone without brushes... except skybox.. so no solid wall below them... It is easily visible when the monsters fly from a solid area to a skybox area... and then faded from lit to black...

Thanks a lot for all the help provided ! You rock guys ! 

Which is the best, and why (formatting apart)?
I'm looking at 'if', 'if/else' or 'if/return'

a)
void() do_job_A =
{
if (something == 1)
do_this1;

if (something == 2)
change_this1;
};

or b)
void() do_job_B =
{
if (something == 1)
do_this1;

else if (something == 2)
change_this1;
};

or c)
void() do_job_C =
{
if (something == 1)
{
do_this1;
return;
}

if (something == 2)
(
change_this1;
return;
}
};

There may be 8 or 9 choices for the variable called 'something'. 

on if do_this1 and change_this1 somehow depend on each other. Otherwise the main principle is "always do as little as possible", which usually translates into else ifs (or even better, early returns) with the most frequent alternatives in the beginning.

If the condition "something" is complex, then split it up in nested or else ifs, with the most frequent and fastest conditions first. QC doesn't "early out" like e.g. C does. Function calls (especially calls to visible() or similar) should typically come last.

You can also take a look here: http://wiki.quakesrc.org/index.php/QuakeC%20Code%20Optimizations . 

Putting it in a lavapit and making it optional was a tight job. Now I'm at the point it iniates lavaballs from its bottem and fires them from its head. I rather would see it iniating from its head.

As I'm standing on a ledge, and when I turn back far enough, I still can see the newboss
and fire at it, but it doesn't seem to see me.
One can only kill it by firing on its bottem.

Because I borrowed it from the spellmaster, which is much smaller, the qc doesn't fit well on this much bigger monster.

http://members.home.nl/gimli/boss.dz

What should I change to the newboss.qc? 

This is very phallic if you run the die sequence backwards? 

This mdl I made myself, because the one in the deathmatch maker had a rather plump way of falling down.
Made no sense for such a big object.

I find it strange if I see it in Qml or Quark it has a right bounce box, but if I shoot it at the top it won't get hurt.(?) 

The box you see in quark/qml is the box that bounds the size of the model. It's used by the engine to determine when the model is drawn, but nothing else. The hitbox is determined by the QC, specifically this line:

setsize (self,'-32 -32 -24','32 32 64');

Adjusting these values will give you a larger or smaller hitbox as you require. The first vector gives the coordinate of the lower left part of the box relative to it's origin. The second vector is the upper right coordinate, so it defines a cuboid hitbox.

Making it see from a different point of view may be a little more complicated to fix, I'll try and post about that later. 

preach, I wondered about that quiete a time.
To make it launch from that height was already a fix, it tended to start shooting in angles up and below the player.