SuggestProjectileVelocity is behaving very peculiarly when DoNotTrace is not specified

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

1 Like

No, I hadn’t seen that; it looks like there may be a solution. :slight_smile:

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 :blush:

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 :smile:

I’m also not sure how OnlyTraceWhileAscending behaves…

Hello Daniel

  1. I don’t quite understand what this parameter ESuggestProjVelocityTraceOption::DoNotTrace is doing in function SuggestProjectileVelocity() ? and what is difference between ::DoNotTrace and ::TraceFullPath ?

  2. 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 ?

Sum up cordinates

It traces the path of the line trace for any collisions

  1. 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 ??

  2. 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?

  3. 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

  1. 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?

  2. 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 ?

  3. 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?

  1. Test it and find out
  2. 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 );
}
  1. 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.

Privacy & Terms