Thanks For The Help On Grenade Lobbing, But
#1869 posted by aDaya on 2015/12/17 14:20:02
I'm still looking for a way for monsters to change attacks depending on its distance with the target/player
You Need
#1870 posted by ijed on 2015/12/17 14:35:53
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();
More On Choosing An Attack
#1871 posted by Preach on 2015/12/17 18:47:32
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.
@kalango
#1872 posted by Spike on 2015/12/17 19:37:27
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.
#1873 posted by aDaya on 2015/12/17 23:22:04
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.
You Need To
#1874 posted by ijed on 2015/12/17 23:28:23
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.
Declaring Variables
#1875 posted by Preach on 2015/12/17 23:47:50
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...
Yeah But
#1876 posted by aDaya on 2015/12/17 23:51:00
What types of declaration should I put "grenade velocity" and "High_GrenadeFly(dist)"?
#1877 posted by aDaya on 2015/12/17 23:52:33
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.
Tried The Following Declarations:
#1878 posted by aDaya on 2015/12/18 10:45:54
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
#1879 posted by kalango on 2015/12/18 17:28:36
Thanks for the info on CSQC guys!
GrenadeLobbing Issue: Resolved
#1880 posted by aDaya on 2015/12/18 20:38:10
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.
Mastery
#1881 posted by ijed on 2015/12/18 20:50:15
The difference between a novice and a master is that the master has made more mistakes.
@Daya
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.
OK What The Hell
#1883 posted by aDaya on 2015/12/20 22:40:19
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.
Debugging Advice
#1884 posted by Preach on 2015/12/21 01:02:39
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.
Sorry,
#1885 posted by adib on 2015/12/21 05:14:33
this nail flak-burst Ogre is not a Quoth monster you used on "Escape from Your Cell"?
@Daya
#1886 posted by Spike on 2015/12/21 05:30:26
'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.
With What Preach Said,
#1887 posted by aDaya on 2015/12/21 10:10:23
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.
Function Reuse
#1888 posted by Preach on 2015/12/21 18:25:08
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...
Oh No I Got It
#1889 posted by aDaya on 2015/12/21 19:18:40
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.
Yes
#1890 posted by ijed on 2015/12/22 18:50:25
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.
At Least
#1891 posted by ijed on 2015/12/22 21:16:59
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.
Dir = Aim(self, 1000);
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 ?
#1893 posted by Spike on 2015/12/25 21:58:08
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.
|