Second answer was not true.
I used a modified code to launch a single phantom_shot one frame after another.
After adding a phantom_shot void I made the attack scene:

void() fant_atk2 =[ $atk2, fant_atk3 ] {PhanMissile(1);};
void() fant_atk3 =[ $atk3, fant_atk4 ] {PhanMissile(0);};
void() fant_atk4 =[ $atk4, fant_atk5 ] {PhanMissile(-1);};


The spread shot came from the (1) (0) (-1) addon.

Now I changed the fant_shot into the one a vormit uses to launch a vore ball.
This works as intended.

pro: I have a monster launching three voreballs.
quo: they don't launch at the same time (I don't mind).
They don't spread anymore on the (1)(0)(-1) arg because the voreball code has three statements, that specify their behaviour.

So what the code misses is the statement of the ShallHome statement of the vormit to include a spread shot and (if possibel) at the same time. 

n/t 

I renamed the ShalMissile code to PhanMissile and now there are three vorbal attacks slightly after each other.
Now idea how to launched them at once, nor how to spread them. 

To have three launch in the same frame just call run the code three times.

ShalMissile();
ShalMissile();
ShalMissile();

To have them launch in different places change

missile.origin = self.origin + '0 0 10';

to

missile.origin = self.origin + '0 0 30';
or
missile.origin = self.origin + '0 0 -10'; 

I might be a dumbass.., I tried

void() fant_atk2 =[ $atk2, fant_atk3 ] {PhanMissile(); PhanMissile(); PhanMissile();};

but only one voreball appears. 

No that makes 3 voreballs appear at the sane time and in the same place. 

Also ShalMissile. 

I see only one. And for clearance, I rewrote the shalMissile to PhantMissile. This gets a bit hazardeous.
Think I'll just stick with a launch apart way. 

I see only one.

That's because they are all in the exact same position. 

So useless as it causes only extra dmg.
Thank for explain. 

Is there a way to quit intermission without a map restart? I was reading engine code and it looks like it's not possible. Once you enter intermission state, you have to restart or load a new map.
...but maybe I'm missing something and there is a way?

ps. through custom progs of course. I know FTE can do this... but I want some general solution 

Alright... so as I though, there is no way. 

One of the problems is that you probably can't send standard clients an "undo intermission" message even if you can get the server on board.

I mean, if all you want to do is put some centerprint text on the screen while the player can't move, you could maybe use cutscene code to "simulate" being in an intermission. But if you want all the scoreboard stuff then I think you're right that there's no way to achieve that in standard quake. 

What are the recommended non-commercial ("free" as in beer) tools for compiling vanilla WinQuake nowadays, without the x86 ASM code?

Is there an updated tutorial anywhere?

While I'd like to take advantage of new features such as multicore support, I also wish to retain as much backwards compatibility as possible (Windows XP support, etc). 

Can someone explain what this is doing in armor_touch?

if (other.armortype*other.armorvalue >= type*value)
return;

I do understand if your red armor drops below a certain amount you can pickup yellow which lowers your armortype to 0.6 from red's 0.8. I assume this the line that controls this?

Also, I am aware this was replaced in Copper. I'm just looking to understand this a bit more clearly. 

It's basically trying to help prevent you from screwing yourself by e.g. picking up 150 yellow when you already have 148 red. It's making sure that you're actually getting better damage resistance from the pickup. 

I am trying to get a grappling hook working properly.

My last problem is that after you have shot your last hook (when ammo count is 0), it does not let you detach from the hook any more by pressing "attack" one last time and switches to another weapon instead (while you remain attached to the chain).

Maybe someone can look at my code and check what's wrong or what needs to be changed?

QC file (5 KB):
https://mega.nz/file/NcoQDZRQ#F3uze1lnu2mVNVKuYmxTeNkZEQ_k5oaQ6LqOF9PJrB8

Possibly relevant variables from defs.qc:
float DROIDMODE_GRAP;
float DROIDMODULE_GRAP = 1;
float GRAP_OUT = 1;
float GRAP_STUCK = 2;
float MOVETYPE_FLYMISSILE = 9;
float MOVETYPE_NOCLIP = 8;
float MULTI_MODE_CHOMPING = 16;
float MULTI_MODE_SCORPION = 8;
float SOLID_SLIDEBOX = 3;
float SVC_FINALE = 31;
float TEAM_WHITE = 1; 

I suspect that the problem is outside of that file, and instead is part of the general-purpose weapon handling code. I'd check the W_CheckNoAmmo function in weapons.qc. That function has a special exception to allow the axe to attack with no ammo, and I think you need to carve out a similar exception for an attached grappling hook with no ammo. 

I tried everything, but the best I can accomplish is that the counter reaches 0, but then if you try to launch the hook again, it's crashing to console.

I have gathered all related code files and packed them together, maybe it will give more insight.

Download (zip, 10 KB):
https://mega.nz/file/0EZXUI5R#9issmLjIVXErj5Kcdo7Me4Osg87DBGTHC1ul-SDJaHw

Basically the hook (grap.qc) is part of a tool belt (droid.qc) replacing the axe. It also comes with flares (flare.qc) and TNT (plastic.qc) which suffer from a similar problem: Once ammo counter reaches 0, you are still holding them in your hand (ideally it should switch either to the next tool or at least the next best weapon).

The tricky part about the hook is really that you are still supposed to fire it when it has 1 ammo, and you can still be attached to the hook when ammo is 0 after that and then you are supposed to be able to detach with "attack" still.

Any help would be greatly appreciated. I am sitting at this already since the better part of the week and can't figure it out. 

Have a look at how W_CheckNoAmmo looks in the standard Quake code, the version in your mod isn't the same. Even the original W_CheckNoAmmo function is arguably badly designed: you might expect that it's just a function that returns TRUE if the current weapon is out of ammo, and FALSE otherwise. Instead it:
a) returns TRUE if the weapon has ammo and FALSE if it doesn't
b) has a side-effect - if you had no ammo, it changes you to a weapon you can attack with!

In the original code there's an exception that prevents it changing your weapon if you are attacking with the Axe. This makes sense - the axe doesn't require any ammo, so there's no need to switch away. In your mod the axe is replaced by items which do have ammo counts, you can't just wave through axe-slot-weapons completely unchecked. But you need to add a more specific exception for the situation you describe - if the player has the grappling hook out and is currently suspended from a rope, then return TRUE before the W_BestWeapon part. 

Yeah, the way axe replacements are handled is indeed annoying. It shouldn't switch directly to the best weapon if you run out of hooks/flares/TNT. But can this completely be solved in weapons.qc or would you have to change stuff in other files, too? 

It's a starting point; try that first, add some dprint statements so you can check whether your changes are correctly coded and do what you expect. If it still doesn't fix the problem, then you can start expanding the search. As Raymond Chen says, "debugging is an exercise in optimism". 

I am afraid I am still not able to get it working. Neither the code insertion point(s) nor what is actually supposed to be written there is clear.

Maybe the check already needs to happen while firing. If I want to hide the flare model when ammo counter reaches zero, it's only hidden after I press the fire button again after the counter is already zero. However, this should happen right after firing the last available flare. We are not speaking of the grappling hook, which is a special case and I still have no clue how to tell the game it's supposed to detach you still from the chain after firing the last hook and ammo counter has reached zero. 

for the grappling hook, a possible solution would be to subtract the ammo on detatch rather than on launch. That way you would still have 1 ammo when you are attached to the final rope. Not sure if this would be considered confusing to the user, to see 1 ammo when they are currently hanging by the last rope. But as soon as they let go and it went to zero, they would probably understand. 

Actually I managed to make flares and TNT behave the way I wanted. If their counter goes below 1, it directly switches to the next available tool (and not the best weapon) instead of reaching zero. Best weapon is only selected if all tools are empty. To achieve this, a small addition had to be made in W_Attack of weapons.qc (where the axe is defined, replaced by the utility vest).

Right now, the grappling hook already has the intended behavior of counting down to 0 when you are dangling from the final chain. However, pressing Attack again would then switch to the best weapon instead of detaching the player. You can still get off the hook by jumping, but it's not as intuitive as it could be.