If I set tracing to full trace, all of the AI tanks have the call fail. For the player tank it works sometimes, and not others, and when it works it sometimes suggests firing straight up into the air.
Have you read the solution from Benâs answerhub thread?
https://answers.unrealengine.com/questions/435995/suggestprojectilevelocity-behaving-badly.html
No, I hadnât seen that; it looks like there may be a solution.
It seems that âOnlyTraceWhileAscendingâ avoids the endpoint-in-ground problem; but not the straight-up problem.
Is there anything wrong with DoNotTrace?
Well, it wonât detect if there is an obstacle in the way.The straight-up problem seems to be the case when you are aiming at yourself, it which case straight up seems a reasonable solution.
In LineTraceSingleByChannel, instead of an empty FCollisionParams have this instead
FCollisionQueryParams CollisionParams;
CollisionParams.AddIgnoredActor(GetControlledPawn());
And what does your scene look like when you go to Visibility Collision instead of lit, do you see your tanks?
Not sure what your reply means. I can see the tanks with Visibility, but the turrets and barrels are in a different colour.
Whatâs a bit disturbing is that I can also see cameras following the other tanks (I had thought they were glitches in the landscape).
Sorry I should probably have provided more context and code, in the TankPlayerController for the line trace add the following commented out lines
//FCollisionQueryParams CollisionParams;
//CollisionParams.AddIgnoredActor(GetPawn());
GetWorld()->LineTraceSingleByChannel(
HitResult,
StartLocation,
EndLocation,
ECollisionChannel::ECC_Camera
//,CollisionParams
)
Seeing the camera is what it should be like unless of course you mean whilst playing. Though Iâll have to look into why you arenât getting results without donottrace. Do you have your project on github? And Iâll take a look at it tomorrow.
I think we have a complete solution then. I am using âGetHitResultAtScreenPositionâ but that takes the same FCollisionQueryParams argument so we can avoid shooting at ourselves. That together with Danielâs solution for aiming below the ground should the other problem and all is good.
Technically one should add a (small) multiple of the normal at the hit point and not just âupâ as up could actually put us deeper into the ground.
My project is on Bitbucket and uses mecurial. The URL is https://Rabid_Cow@bitbucket.org/Rabid_Cow/04_tankbattlex though I donât know if that will allow access. I really donât know what Iâm doing here
I notice that you used GetControlledPawn whereas Ben used GetPawn. What is the difference?
Sorry itâs old code and deprecated, GetPawn() is correct.
Had that same problem. Using donottrace solved it for me. Iâm not sure I would want to trace anyway in this instance. I feel that if you trigger that fire button, an explosion should happen. Toobad if that explosion is right in my nose
Iâm also not sure how OnlyTraceWhileAscending behavesâŚ
Hello Daniel
-
I donât quite understand what this parameter ESuggestProjVelocityTraceOption::DoNotTrace is doing in function SuggestProjectileVelocity() ? and what is difference between ::DoNotTrace and ::TraceFullPath ?
-
SuggestProjectileVelocity() function returns out parameter FVector OutLaunchVelocity; which is Unit Vector and equal 1. but if we sum up X,Y,Z coordinates itâs not 1. WHY ?
It traces the path of the line trace for any collisions
-
this parameter is something like we used in BuildingEscape project in LineTraceSingleByObjectType() function, is not it?
but ::TraceFullPath is strange with it SuggestProjectileVelocity() perceive only player Tank ?? -
from the SuggestProjectileVelocity() function Ben delete 3 default parameters and they were middle parameters which follow ESuggestProjVelocityTraceOption parameter. how itâs work?
how can I omit second parameter but give function third parameter?
-
why we need auto AimDirection = OutLaunchVelocity.GetSafeNormal(); this line why we need Unit Vector ? because we can directly convert FVector to FRotator
I get the answer about Second question from the chat. itâs only lucky incident ::DoNotTrace = false
Donât understand your question
-
from SuggestProjectileVelocity() we get Out parameter FVector OutLaunchVelocity than we convert it Unit Vector
auto AimDirection = OutLaunchVelocity.GetSafeNormal(); and we need it to make FRotator for Barrel,
auto AimsRotator = AimDirection.Rotation();
but we can directly convert FVector to FRotator
auto AimDirection = OutLaunchVelocity.Rotator() like this and is there any difference to write this code without Unit Vector? -
in order to get difference between AimsRotator and Barrel currentRotator Ben subtract one to another and FRotator - FRotator is the same proces as FVector - FVecotr ?
-
I have one question about pre-processing. Ben said that #include in header file slow down compilation process because there we have cut and past whole code in .cpp file during the pre-processing. forward declaration improve time compilation as Ben said but in this case we have #include in .cpp file instead of header files and by this way we have not cut and past code in .cpp file?
- Test it and find out
- Yes, just a member-wise
-
FORCEINLINE FVector FVector::operator-(const FVector& V) const
{
return FVector(X - V.X, Y - V.Y, Z - V.Z);
}
FORCEINLINE FRotator FRotator::operator-(const FRotator& R) const
{
return FRotator( Pitch-R.Pitch, Yaw-R.Yaw, Roll-R.Roll );
}
- Yes, but any cpp that includes the header also has to include that. If TankAimingComponent.h includes SomeBigHeader.h then any file that needs to include TankAimingComponent.h will also include SomeBigHeader.h regardless of wether or not it actually needs it.