View Single Post
Old 03-25-2010, 12:02 AM   #4
JaedenRuiner
Rookie
 
Join Date: Apr 2004
Posts: 19
Quote:
Originally Posted by XycaleTh View Post
It might be that because it's touching the ground, it's registering as starting in a solid. I'm not sure what the trace function would do this in case - whether it detects the first collision AFTER the starting point, regardless of if it's already colliding with something, or whether it takes the first collision to be the result. If it's the first case (and you would be able to test it, just check if tr.fraction is 0.0 when tr.startsolid is true), then you could only check for tr.fraction != 1.0.
Hrm. Okay, First, that was very helpful in explaining what the parts of the trajectory_t structure mean. i've looked at the inline documentation and figured it was like that, but it isn't, as one might say, accurate in its determination. Often times things are flagged when they shouldn't be or the trace hiccups, with minutia that wouldn't normally be a factor.

So I will list out my code and then list the results:

My code is implementing a force grab, like a pull/push on items, but instead of just moving them, it grabs them and they subsequently can become a bludgeoning weapon. in my think() method for the item, i am moving it around until it hits something, which cancels the grab and the item bounces away. pretty straight forward.

first I do a trap_trace() starting at the object's current location with an end position about 24 units further along the current trajectory. my trap_Trace() uses the mins, maxs set to vectors at -ITEM_RADIUS and +ITEM_RADIUS for each item. this is the tricky part.

Yes, when the item, say a weapon, is floating on top its little hover thing where one can pick up the items, it works fine until i hit something. however, when it is lying on the ground, i can grab it, but the moment i move, it falls back down again. I noticed at this time startsolid was true. So i thought about doing another test, but my only theory for the second test was to remove the mins,maxs, or the bounding box around the item. The trap_Trace() seems to detect collisions for any area around the origin that is contained within the boudnign box. So, for the second trap_trace() with NULL instead of min and max, i get different values. I had the system Com_Printf() out the values and these are my results:

1. Tr = Start: 1, All: 1, Fract: 0.000, Ent: 1022, Pos(140.597, 20.730, -8.756)
2. Tr = Start: 0, All: 0, Fract: 1.000, Ent: 1023, Pos(140.597, 20.730, -8.756)

1. Tr = Start: 0, All: 0, Fract: 0.774, Ent: 1022, Pos(18.527, -6.771, -0.875)

1. Tr = Start: 1, All: 1, Fract: 0.000, Ent: 1022, Pos(154.887, 28.865, -7.479)
2. Tr = Start: 0, All: 0, Fract: 1.000, Ent: 1023, Pos(154.887, 28.865, -7.479)

1. Tr = Start: 1, All: 0, Fract: 1.000, Ent: 1023, Pos(159.430, 25.361, 14.508)

1. Tr = Start: 1, All: 0, Fract: 1.000, Ent: 1023, Pos(47.179, -63.674, 14.925)

1. Tr = Start: 1, All: 1, Fract: 0.000, Ent: 1022, Pos(25.908, -113.040, -4.655)
2. Tr = Start: 0, All: 0, Fract: 1.000, Ent: 1023, Pos(51.164, -122.102, -4.655)

1. Tr = Start: 1, All: 0, Fract: 1.000, Ent: 1023, Pos(62.883, -127.932, 10.647)

1. Tr = Start: 1, All: 1, Fract: 0.000, Ent: 1022, Pos(21.971, -109.270, -10.904)
2. Tr = Start: 0, All: 0, Fract: 1.000, Ent: 1023, Pos(42.560, -124.218, -10.904)

1. Tr = Start: 1, All: 1, Fract: 0.000, Ent: 1022, Pos(29.604, -115.936, -9.992)
2. Tr = Start: 0, All: 0, Fract: 1.000, Ent: 1023, Pos(62.724, -138.012, -7.349)

the 1. tagged lines are the values from the first trap trace with the mins and maxs, the 2. tagged lines are from when i have NULL instead.

Occasionally when i pick up the item, startsolid and allsolid are true and fraction is 0. other times when i pick up the item, startsolid is true and fraction is 1. I need to find the pattern in this that helps me determine that the trap_trace is ill-legitimately pegging the min,max as starting solid when it is right above the ground, and thus which values i can use to make sure the second trap_trace() verifies the actual collision. I'm thinking using the entitynum to help to a degree, but even that isn't perfect. the problem is the bounding box intersects with the current plane the item is resting on, so it is detecting a startsolid collision, when it shouldn't. this is what i'm trying to compensate for, so that when the object is moving through the air, the bounding box helps to predict an actual collision, but when i'm picking it up from the ground the bounding box doesn't cause a false positive.
Thanks
J"SD"a'RR


Jaeden "Sifo Dyas" al'Raec Ruiner
http://www.wayoftheleaf.net
JaedenRuiner is offline   you may: quote & reply,