Where to find Hitzones ?

[razorace]

Originally posted by Tchouky

it converts and angle into a vector

 

Ok, two questions:

 

1. Does the engine handle angles in degrees or radians?

2. Please explain the nature of the conversion. Why does it convert a 3d vector (vec3_t) of angle data into three different 3d vector outputs instead of one vector?

 

I've done some checking using google but I'm not getting anywhere. The stupid functions aren't explained!

[Wudan]

Uh, I thought it was calc'in vectors in x y and z directions ... and stuff

[razorace]

Originally posted by Commodus

Yea, check q_math.c, it has the definitions for most, if not all the mathematical functions.

 

BTW, what exactly is the function DotProduct used for?

 

Well, q_math.c doesn't explain most of the functions! A simple one sentence explaination would suffice! They're mainly simple math functions.

 

DotProduct does a dot product on two vectors and returns the result. It's a standard vector math function. What it does is the sum of the multiplication of both vector's components. The result is a vec_t (scalar) value. It's a scalar value of how far each vector travels across the other. (multiple the scalar by one of the vectors to give you an actual vector of the travel path on the individual vector)

 

I'll get you a link on the the nature of dot products.....Here we go and here and here. I know, there's a LOT of crap covering up the purpose of the function.

[razorace]

Originally posted by wudan

Uh, I thought it was calc'in vectors in x y and z directions ... and stuff

What? You lost me. Towards what are you refering to?

[Wudan]

I was posting in regards to your AngleVectors inquiry/reply to TcK's rather laconic reply.

 

Re: vec3_t

 

From code3arena: "... it is simply an array of three vec_t's (in other words, an array of three float's). These three floats represent what we call the x, y and z components."

 

Re: AngleVectors - well, see the above Re: vec3_t. Because I'm not a formally trained coder, I don't think I could explain it without looking silly.

 

[Edit: I don't think I could explain it ]

[razorace]

Well, it normally does but it looks like it sometimes stores angle data instead. I THINK AngleVectors converts the Angle data to the standard coordinate system but I'm not sure what system teh angle data is in (radian or degrees) and WHY it outputs to three vec3_t's instead of one...

[Jaii der Herr]

it is degrees.

 

And it outputs three because an set of yaw pitch and roll cannot be discribet with less than 2 axis.

Ok not a good sentece *g*

 

It's simply 3 because sometimes you need the up, or the right, or the forward axis. Or all of them...

[razorace]

Thanks Jaii der Herr. It looks like it's set up so this function creates three directional vectors for a "new" 3D coordinate system that's asqued from the "real" coordinate system. It's then used by the rest of the g_gethitlocation to determine hitzones.

[Wudan]

Vectors are never reported as 'standard' coordinates - if you tried to use them like that, your file would not compile.

 

degrees makes sense, because other functions that use it are represented in degrees, hence cg_thirdpersonangle 180 views player from the front.

[ASk]

There's another method of hitboxes in the code. It's used when the player is ATST.

 

What it does:

- In gclient_s struct there are 3 vars

int			damageBoxHandle_Head; //entity number of head damage box
int			damageBoxHandle_RLeg; //entity number of right leg damage box
int			damageBoxHandle_LLeg; //entity number of left leg damage box

they are used to hold the number of the entity that is used as a hitbox.

Every frame the client gets ClientThink_real function called. If the player is ATST the code gets executed:

if (client->ps.usingATST && ent->health > 0)
{ //we have special shot clip boxes as an ATST
	ent->r.contents |= CONTENTS_NOSHOT;
	ATST_ManageDamageBoxes(ent);
}
else
{
	ent->r.contents &= ~CONTENTS_NOSHOT;
	client->damageBoxHandle_Head = 0;
	client->damageBoxHandle_RLeg = 0;
	client->damageBoxHandle_LLeg = 0;
}

the ATST_ManageDamageBoxes does this:

checks whether the corresponding hitboxes exist. If not, it creates them, assigning them a constant as the redirectDamage var (to differentiate between them), the owner number as the redirectTo, the function DmgBoxHit as ent->touch and the entity number to the corresponding variable in the owner entity ( damageBoxHandle_Head , etc).

 

The original DmgBoxHit is empty. However using code like:

void DmgBoxHit( gentity_t *self, gentity_t *other, trace_t *trace )
{
gentity_t *owner = &g_entities[self->r.ownerNum];
if (self->damageRedirect == DAMAGEREDIRECT_HEAD &&
	owner->client->damageBoxHandle_Head == self->s.number)
{
                        // hit head
}

if (self->damageRedirect == DAMAGEREDIRECT_RLEG &&
	owner->client->damageBoxHandle_RLeg == self->s.number)
{
	// hit right leg
}

if (self->damageRedirect == DAMAGEREDIRECT_LLEG &&
	owner->client->damageBoxHandle_LLeg == self->s.number)
{
	// hit left leg
}
return;
}

we could make different situation for each case (and this function takes animation into account I believe.

Also in G_Damage there's a piece of code:

if (targ && targ->damageRedirect)
{
	G_Damage(&g_entities[targ->damageRedirectTo], inflictor, attacker, dir, point, damage, dflags, mod);
	return;
}

which could be manipulated in the similar way.

 

Again, as far as I checked, these hitboxes are assigned on each frame, to the current model parts positions, thus taking the animations into considerations.

[Jaii der Herr]

I wouldn't trust Atst code *g*

 

 

and as you can see it would mean at least 6 entities for a player model ( player could be used as body, head, 2 arms, 2 legs). I think using the g2trace is a better solution...

[razorace]

How do you suggest using g2trace to impliment better hitzones? Personally, I'm not sure we NEED a much better hitzone system. It would require a lot of coding and there isn't much use for it, it's only used for death animations and dodging at the moment.

[Wudan]

Uh, we need a better one for obvious reasons.

 

saber combat is supposed to be 'intense', not 'wave your saber at the enemy', so, to make hitting certain locations more damaging, or possibly alter it so that some shots aimed at certain locations are easier to deflect, why ... it'd change saber combat, and it's the best way to add more depth to the saber system without adding a gizillion more styles.

 

Of course, I'm wrong in a lotta ways, but that's beside the point.

[razorace]

That's more game mechanics than a hitzone problem. Personally, I don't think it's a big deal. The simplistic hitzones we got now are able to do stuff like that. you just have to alter the way the damage is calculated and dealt. The function is only called for JediDodge and death animations anyway. The game runs so fast as is that it's barely noticable.

 

Now, if someone comes up with a good, fast, non laggy improved hitbox system I'll impliment it in MotF but until then, I'm not going to mess with it unless I notice a serious problem during testing of MotF's new features.