The only one I see is Initial Velocity in Local Space
I tried disabling it, nothing changes.
The correct tags for code btw are ‘Code’ not ‘php’. The php colouring makes the code incredibly hard to read on dark theme.
Also, you’re projectile fires backwards because ‘AimDir’ is incorrect. When calculating normals like this, think of it as ‘I want a direction from A > B’. It should be this.
AimDir = MyOwner->GetMesh()->GetSocketLocation((FName("WeaponSocket"))) - Hit.Location;
No. The other way around should be correct. You are at Position 20. You want to Position 100. 100 - 20 = 80. Normalize 80 and you get +1. You travel in the right direction. 20-100 = -80. Normalize that, you get -1. When you travel -1 from 20, you move away.
Edit: But yes, I meant “Initial Velocity in Local Space”. What happends in you just manually =* -1 the AimDir?
The direction goes towards the opposite way, but it’s still not what I want.
On the left you have the SHOOTER PERSPECTIVE, on the right you have **ANOTHER PLAYER’S PERSPECTIVE **
The crosshair is that red dot at the center.
The projectile flies way down sloping until it touches the ground.
EDIT: this happens if I multiply AimDir by -1 AFTER it has been Normalized(). If I do that before it gets Normalized(), then the result doesn’t change from the one described in the previous posts.
I’ll script something working for you in Blueprints that you can port to C++ then.
That feels like having the work done, though.
If I only knew what’s wrong with that!
Oh yeah right… lol I even had my aim code open in front of me when I wrote that. What I don’t understand is since this system is obviously identical to ShooterGame’s system, why not just follow what they do? I’d show mine, but the reticle follows the weapon in my design rather than the other way around. Either way it’s a relatively simple trignometry problem and like everything in games (!) can be sovled with triangles.
Your triangle points are the camera, the gun socket, and the end location of the bullet. To calculate the offset for the gun socket to hit the reticle, you need to know the ‘range’ at which the bullet will hit that reticle. That’s why you need the line trace. In your case you also want to make that trace distance infinite, or clamp the length to the maximum range of your weapon. At the moment, if your line trace doesn’t hit then you’re passing an uninitialized variable into ‘InitVelocity’, which you should never do.
Either way, from those three points you can figure out the angle between the line passing from the camera center to the impact location, and another line from the gun socket to the impact location, giving you the angle to fire the projectile at.
There will be cases where this doesn’t work though, such as if the bullet has to pass through geometry to ‘get to’ that reticle location. Most games handle this by having the bullet just come out the center of the screen, but tbh that’s a lame solution. Especially in Multiplayer. Gears of War 1 got away with it though, they just fired particles from the gun instead.
I think he follows the system except the divergence between Mesh1P and Mesh3P, which resolves the issue with the crosshair, because Mesh1P is used for physics and local animation and Mesh3P is only used for external clients animation (FX).
Cause I don’t do copy-paste without understanding what I’m doing. And since the ShooterGame uses some functions I don’t really understand the purpose, I’d like to be helped on some points… if possible in this thread.
Sometimes it’s better to just copy in paste and then debug through the process of, in this case, shooting instead of spending weeks trying to reinvent the wheel on you own 
What you are trying to do is called Gun harmonisation and Elevation (ballistics)
And actualy you want your convergence point be equal to hit point of world-projected view sight vector.
That’s what in third person template is done.
This is pretty straight forward. Get the screen’s middle and line trace to the target. Get that target point and use that for the weapon.
Thats what I suggested for like 10 posts
I’m following the ShooterGame system.
This is their code:
// If something was hit...
if (Impact.bBlockingHit)
{
**// What are they doing here?!?**
const FVector AdjustedDir = (Impact.ImpactPoint - Origin).GetSafeNormal();
bool bWeaponPenetration = false;
**// And here?!?**
const float DirectionDot = FVector::DotProduct(AdjustedDir, ShootDir);
if (DirectionDot < 0.0f)
{
// shooting backwards = weapon is penetrating
bWeaponPenetration = true;
}
else if (DirectionDot < 0.5f)
{
// check for weapon penetration if angle difference is big enough
// raycast along weapon mesh to check if there's blocking hit
FVector MuzzleStartTrace = Origin - GetMuzzleDirection() * 150.0f;
FVector MuzzleEndTrace = Origin;
FHitResult MuzzleImpact = WeaponTrace(MuzzleStartTrace, MuzzleEndTrace);
if (MuzzleImpact.bBlockingHit)
{
bWeaponPenetration = true;
}
}
if (bWeaponPenetration)
{
// spawn at crosshair position
Origin = Impact.ImpactPoint - ShootDir * 10.0f;
}
else
{
// adjust direction to hit
ShootDir = AdjustedDir;
}
}
There are a couple of things I’d like to really understand before accepting this premade code.
Does anyone of you knows something about this to tell me? If you have some time, even shortly if you want…
UP!
Basically, I need to understand what does the if-statement do (see above)
All the rest is fine, I got it.
gedamial,
I am just learning a lot of this. GetSafeNormal is getting the unit vector of the aim direction of the weapon.
I am finding the Udemy course, https://www.udemy.com/unrealcourse/learn/v4/overview, to be very helpful. It is very basic, geared to the absolute beginner in every way, but the battle tank section gets into some good foundation issues.
The comments tell you what it does. The DotProduct gives you the amount of one vector into the direction of another one. So, for example when your vehicle is drifting and you want to know the percentage of how much of the speed is forward and how much sideward, you just get DotProduct(Vel,WheelRight) and DotProduct(Vel,WheelForward). Same with the ShootDirection stuff. For two normalized Vectors (Rotations, converted to Vectors, are always normalized), the DotProduct always will be in the range of -1 to 1 (Because thats the definition of a normalized vector, all its components [XYZ] sum up to exactly 1), so 0.5 is the median direction vector.
You really should start debugging more with breakpoints and testing around, a lot of stuff really is self explaining
I’m having a similar issue.
When I shoot a line trace like this:
Start: CameraLocation
End: CameraLocation + CameraForwardVector*Range
the LineTrace hits perfectly the crosshair. But this doesn’t work in generall, as
at certain angles the projectile goes directly to the character and therefore the player shoots himself.
And it even doesn’t matter whether I’m doing it from the TP perspective or complete FP perspective.
I opened this thread
https://forums.unrealengine.com/deve…iming-problems
Perhaps someone can take a look at it.