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