T3D 1.1 beta 3 - AiPlayer Offset Scale Relative To Own Bounds And Not Space Time Continuum - LOGGED - RESOLVED
by Steve Acaster · in Torque 3D Professional · 11/29/2010 (8:30 pm) · 9 replies
T3D 1.1 b3
Using:
win7 32bit
Target:
AIplayer, SetAimObject, SetAimLocation, probably all distance based measurements relating to Ai and boundingbox size updates of poses.
Issue:
When using the updated bounding box of the extra poses (crouch, prone, etc) the Space Time Continuum warps, meaning that the offset becomes relative to the Aimer's updated bounding box rather than World Units.
Repeat:
Get some Ai, sort them out some crouch/prone poses/updates, get them to aim at each other. Use debugdraw to see where their aim is going, it's pretty that way.
Suggest:
Technically, I suppose that this isn't a bug as it does appear to follow Einstein's theory of relativity - but only if you swap speed/gravity for boundingbox displacement ... not sure what Einstein said about boundingboxes ...
It certainly did't behave in the way which I expected it to, though, hence posted.
Knowing is half the battle ... and the other half is blowing stuff up with cool explosions ...
[edit]
And just to be annoying ... very occaissionally it works as you'd expect ... but only on individual Ai, not all together ... hmmm ... networking issue perhaps? he says ... guessing wildly ...
[double edit]
seems to change to normal if I bring up the editor and switch to free cam mode
[EDIT] 11th August 2011 - appears fixed in 1.1 Final
Using:
win7 32bit
Target:
AIplayer, SetAimObject, SetAimLocation, probably all distance based measurements relating to Ai and boundingbox size updates of poses.
Issue:
When using the updated bounding box of the extra poses (crouch, prone, etc) the Space Time Continuum warps, meaning that the offset becomes relative to the Aimer's updated bounding box rather than World Units.
//Ai1 aims at Ai2's head, both are standing. Ai1.setAimObject(Ai2, "0 0 1.8"); //1.8 world units up to hit Ai2 in the boomheadshot //Ai1 aims at Ai2's head, Ai1 standing, Ai2 prone. Ai1.setAimObject(Ai2, "0 0 0.4"); //0.4 world units up to hit Ai2 in the boomheadshot //all good here but ... //Ai1 aims at Ai2's head, Ai1 is prone, Ai2 standing. Ai1.setAimObject(Ai2, "0 0 3.0"); //has to aim as though space has distorted to his own prone boundingbox size, //rather than a standard world unit - so aim offset is now 3 "relative" units
Repeat:
Get some Ai, sort them out some crouch/prone poses/updates, get them to aim at each other. Use debugdraw to see where their aim is going, it's pretty that way.
Suggest:
Technically, I suppose that this isn't a bug as it does appear to follow Einstein's theory of relativity - but only if you swap speed/gravity for boundingbox displacement ... not sure what Einstein said about boundingboxes ...
It certainly did't behave in the way which I expected it to, though, hence posted.
Knowing is half the battle ... and the other half is blowing stuff up with cool explosions ...
[edit]
And just to be annoying ... very occaissionally it works as you'd expect ... but only on individual Ai, not all together ... hmmm ... networking issue perhaps? he says ... guessing wildly ...
[double edit]
seems to change to normal if I bring up the editor and switch to free cam mode
[EDIT] 11th August 2011 - appears fixed in 1.1 Final
About the author
One Bloke ... In His Bedroom ... Making Indie Games ...
#2
01/07/2011 (11:31 pm)
Logged as THREED-1307.
#3
Using setAimObject without offset to aim at the target's position (feet).
Top: Standing all is well
Middle: Crouched, issue becomes apparent
Bottom: Prone, issue very apparent
01/10/2011 (7:46 pm)
Whilst I've rolled back some other bugs I found in B3, I've had no idea where to look in the code for this ...Using setAimObject without offset to aim at the target's position (feet).
Top: Standing all is well
Middle: Crouched, issue becomes apparent
Bottom: Prone, issue very apparent
#4
aiplayer.h
edit;
no wait, that's clearly gibberish isn't it - it doesn't explain the occaisional Ai that spawns and targets using correct world space units ...
needs more tea
01/22/2011 (7:34 am)
Actually, I just thought, (one cup of tea ... slightly hazy) could the issue be because I'm using a ConsoleMethod and not an engine define ...bool AIPlayer::getAIMove(Move *movePtr)
//....
// Replicate the trigger state into the move so that
// triggers can be controlled from scripts.
for( int i = 0; i < MaxTriggerKeys; i++ )
movePtr->trigger[i] = getImageTriggerState(i);
//yorks in start
switch (mPose)
{
case StandPose:
movePtr->trigger[3] = false;
movePtr->trigger[4] = false;
break;
case CrouchPose:
movePtr->trigger[3] = true;
movePtr->trigger[4] = false;
break;
case PronePose:
movePtr->trigger[3] = false;
movePtr->trigger[4] = true;
break;
}
//yorks in end
return true;
}
//yorks
void AIPlayer::changePose(S32 poseNumber)
{
Pose poseAnimation = StandPose;
if(poseNumber == 1)
{
poseAnimation = CrouchPose;
}
else if(poseNumber == 2)
{
poseAnimation = PronePose;
}
setPose(poseAnimation);
}
//yorksConsoleMethod( AIPlayer, setPose, void, 3, 3, "()"
"(int pose) StandPose=0,CrouchPose=1,PronePose=2")
{
object->changePose(dAtoi(argv[2]));
}aiplayer.h
void changePose(S32 poseNumber);//yorks
edit;
no wait, that's clearly gibberish isn't it - it doesn't explain the occaisional Ai that spawns and targets using correct world space units ...
needs more tea
#5
Steve,
Somehow I get the impression that there might be an issue with GetEyeTransform() which is also used in AIPlayer.cpp when detecting LOS or something like that.
I am having strange situations where I am certain that I am pointing at an object (with getControlCameraTransform()), but detecting it with an approach over getEyeTransform I don't find a bl***y thing.
Right now I haven't got time to dig deeper, but it is one issue I need to resolve.
01/30/2011 (5:25 am)
edit: Forget this. complete nonsense!!!Steve,
Somehow I get the impression that there might be an issue with GetEyeTransform() which is also used in AIPlayer.cpp when detecting LOS or something like that.
I am having strange situations where I am certain that I am pointing at an object (with getControlCameraTransform()), but detecting it with an approach over getEyeTransform I don't find a bl***y thing.
Right now I haven't got time to dig deeper, but it is one issue I need to resolve.
#6
Steve,try to remove these lines from getEyeTransform(),but I doubt this could be your bug.
const Point3F& scale = getScale();
dp[3] = sp[3] * scale.x;
dp[7] = sp[7] * scale.y;
dp[11] = sp[11] * scale.z;
01/30/2011 (8:55 am)
getEyeTransform() is used as a start location,you guys have a problem with the aim location (box position + Z offset).Steve,try to remove these lines from getEyeTransform(),but I doubt this could be your bug.
const Point3F& scale = getScale();
dp[3] = sp[3] * scale.x;
dp[7] = sp[7] * scale.y;
dp[11] = sp[11] * scale.z;
#7
Whilst that does sort out the Ai's prone aiming, it has a terrible effect on the player's aiming and causes weapon pushback against all bounding boxes of any object.
I did previously look for differences in code between B2 (no problem) and B3 (problem) but couldn't see any changes in player/aiplayer that would cause such an issue.
01/30/2011 (9:22 am)
Ivan,Whilst that does sort out the Ai's prone aiming, it has a terrible effect on the player's aiming and causes weapon pushback against all bounding boxes of any object.
I did previously look for differences in code between B2 (no problem) and B3 (problem) but couldn't see any changes in player/aiplayer that would cause such an issue.
#8
I'm running through a backlog of bugs. Do you know if this is still an issue in the latest release?
08/10/2011 (2:25 pm)
Steve,I'm running through a backlog of bugs. Do you know if this is still an issue in the latest release?
#9
And all seems to work fine with Soldier's stock crouch and aiming. I'll mark this thread as RESOLVED.
08/10/2011 (6:05 pm)
Just tried a fresh install of Final with only the required code changes above plus what is needed to have the eyeNode Transforms update with the animations in player.cpp ...void Player::getEyeTransform(MatrixF* mat)
{
// Eye transform in world space. We only use the eye position
// from the animation and supply our own rotation.
MatrixF pmat,xmat,zmat;
if(!isGhost()) // Add this line yorks get eyenode pos to update
mShapeInstance->animate(); // and this line yorks see above
xmat.set(EulerF(mHead.x, 0.0f, 0.0f));
//...And all seems to work fine with Soldier's stock crouch and aiming. I'll mark this thread as RESOLVED.
Associate Steve Acaster
[YorkshireRifles.com]