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. 

this nail flak-burst Ogre is not a Quoth monster you used on "Escape from Your Cell"? 

'incompatible redeclaration' means you defined something twice, but with different types.
the error should include some kind of note that says where the previous definition/prototype can be found, while the error line itself says the new/later redeclaration of it.
just make sure they both have the same type (and only one initialisation, ideally).

like preach says, you probably already have some existing function/field/monkey with the same name elsewhere with a different purpose, in which case just rename one of them or something.
Alternatively you can prefix both defs with the 'static' keyword so that they won't conflict with other definitions from other .qc files. 

I remembered a solution I did before when something similar happened with animation declarations: I just had to rename them according to the monster's name.

@adib I'm not using it, I'm recreating it with my own code as far as I can, with a different skin and sound set. 

But Daya, if both of the functions are identical apart from the name, wouldn't it make more sense to just use the same function in both places, and make sure that there's only one definition? I'm worried from your response that my explanation didn't make sense... 

Like, I could've deleted the chainsaw code inside butcher.qc, and the declarations would actually mention the one in ogre.qc, but I didn't do that simply for keeping things in their own sides, even if there's no changes. 

Duplicate entries are anathema for pro coder's - typically you want to keep only one function but make it more complex, so it would know which monster was calling it (butcher or ogre).

But the format of the QC doesn't help, since some attack functions are in weapons while many others are scattered across all the monsters.

One of the things we did in RMQ was to add an attack library qc, and then move everything to that one central location. 

That was the intention, to make everything modular. We got quite a way before the project collapsed.

The strength of a system like this is that your code is easier to debug and more open - if you decide to chop and change abilities or add new ones its pretty easy.

Especially since, in quake at least, almost all the projectile creations are the same apart from a few different variables like damage done, model used and so on. 

Is there any difference in the aim built in function than merely calling makevectors on your v_angle / angle and assigning :

dir = v_forward;

??

Or does the aim function do that but normalize the result? Also whats the float of 1000 or whatever you enter there actually do ? 

aim typically returns v_forward.
traditionally it also nudges the z value to point towards entities with .takedamage==DAMAGE_AIM
this gives the same sort of aiming found in doom with its complete lack of pitch angles.
of course, because this means peoples rockets always miss the enemy's feet, most engines default sv_aim to 2 or so in order to disable the autoaim/automiss effect. 

What does 2 do as opposed to 0? 

It's just a dot product comparison, which means sv_aim is actually fully on instead of off. 

Esoteric but interesting. 

for fun, set sv_aim to -1 then try to do rocket jumps with a monster in the same room (including behind you) :) 

So it seems I got the hang on sprite thingies, but I don't know how to properly integrate them.

From my observations on the explosion sprite, this is what I came up with: http://pastebin.com/DzipzBRq 

I'm guessing that you want the plasma to animate while it flies, let me know if not.

The first problem is plasmashot1...etc are functions, but you have defined them in the middle of the LaunchPlasma function. Move those above the rest of the code and it should compile.

The second problem is that you aren't using them, you need something which says self.think = plasmashot1 to kick off the animation. Change the line for SUB_Remove to plasmashot1 instead and change self.nextthink = time + 0.05. Then you should get animations.

The third problem is that SUB_Remove never gets run, and so plasma might stick around forever. This is actually a bit harder to sort out, because we can only have one think function at a time, and we're already using it to run our animation. How can we schedule a think for 5 seconds in the future if we need to think 20 times a second in the meantime?

The nice thing is that your code will run without fixing this, so have a think about it first and I'll explain in a later post.