Game Development Community

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 :

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

#1
10/20/2009 (10:16 am)
I would have thought this was so that initially the target could be out of LOS, but you'd get a callback as soon as the LOS check in getAIMove realised that the target was actually in LOS. If targetInLOS was initially set to true, there'd be no calback after setting a new target, because the raycast code would think the target was already in sight.

EDIT: Umm... just realised you're not listed as a licensee. How do you have source code access?
#2
10/22/2009 (5:37 am)
1st: to asnwer the second question i am on a educational licence

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...
#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 again
That'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
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
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
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.