mTargetInLOS = false, in SetAimObject(), in aiplayer
by graham mcinnes · in General Discussion · 10/20/2009 (5:20 am) · 7 replies
not a real problem or a bug so much as an oddity,and possibly erronous behaviour.
specifically changing set targets with ai, and if you go from a target in los to one out of los.
the code i have issue with is :
never does any checks, but more importantly never raises any events. and further
down this messes up the raycast, to see if it has moved into/out of los...
in my scenario i had an aiplayer still firing, because
it never triggered the leaving los code causing it to stop.
i solved this issue by just replacing mtargetinlos = false; with the raycast used later.
then i put an if check to see if the target changed to avoid redundant raycasts
specifically changing set targets with ai, and if you go from a target in los to one out of los.
the code i have issue with is :
void AIPlayer::setAimObject( GameBase *targetObject )
{
mAimObject = targetObject;
mTargetInLOS = false;
mAimOffset = Point3F(0.0f, 0.0f, 0.0f);
}specifically the mtargetinlos = false;never does any checks, but more importantly never raises any events. and further
down this messes up the raycast, to see if it has moved into/out of los...
in my scenario i had an aiplayer still firing, because
it never triggered the leaving los code causing it to stop.
i solved this issue by just replacing mtargetinlos = false; with the raycast used later.
then i put an if check to see if the target changed to avoid redundant raycasts
#2
2nd: well i may be wrong but; in getaimove, it casts the ray,
then it checks mtargetinlos, to see if it should raise the in/out events.
which is where it causes problems, because if the target is in los when the ai's target is changed, then the target has to leave and come back into los to work again, but then it misses a throwCallback or two...
10/22/2009 (5:37 am)
1st: to asnwer the second question i am on a educational licence2nd: well i may be wrong but; in getaimove, it casts the ray,
then it checks mtargetinlos, to see if it should raise the in/out events.
which is where it causes problems, because if the target is in los when the ai's target is changed, then the target has to leave and come back into los to work again, but then it misses a throwCallback or two...
#3
10/22/2009 (6:49 am)
Okay, fair enough - it must get annoying being asked by people about a licence :P.Quote:then the target has to leave and come back into los to work againThat's right - if we set the target, and say it's in LOS, then there would be no callback. But by setting LOS to be false when the target is set, the ray will find the target, and we get an immediate callback for the new target.
#4
well maybe i am looking at different code, anyway,
after changin the target, in my version of t3d this code ...
checks mtargetinlos, as its false it does nothing, so it doesn't
trigger the exit line of site code.
i have just figured out this code is working for switching targets,
from one out of LOS to one in LOS, but breaks when you go from in LOS
to out of LOS...
10/25/2009 (10:54 pm)
wait, are you saying i'm right or i'm wrong?well maybe i am looking at different code, anyway,
after changin the target, in my version of t3d this code ...
// This ray ignores non-static shapes. Cast Ray returns true
// if it hit something.
RayInfo dummy;
if (getContainer()->castRay( location, targetLoc,
InteriorObjectType | StaticShapeObjectType | StaticObjectType |
TerrainObjectType, &dummy)) {
if (mTargetInLOS) {
throwCallback( "onTargetExitLOS" );
mTargetInLOS = false;
}
}
else
if (!mTargetInLOS) {
throwCallback( "onTargetEnterLOS" );
mTargetInLOS = true;
}immediately casts the ray, returns true as it finds an obstacle,checks mtargetinlos, as its false it does nothing, so it doesn't
trigger the exit line of site code.
i have just figured out this code is working for switching targets,
from one out of LOS to one in LOS, but breaks when you go from in LOS
to out of LOS...
#5
It does seem to be working incorrectly: if the raycast succeeds, and the target was previously in LOS... we say it's not in LOS? That's completely bugged. It seems that the if(getContainer should actually be if(!getContainer.
10/26/2009 (12:55 am)
Okay, that's weird. I remember that code being different in TGE, but I've removed it in my current build.It does seem to be working incorrectly: if the raycast succeeds, and the target was previously in LOS... we say it's not in LOS? That's completely bugged. It seems that the if(getContainer should actually be if(!getContainer.
#6
(ie an obstacle, cause it wouldn't hit its target)
well it works fine for the most part, its just changing targets...
it was something i thought should be brought up,
easy enough to fix, but did seem odd
10/26/2009 (3:15 am)
i think the ray is fine, it returns true if it hits something(ie an obstacle, cause it wouldn't hit its target)
well it works fine for the most part, its just changing targets...
it was something i thought should be brought up,
easy enough to fix, but did seem odd
#7
10/26/2009 (3:52 am)
Yes, it is odd - the ray returns true if it hit, but the logic in the brackets that follows should be switched. It will work when switching from one target in LOS to another in LOS.
Torque Owner Daniel Buckmaster
T3D Steering Committee
EDIT: Umm... just realised you're not listed as a licensee. How do you have source code access?