Couple of questions (auto aim, collision detection)

MDave · Post by **MDave** » Thu Feb 28, 2008 10:42 pm

Posting another few questions here since it seems to be the best place to ask questions about anything code related to quake

I'm a bit of a noob when it comes to programming (slowly teaching myself) and I've been trying to understand how the PF_aim function works in pr_cmds.c

What I want to change, if this is the right function, is to enable auto aim for the horizontel axis which already works for the vertical axis. Now I noticed a function below that one called PF_changeyaw, and one below that ifdef'd out, PF_changepitch. At first glance that seems related to it? But I'd just like to make sure it isn't so I don't trial and error for a week just to find out it isn't related

Note, I don't mind breaking compatability with quake since I'm doing this for my own total conversion using quake as its base, but keeping compatability would be nice

Reason I want full auto aim functionality is because the platform I'm working on is the PSP

Now for the collision detection question.

Would it be possible to modifiy the quake engine to use per poly collision detection for players and enemies, for weapon attacks (and not the world, don't think thats possible or wise

) ?

One last one I'll sneak in here.

Any idea how I'll be able to make the view model face the direction of the auto aimed target, so it looks more realistic instead of the bullets and nails etc. veering off at an odd angle compared to the guns actual direction?

This place rocks. Thanks for reading this far.

Post by **FrikaC** » Mon Mar 03, 2008 4:40 pm

What I want to change, if this is the right function, is to enable auto aim for the horizontel axis which already works for the vertical axis. Now I noticed a function below that one called PF_changeyaw, and one below that ifdef'd out, PF_changepitch. At first glance that seems related to it? But I'd just like to make sure it isn't so I don't trial and error for a week just to find out it isn't related

Those are unrelated and deal with the AI. Changeyaw is an engine side implementation of the changeyaw in ai.qc (iirc) for performance reasons.

As for the rest of your questions, I'm sure someone with the source in front of them could help.

RenegadeC · Post by **RenegadeC** » Mon Mar 03, 2008 6:16 pm

Horizontal aiming can be implemented by using the FrikBots AIM(); function and slightly modifying it, I did it in Codename Corporal's Dreamcast release. I'll find the code today if I have time.

MDave · Post by **MDave** » Thu Mar 06, 2008 12:56 am

Thanks for the replies!

Glad to know the changeyaw and pitch functions are not related to the aim function

RenegadeC, would that mean I would have to modifiy and add it to the engine code, or the progs code? I think it'd be harder to somehow make the view gun angle change direction to adjust where its actually aiming at with auto aim turned on. Surely theres *something* in the below code I only have to add or tweak to enable horizontal auto aim? Heres the unchanged pr_aim function:

Code: Select all


/*
=============
PF_aim

Pick a vector for the player to shoot along
vector aim(entity, missilespeed)
=============
*/
cvar_t	sv_aim = {"sv_aim", "0.93"};
void PF_aim (void)
{
	edict_t	*ent, *check, *bestent;
	vec3_t	start, dir, end, bestdir;
	int		i, j;
	trace_t	tr;
	float	dist, bestdist;
	float	speed;
	
	ent = G_EDICT(OFS_PARM0);
	speed = G_FLOAT(OFS_PARM1);

	VectorCopy (ent->v.origin, start);
	start[2] += 20;

// try sending a trace straight
	VectorCopy (pr_global_struct->v_forward, dir);
	VectorMA (start, 2048, dir, end);
	tr = SV_Move (start, vec3_origin, vec3_origin, end, false, ent);
	if (tr.ent && tr.ent->v.takedamage == DAMAGE_AIM
	&& (!teamplay.value || ent->v.team <=0 || ent->v.team != tr.ent->v.team) )
	{
		VectorCopy (pr_global_struct->v_forward, G_VECTOR(OFS_RETURN));
		return;
	}


// try all possible entities
	VectorCopy (dir, bestdir);
	bestdist = sv_aim.value;
	bestent = NULL;
	
	check = NEXT_EDICT(sv.edicts);
	for (i=1 ; i<sv.num_edicts ; i++, check = NEXT_EDICT(check) )
	{
		if (check->v.takedamage != DAMAGE_AIM)
			continue;
		if (check == ent)
			continue;
		if (teamplay.value && ent->v.team > 0 && ent->v.team == check->v.team)
			continue;	// don't aim at teammate
		for (j=0 ; j<3 ; j++)
			end[j] = check->v.origin[j]
			+ 0.5*(check->v.mins[j] + check->v.maxs[j]);
		VectorSubtract (end, start, dir);
		VectorNormalize (dir);
		dist = DotProduct (dir, pr_global_struct->v_forward);
		if (dist < bestdist)
			continue;	// to far to turn
		tr = SV_Move (start, vec3_origin, vec3_origin, end, false, ent);
		if (tr.ent == check)
		{	// can shoot at this one
			bestdist = dist;
			bestent = check;
		}
	}
	
	if (bestent)
	{
		VectorSubtract (bestent->v.origin, ent->v.origin, dir);
		dist = DotProduct (dir, pr_global_struct->v_forward);
		VectorScale (pr_global_struct->v_forward, dist, end);
		end[2] = dir[2];
		VectorNormalize (end);
		VectorCopy (end, G_VECTOR(OFS_RETURN));	
	}
	else
	{
		VectorCopy (bestdir, G_VECTOR(OFS_RETURN));
	}
}

It be handy to get the crosshair to move to where the weapon is autoaiming at too, hopefully that won't be too dissimilar to the weapon angle view modification.

Oh, thought I'd show what it is I'm working on exactly, screenshots taken directly off the PSP

http://bladebattles.com/kurok/kurok_screenshots/

Maps, models (minus the Raptors dino model, borrowing that until I make my own

), sprites and HUD mine, except for the health and ammo boxes I've yet to replace. Fully functional bow and arrow, god coding that so it behaves accurately was a pain.

Spike · Post by **Spike** » Thu Mar 06, 2008 2:42 pm

regarding aim. dotproduct between two vectors as in PF_Aim gives the 'angle' between two normalised vectors (in 1 to -1 range).

Code: Select all

   if (bestent)
   {
      VectorSubtract (bestent->v.origin, ent->v.origin, dir);
      dist = DotProduct (dir, pr_global_struct->v_forward);
      VectorScale (pr_global_struct->v_forward, dist, end);
      end[2] = dir[2];
      VectorNormalize (end);
      VectorCopy (end, G_VECTOR(OFS_RETURN));   
   }

See how it changes end[2] but not end[0] or end[1]? that's what makes it aim in only the vertical direction. (thus you can get rid of the dotproduct and vectorscale there).

MDave · Post by **MDave** » Thu Mar 06, 2008 9:17 pm

Ahh cheers for that explanation! I think I'm just about understanding how vector functions work. Works a charm

Need to have sv_aim at 0.99 though or else its too easy, even for a handheld with an analog stick as a means to aim. Now all thats left is a way to link that up with the function to CalcGunAngle in view.c and the crosshair (or maybe not the crosshair, I'll show the crosshair only if the fov is greater then 90 for zooming in, and also disable auto aim for the client somehow, until he/she zooms back out).

Is this a pretty fast per-poly collision solution by any chance? And does it work ok with model animation transform and frame interpolation?

http://www.telefragged.com/thefatal/q_t ... lision.txt

If thats not a wise idea for a handheld that sports a 333mhz processor (but a pretty powerful for a handheld 3d accelerated graphics chip), whats the best way to size down the width and depth of the player bounding box's? Currently, they seem pretty big except in height with, compared to quake's soldier and player model's, my more proportionate human models?

Sorry for all the questions

RenegadeC · Post by **RenegadeC** » Fri Mar 07, 2008 1:29 am

Guess you don't need me anymore, my method was done using QuakeC which would probably not be the best way to do it if you wanted the viewmodel weapon to move also.

MDave · Post by **MDave** » Fri Mar 07, 2008 3:56 pm

Actually, your help could very well be needed

hehe.

Since auto aim in the engine is server side (from the looks of it) that could be a problem for turning it on/off for each client that uses zoom. As for the viewmodel weapon to move also, I could probably get away with using stuffcmds to client side cvars that change the weapon angle, maybe. Guess its not a clean way of doing it, but it works.