Vectors & Trace in Game...

[JaedenRuiner]

Okay,

 

Well, i'm not trying to repost, but I FileFront has recommended I try other forums as there aren't very many coders on their site, and since I'm a member here as well, I figured...you know.

 

I've been having a lot of problems working with vector math and with the Trace functions that exists (you know like trap_Trace) and have been trying to figure out how to affect certain things. I've got some of it but not all. Primarily I'll pose my original question, but i'll follow with some other things as well. On a map, you have items and other things that exist within the world. You can put your crosshair on them, but forcepull/push doesn't do anything. (this is only a basic start, for i know people have altered that in the past). I have already rewritten a LOT of user interface code, and saber style code, and force code, including reworking force speed to work like force lighting (a push & hold not a duration toggle) and have removed saberthrow to work like a fire'n'forget, where the saber shoots off and falls to the ground. (i'm still working on the vector physics on that one, but more on that later).

 

However, when using trap_Trace(), I have tried to put the mask as CONTENTS_ITEM, but I only get the ENTITYNUM_WORLD as a response. I don't get the item entity number. However, when this is called:

numItemEntities = trap_EntitiesInBox(itmMins, itmMaxs, itemList, MAX_GENTITIES );

The item entity numbers are returned. But in w_force.c::ForceThrow() the bounding box is MASSIVE. You get a lot of entities, and when your force level is 1, it only uses the trap_Trace() (which as i've mentioned won't target the items).

 

It's those vec3_t types which are totally confusing, and I would expect certain things to be standard with Cartesian coordinate systems, but they aren't.

 

I was planning to "narrow" my field of vision, by adjusting the mins and maxs with my own custom sizes, thinking, as it were, that we have a standard "box" to look into. that box is provided by giving 6 coordinates. The (x,y,z) of the smallest corner, and the (x2,y2,z2) of the largest corner. In basic Cartesian design, if you list the lower left and upper right of any box, the points are quite simple to extrapolate for the 8 points (starting with the face closest to the view)

1. x,y,z
   
2. x,y2,z
   
3. x2,y2,z
   
4. x2,y,z
   
5. x2,y2,z2
   
6. x2,y,z2
   
7. x,y,z2
   
8. x,y2,z2
   

 

Pretty straight forward

However, there are a few issues. First, I would *expect* the pattern to be:

vec3_t[0] = x
vec3_t[1] = y
vec3_t[2] = z

Is this Correct?

 

Second:

Currently (for the force throw in this situation) the engine is basing the min/max off the center, which is set on the player origin. However, I am thinking that using the origin for my test is not the wisest course of action, and instead I should narrow that bounding box in relation to an "endpos" from a trace directly out from the viewangles and try to put the bounding box around the area in between the player origin and the final "solid" (wall) that the trace hits. Is this a wise idea?

 

Thirdly:

I am beginning to wonder if the engine is using Z (or depth in my humble opinion as it should be) as a directly line out from the player's view. X = Left/Right (according to player view), Y = Up/down (according to player view) and Z = Front/Back (according to player view). Is this correct, or is the x,y,z being computed based upon map coordinate origin? If they are based upon the map, how would I effect the bounding box to know that I am looking "forward" from the player view, affecting the correct axes of the bounding box, to equal a narrow vision from the player directly out from their eyes?

 

Lastly:

My vector math isn't what it used to be, and though my coding is phenomenal it isn't as well versed in C/C++ as it is in other languages. My scripting is far better than my C, and my Delphi is astronomical compared to both. But my linear algebra is shall we say more than a decade on the shelf gathering dust. I have figured out certain rules, like the VectorNormalize() returns a unit vector in the direction the initial passed vector is aiming, thus allowing you to scale it perfectly to the exact distance you want your item to travel. Simply physics, of unit vector angle, times x force, and voila you have movement. But, I have noticed several discrepancies in my though processes. Like, when the thrown saber goes out and eventually falls to the ground, it currently uses a TR_LINEAR computation. I'd like gravity to be involved, but I can work that later. Right now, I worked in ForceThrow() (when pulling) a way to find the saber that you are aiming at (since I removed the autoreturn and will eventually remove the BUTTON_ATTACK as the call-saber-back trigger). When you pull on the saber it does return to your hand. However, it bounces along the ground as it does.

I basically did this:

float dirLen;

if ( pull ) {
VectorSubtract( self->client->ps.origin, thispush_org, pushDir );
} else {
VectorSubtract( thispush_org, self->client->ps.origin, pushDir );
}
dirLen = VectorLength(pushDir);
VectorNormalize(pushDir);
pushPowerMod = pushPower - (dirLen*0.7);
if (pushPowerMod < 16)
{
pushPowerMod = 16;
}
VectorScale(pushDir, pushPowerMod * 3, pushDir);
if (pull && push_list[x]->s.weapon == WP_SABER) {
push_list[x]->s.pos.trType = TR_LINEAR;
} else {
push_list[x]->s.pos.trType = TR_GRAVITY;
}
push_list[x]->s.pos.trTime = level.time;
push_list[x]->s.pos.trDuration = pushPowerMod;
VectorCopy(pushDir, push_list[x]->s.pos.trDelta);
if (push_list[x]->s.weapon == WP_THERMAL)
vectoangles(pushDir, push_list[x]->s.angles);
push_list[x]->physicsObject = qtrue;

 

(Yea, this handles the rolling thermal detonators as well, because for some reason they weren't included in the original MP game. dunno why, even when the comments say they did, it never worked for me).

regardless, I first had both working with TR_GRAVITY, thinking that when you pulled the item it would streak towards you, but, I wanted to allow for "missing" the item, say you moved or something. Unlike the saber throw code, I couldn't find the "think()" method that processed the per-second movement of the item through the air.

My item code is similar, but if items hit a small lip in the map, they stop, (unless you are at a high enough angle to pull them more up than across), and as I said the saber bounces along the ground until it reaches you. So yea, I need help. I need some pointer to help explain the coordinate system in coding terms as well as some vector math help to affect the right level of movement and such. If i get the basics, or a point in the right direction with one thing, I can extrapolate the rest, I'm just a bit lost at the moment.

Thanks very much for your time,

Regards

[JaedenRuiner]

Well,

I have long since resolved this, and thought I might post a few comments about what I did to help others along the way.

 

First off it is quite possible to utilize the trap_EntitiesInBox() function in order to target quite a great many things. By setting the min/max bounding box you can grab all entities from func_* brushes, triggers, and Items, everything that is not simply the "WORLD" but some other entity as stored in the g_entities[] array. From there, using the trap_Trace function you can determine which entity you are precisely looking at with a personal function i wrote but is very simple to reciprocate given a modicum of understanding of vectors.

 

With each entity you can determine its type and its class (via the classname field and entityState :: eType field) With those you can limit or adjust which entities you retrieved initially are valid for comparison.

At that point you simply gather a distance between your origin and the entity in a loop, then trace a line along your viewangle direction vector at the distance between you and the entity in question. If that fraction is 1, the trace completed without colliding with anything, and the endpos vector should be contained with the entity's min/max bounding box around its origin. I wrote the function VectorContain() which is similar to vectorCompare, but instead of comparing two vectors for equality it compares a vector to two other vectors (min/max) for containment within. You do have to play a bit with some items, for the min/max of a Item placement holder (especially for weapons) is pretty much right on the floor of the map, so you tweak it a bit for each item, but in the end you can point directly at an item and determine which entity you are targetting.

 

For Func_brushes, there is a slightly different calculation because sometimes their pos1 and pos2 origins are relative and have to be computed. If you examine the ForceThrow() function in w_force.c file, you will see how they explicitly target a func brush to make sure you are pointing directly at it.

 

Well that was my quickie, and when the mod is completed I will be including my source along with if anyone needs a look see to help them with the vector and trace calculations.

 

Regards