I remembered Inside3D/InsideQC had a tutorial for that, but for some reason I can't find it.

Try this one,it's not hijacked:

http://www.insideqc.com/qctut/ 

I did a Grunt shooting accelerating rockets, I tried to make in a custom explosion sound, but it plays the vanilla one instead and the explosion sprite doesn't come up.
code: http://pastebin.com/0aBFGkFP

Another thing, still on that Defender-like: how to make him trigger an attack where the player is in a set distance? Looking at the Ogre code doesn't seem to answer me.

and MadFox, this is exactly where I went, but I couldn't find it. 

What's the way of reducing the amount of stun taken by a hit for a monster? Is it related to armor values? 

You need to look at the function in ".th_pain". Two good examples are knight_pain and sham_pain.

Typically there are three decisions to make in a pain function. The first is whether the monster had a pain animation recently or not. Usually this is a bit of code like:

if (self.pain_finished > time)
���return;

self.pain_finished stores the first moment the monster is allowed to go into pain again, and this code skips a pain animation entirely if it's too soon. This is a very important bit of code because it stops pain animations overlapping - without it you'd have monsters entirely stunlocked by a stream of nails.

The second choice is to decide if the damage is high enough to trigger pain. Typically only very large monsters do this, like the shambler:

if (random()*400 > damage)
���return;

This means we skip the pain animation randomly, in proportion to the damage inflicted. For example, a shambler will only go into pain from a 200hp hit 50% of the time. A full double-shotgun blast does ~50hp, so that's only a 1-in-8 chance of a pain animation. 400+ hp in one blow will always cause shambler to go into pain, but even a quad rocket to a shambler isn't powerful enough for that.

The last choice is selecting which pain animation to use, here's the code for the knight:

r = random();

if (r < 0.85)
{
���knight_pain1 ();
���self.pain_finished = time + 1;
}
else
{
���knight_painb1 ();
���self.pain_finished = time + 1;
}

The line knight_pain1(); start this pain animation immediately, and it will run to the end before the monster starts attacking again. The main difference between these two animations is that knight_painb is much longer. A way to make the pain animations less severe is to pick the short animations more often, so the monster resumes fighting earlier.

You'll also notice that it's this part of the code which sets the pain_finished time, in this case saying the knight won't go into pain for 1 second. The enf_pain is an elaboration on these ideas, as there are 4 pain animations to choose from, and the last one has a longer pain_finished time than the other. So another way to make your monster resistant to pain is to increase these times, but be careful! Setting these too high made the Quoth monsters irritating to fight, as they were too relentless. 

...is what I believe the original post on inside3d was. Me and Prime collaborated on this into Gnouc's clean src a while ago into a creepcam2 project. IT seemed to work pretty good from what I remember, and I thnk we put in a skill comparison to activate it as well. YOu can copy the code from the Ogres function here: [ https://github.com/teknoskillz/Creepcam2/blob/master/monsters/ogre.qc ] 

Trying to _perfect_ as best as possible the starting pos of the LG beam using a right handed vwep model sort of like the one in dpmod has. The tricky part is finding a compromize between the 1st person view, and the external viewposition. I believe there is no perfect fit, but this is the code I am experimenting with in W_FireLightning ()

local vector angl;
// angl = self.v_angle;
angl = self.angles;


normalize (v_forward);
org = ((self.origin + (v_right * 7)) + ((v_up * (10 + ((angl_x * -1) / 3)))) + (v_forward * (12 + (((0 - angl_x) / 1.05)))));


I believe the problem may be v_angle versus angles, as the first person view will always be using the v_angle perspective, and using .angles definately manages the external view better so far in my experiments.

Just curious if anyone ou tthere knows a better way? Im using Darkplaces as the engine and it has a waist level lightning option in the menu but on or off does not seem to show much difference in this case. 

that's going to change based on engine, right? fitz engines use a different weapon offset than other engines, and it's positioned differently when you look up or down. 

Hey, anyone knows any resource for learning CSQC? Mostly HUD related CSQC. Every link i find seems to be dead.
Also i wanted to know if FTE supports CSQC for Hexen ;P 

There is some CSQC info at this location http://forums.insideqc.com/viewforum.php?f=16&sid=1 

I'm still looking for a way for monsters to change attacks depending on its distance with the target/player 

A Choose Attack function.

Look at the bottom of the monster where it's Ai routines are initialised, you should find something like this:


self.th_stand = ogre_stand1;
self.th_walk = ogre_walk1;
self.th_run = ogre_run1;
self.th_die = ogre_die;
self.th_melee = ogre_melee;
self.th_missile = ogre_nail1;
self.th_pain = ogre_pain;


All the ones which have a '1' at the end are sending the monster to that animation sequence whenever the conditions are met. The others have a routine which decides which animation sequence to send them to, like this:


void() ogre_melee =
{
if (random() > 0.5)
ogre_smash1 ();
else
ogre_swing1 ();
};


So instead of just going directly to ogre_smash1(); it has a 50% chance of going to that OR ogre_swing1(); 

There's a good template to base your attack choosing decision on in SoldierCheckAttack. The first half of the function is basically checking if the player is visible. Look at the bits afterwards involving enemy_range - they set a variable chance of attack according to player distance.

You'd want to adapt that so it changes the attack itself rather than just the probability. I'd change the bit which uses self.th_missile to directly name the attack I want to use. e.g:

if (enemy_range == RANGE_NEAR)
{
���alien_spit_acid1()
���return TRUE;
}
else if (enemy_range == RANGE_MID)
{
���alien_fire_rocket1()
���return TRUE;
}
return FALSE;


There's an important extra bit of the puzzle here, in order to get a custom checkattack function you need to add it to CheckAnyAttack. Otherwise you get the default CheckAttack, which only gives you the choice of 1 melee attack and 1 missile attack. 

FTE servers translate stuff such that the client can't really tell whether its hexen2 or quakeworld with a certain set of extensions.
so yes, fte+csqc+hexen2 should work fine on the condition that you can work with the extra stats that the server sets up to provide whatever hud functionality normally expected for a q2 mod.

for those stats, check http://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/engine/common/bothdefs.h for the STAT_H2_ enum values.
you can override or add to these inside your SSHC code, if you need.

huds are otherwise 'just' a case of calling drawpic+drawstring etc.
the tiny font can be selected with drawfont=loadfont("", "gfx/tinyfont", "8", -1);
then switch drawfont between that and -1 or something.

its otherwise just a glorified quake mod. 

Had to use Preach's method for Grenade lobbing because FTEQCC doesn't recognize "makevectors2" nor "grenade_velocity", but even with that and the HTML rewrites he doesn't recognize attack_elevation. 

Add those to defs.qc.

Add them to the end of the list though, too high up and you change things the C code is expecting to be there. 

Daya, there's a general programming idea here which seems to be tripping you up. The idea is called declaring variables, here's a short tutorial on it.

https://www.macs.hw.ac.uk/~pjbk/pathways/cpp1/node45.html

When the compiler is complaining about names it doesn't recognise, it usually means you're missing the declaration. You may need to add the declaration, or you may need to move it earlier in the file. You can also get this error if you misspell a variable, so check the spelling of the error and the declaration carefully.

Incidentally, the declaration for attack_elevation is right below the sentence
"Finally we need to change the ogre�s firing sequence to make use of all this new code:"
you may have have copy-pasted that bit incorrectly... 

What types of declaration should I put "grenade velocity" and "High_GrenadeFly(dist)"? 

Forgot to tell I decided to use Teknoskillz' method because Preach's method doesn't seem to work, as the shooters still aren't Z-aware. 

vector grenade_velocity;
float grenade_velocity;
void() grenade_velocity;
(He always says "float should be vector")

and
float (vector v) High_GrenadeFly;
vector High_GrenadeFly;
(He mostly says "Bad field type")

I feel like I'm dumb as bricks, christ 

Thanks for the info on CSQC guys! 

I remembered an old unfinished mod I made when I first started QuakeC modding, and the Ogre's code contained said Inside3D's grenade lobbing tutorial code, which was actually small.

I feel relived now, as this issue just made my development came to a full stop. 

The difference between a novice and a master is that the master has made more mistakes. 

The code I linked to was from the inside3d article...it may have even been in the AI area to make FRikbot lob the grenades, not sure. I dont recall who was the author, but I can say for sure in the coop game mode with monsters, the ogres determinately are improved using that code. Glad you got it working tho. 

I've been working on an Ogre-like that shoots a flak-burst of nails, I only took out the grenade code and replaced it with said flak-burst of nails, but the problem comes to the chainsaw part of all things, where FTEQCC says at the very end of the declaration it's "incompatible".

http://pastebin.com/YyARaT2Z (at line #113, at the very end of the chainsaw declaration, "};") It's the same chainsaw code from the ogre's file that I never touched, I guess that's why "FIX ME" is written there but if that's the case I don't know what's the solution. 

It's really a good idea to post the exact text of the error message you're getting, although posting all the code is also helpful.

My guess is that you've still got a function called chainsaw in the original ogre code, and the identical copy in your new is confusing the compiler. Functions should only be defined once, so I'd recommend just deleting the copy from this new file - the definition from the old file will be fine if you haven't made any changes.