Finding angle at which a grenade hits a wall
 

Hi yet again everyone,

Sorry for the deluge of questions recently. I'm now trying to determine the angle at which a grenade hits a wall. I have the grenade entity, but I'm not sure how to get the angle of a wall it hits relative to the grenades vector of motion.

Can someone help me with this? Thanks a lot.

Re: Finding angle at which a grenade hits a wall
 

this may help you :

if you have two vectors, the dotproduct of the normalized vectors ( length is 1 ) of both ( dotproduct is sum over the products of the components x(i)y(i) ) is the cosine of the angle

the cool thing about it is that this simple stuff is working in n-dimensional vector spaces 8) ( at least on kanonical bases )

€ : argh, what did I write
€^2: LA sucks btw ... at least the nontrivial stuff ... but somewhen you'll call everything trivial, so there is still hope

Re: Finding angle at which a grenade hits a wall
 

euh, what do you want to do with that information? If you want to let bots avoid grenade's , you can scan within a specific area for grenades and let bots just react on the grenade vector. Or, even more neat is to store it as a possible danger vector, then keep track if it gets closer , and if it does, then react on it.

Re: Finding angle at which a grenade hits a wall
 

Well, I'd like my bots to run away from the grenade if it looks like it's going to bounce off a wall at a sharp angle, or run towards it if it looks like it's going to bounce at a shallow angle. I'm building these bots for a prototype simulation, not for real CS play, and this behavior is an approximation of diving for a grenade to throw it back if it's not bouncing around too much, or just running away if it doesn't look like it's catchable. Of course the bots won't actually be able to pick it up, but the important thing to show is that they "thought" to run after it in some cases. I chose the angle thing since CS doesn't let you vary the strength of your toss, so I had to choose another metric to base the decision on.

Any other tips? The dotproduct is useful, but the problem is that I don't have two vectors, just the edict of the grenade. If it's possible to get a vector for the wall, let me know!

Re: Finding angle at which a grenade hits a wall
 

do a traceline along the estimated trajectory and then, if you hit the wall, the traceline function returns also a face normal of the wall

Re: Finding angle at which a grenade hits a wall
 

s/"along the estimated trajectory"/"using the grenade edict's velocity"

Re: Finding angle at which a grenade hits a wall
 

what are you trying to say pierre ? what's that kind of syntax ?

Re: Finding angle at which a grenade hits a wall
 

ah... it's Unix syntax :) "awk", I think (or is it "sed" ? can't remember).
means "replace item 1 with item 2"
used like this (on a forum or on Usenet) it means that by saying item2 you were probably meaning item1
That was just to make thins more clear :)

Re: Finding angle at which a grenade hits a wall
 

' s/"along the estimated trajectory"/"using the grenade edict's velocity" '
I first thought it's CCED and really surprised (may be unknown to you, but it's a very common text editor in mid-1990s in China - as well as WPS) :)
Looks like Zhu Chongjun has stole the awk syntax

Re: Finding angle at which a grenade hits a wall
 

but I meant estimated trajectory, since most grenades do not fly a straight line ... :)

but estimated trajectory can still be a straight line, nevertheless ...

Re: Finding angle at which a grenade hits a wall
 

Hey everyone,

Thanks for the responses. I'm feeling kind of dumb, but I'm still having a lot of trouble getting a proper angle. I think a big part of the problem is that I'm not really familiar with the info that's made available by Half Life/CS. Could someone show the code necessary to get the angle of incidence? Here's what I've been doing once I have the grenade entity (pTargetEdict):

This gives me angles, but they don't seem to remain steady as I'd like them to, leading me to believe something is wrong, probably in my calculation of the dot product. Any LA gurus want to tell me my obvious mistake? =)

Re: Finding angle at which a grenade hits a wall
 

Hmm no, there are a couple easy mistakes in your code. Let me try to explain this.

1st rule is, never write into pEdict->v.anything, unless you're perfectly sure of what you are doing. The "v" structure is the entity variables (entvars_t), which is the sole property of the game engine. The game does whatever it wants with these variables. It's always safe to read them, but rarely to write in - unless you are positive that the engine won't mind about it.

Don't use oldorigin. It's obsolete. I'm not sure the engine even updates it each frame. It may still be in use for certain situations, but I wouldn't count on it.

What determines an entity are its origin and velocity. Use these variables thoroughly, these are safe ones. The velocity is simply the vector distance that the physics computed the entity would be moving during the current frame (provided there is no obstacle ahead).

If you want to make sure that the three x,y,z components of a vector are not null, you can compare the vector with g_vecZero. g_vecZero is a global const Vector which is initialized to Vector (0, 0, 0) at the start of the program and stays as is forever. Just do
if (pTargetEdict->v.oldorigin != g_vecZero)
instead of
if (pTargetEdict->v.oldorigin.x != 0 && pTargetEdict->v.oldorigin.y != 0 && pTargetEdict->v.oldorigin.z != 0)

pEdict->v.pContainingEntity points to pEdict itself. The usefulness of the pContainingEntity variable is to get a hand back on the edict_t pointer to an entity when you only have an entvars_t pointer. You can replace any occurence of pSomething->v.pContainingEntity in your code with pSomething.

origin (and oldorigin) are the vector distances of a particular entity relatively to the origin (center) of the world. That is to say, if you do
pTargetEdict->v.origin * 1000
your end point will be on a line that passes through the point zero of the world AND through the entity, 1000 times further from the origin of the world than the distance your entity currently is. This is very unlikely to be what you wanted to do.

If you want to fire a TraceLine from pTargetEntity's position in the direction of pTargetEntity's movement, good parameters for TRACE_LINE are:
TRACE_LINE (pTargetEntity->v.origin, pTargetEntity->v.origin + pTargetEntity->v.velocity * 1000, ignore_monsters, pTargetEntity, &tr);

3.14159 is already defined (with much more accuracy) as M_PI. You can use this macro each time you want to do trigonometry.

I am not familiar with DotProducts at all, and generally speaking I don't trust math I don't understand, hence I would rather retrieve the incidence angle like this:

The incidence angle is the angle difference between the flattened angle of movement of pTargetEdict, and the flattened angle of direction of the hit plane normal PLUS 90 degrees (adding 90 degrees to the hit plane normal to have the actual angle of the wall, and not its orthogonal counterpart).

Hence

float fTargetEdictAngle;
float fWallAngle;
float fIncidenceAngle;

fTargetEdictAngle = UTIL_VecToAngles (pTargetEdict->v.velocity).y;
fWallAngle = UTIL_VecToAngles (tr.vecPlaneNormal).y + 90;

fIncidenceAngle = fWallAngle - fTargetEdictAngle;

I think I cannot be too mistaken. Hope this helps :)