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. 

Knowing how poorly the q1 engine and compiler generally handles slanted stuff, how insane would this be:

I want to design a map that's made of concentric sections surrounding a circular core. Every area of the map would have a gentle (or, near the center, not so gentle) curve to it. All lines would either be radial or circumferential. Essentially the entire map would be designed for polar coordinates, but imposed on a square grid.

Insane? Mad? Masochism? 

You mean like this?

http://www.student.vu.nl/h.e.beck/girl8.gif

Yes, the compiler handles stuff like this fine. 

like I said, you're out of your mind. :) does that even come close to the 8 grid? 

handles stuff off the grid afaik. For SM32 I had to rebuild Gibbie's bit because it was on a floating point grid >:(

Radiant handles stuff down to 0.25 I think, and last time I used it you could build

I think the plan to make that in Quake is masochism. I built about half of my wolfenstein map at 45 degrees when there wasn't much need for it. It wasn't particularly difficult, just time consuming and annoying to build. Having said that, gibbie's map looks like it is generally at more challenging angles.

Gibbie: How about an editor xz view? I want to see how the ceilings were built. 

Shady xz:
http://www.student.vu.nl/h.e.beck/shadyxz.gif
Girl8 xz:
http://www.student.vu.nl/h.e.beck/girl8xz.gif

In gtkradiant 1.5 you have to turn off "Snap planes to grid" or everything goes wrong. The smallest grid for both maps is 0.125. That is also the smallest grid you can set in gtkradiant. However if your brushes are not on the smallest grid (eg because of clipper usage) i think it will still save them properly.

Anyways, most of the time i don't mess on such small grids. I mostly just use prefabs from a curvey thing of concentric brushes i once made, kinda like:
http://www.student.vu.nl/h.e.beck/curve.gif
This also has pre-aligned textures :) 

A map called "girl" filled with phalluses? And people thought I was perverted. 

about filling a girl with phalluses? 

about filling a girl with phalluses?

I really hate during a DP when they rub your weiner up against another guy's junk while they are giving oral, but other than that, nothing! 

I think that I am glad that I don't understand American too well! 

the plural 

yeah, but generally it only takes one to fill 'er up. 

is there a way (hack) to have a trigger_push that does not play the wind sound? 

As far as I can tell, the windfly.wav is only used by the trigger_push. Therefore if you are doing a mod you could get away with supplying ambience/windfly.wav in your mod directory where you have a copy of null.wav (from the sound/misc folder in pak0) and renamed windfly.wav. That's a hack.

If you play with Qc it's straightforward to create a flag for noise or no noise.

But Preach will probably come up with some wizard way of doing it :) 

The function that causes the push of the trigger also specifically plays ambience/windfly.wav - unlike doors which play whatever wav file is in self.noise1 for instance. So there's no possibility that the sound could be changed to null.wav by entity field editing. The only possible line of attack would be to make sure that the player's .fly_sound is set to a time far in the future, but I doubt there is any function in the QC that will perform this. 

i already expected it to be impossible. thanks for clarifying.