Reducing momentum of projectile?

I have a projectile from the FirstPersonShooter (C++) template and I want it to go fast, however this makes my projectile have an absurd momentum which makes all the objects it hits fly off like crazy. I tried reducing the mass scale of the blueprint (both in the spherecomponent and the static mesh component) but this has no effect.

What should I do?

You are useing Projectile Movment Component? You can’t find anything useful there?

Nothing about mass.

but do you use Projectile Movment Component?

Yes, I use the projectile movement component

Hello ,

What type of settings are using for Initial Speed, Max Speed, Bounciness and anything else that could be affecting the momentum? We’ll need a frame of reference to base this off of to get an idea for what kind of problem you’re running into.

We haven’t heard from you in a while, . Are you still having problems reducing the momentum of your projectiles or have you found a solution? If so, please share it here for other users or if you still need assistance, please let me know. In the meantime, I’ll be marking this question as resolved for tracking purposes.

InitialSpeed = MaxSpeed = 20000.0f; bShouldBounce = false; So I guess bounciness is whatever the default value is.

To be clear, you want to have the projectile move at extremely fast speeds but not have the momentum to move objects that it collides with?

No I just don’t want it to affect the objects it hits as much as it does (lower momentum)

The only thing I could think of to do there would be a sort of workaround. I would suggest not actually simulating physics on the object that is going to be hit immediately. Instead, have it begin simulating physics OnHit and then apply a force that is considerably smaller than the projectile’s momentum in the direction of the projectile’s forward vector, maybe. There may be other ways to do this but I cannot think of another way off the top of my head at the moment.

@
I am dealing with a very similar issue and your solution intrigues me and I hope you might be able to clarify.

Are you suggesting that the object to be hit should be frozen in place before the projectile hits it and then physics simulation is turned on after that? Because that sounds a sub-optimal (it doesn’t even handle the common situation of 2 projectiles hitting the same object in quick succession).

Or are you suggesting that there is some way to stop a an object from exerting force on an object it hits at the time the OnComponentHit() delegate is called? That sounds like a great solution, but is it possible?

Hello cgd82

I’m actually not sure why I didn’t think about this before but when taking another look at the original question, you can fix his problem of too much momentum by simply changing one of the float values inside of the Projectile’s blueprint. As part of the calculation for the amount of impulse to add, it multiplies the current velocity by 100 by default. After changing the speed of the projectile to 20000 as the user did, any cubes that were shot would go flying. I changed the equation to only multiply the velocity by 10 and it’s moving the cube as much as it did initially.

Speaking of which, this also negates my previous post because that is almost exactly what these projectiles do. They never actually exert force on the object they hit by simple collision, they just add impulse as part of their collision response. This also explains why changing the mass wasn’t making a difference, since it was only going off the velocity.

Hey, I know this is a bit old, but I just found this question searching for a solution to the projectile impulse magnitude myself.

I wanted to ask: to change the scaling factor (100 → 10 in your example), do I need to modify the source code and recompile the component or am I supposed to have that scaling factor exposed somewhere from blueprints?

Thanks in advance.

Hello saldavonschwartz,

That depends on whether your FirstPersonProject is created for C++ or Blueprints. If it’s for blueprints you’ll see the OnHit functionality in the Event Graph of the blueprint and the variable you need to edit should be there. If it’s for C++, you’ll find the following line in FirstPersonProjectile.cpp:

OtherComp->AddImpulseAtLocation(GetVelocity() * 100.0f, GetActorLocation());

You can edit the 100.0f here to change the velocity multiplier that I mentioned.

Thanks for replying.

My project is a blank C++ project, no first person template or anything.

I’m new to Unreal (not to C++) and I got the impression so far that even if doing a C++ project, the engine seems to encourage building blueprints around core C++ classes. So for instance in this case, I found the projectile component inside the blueprint editor and went ahead and used it from there. So I guess I’m using the blueprint version?

If I right click on the component I have the option of opening up the header file for it, but I’m not sure if from the header I should be able to locate the cpp, (assuming the scaling factor is in the implementation), modify that and recompile (is this even possible if I am using UE from the Launcher as opposed to the source from GitHub?).

On the BP side, I don’t see any variable to edit on OnHit. This is what my blueprint looks like:

There are a few things to explain here. Seeing as you know C++, this should be a bit easier.

You can think of a blueprint like a child of your C++ class. When you make a blueprint based off of your ProjectNameProjectile class, it inherits everything it has from that class, just as a child class would. This also means that any updates you make to the C++ class will be applied to this blueprint when you make them. This is where Hot Reloading comes in.

UE4 links to Visual Studio to allow compiling changes to affect the editor on the fly instead of requiring you to restart the editor after each compile. When you compile, check your output log in the editor to ensure that Hot Reloading was successful and the blueprint should reflect any changes that you made.

As far as not seeing the variable goes, this is due to this event graph having nothing at all to do with the function in code that deals with the OnHit functionality.

In blueprints, you’re calling the K2_OnHit function (K2 is usually what blueprint nodes are prefaced with, it’s not that important, it’s just to explain that they’re different) which is completely separate from the OnHit function that the C++ class is overriding. Also, in this line:

OtherComp->AddImpulseAtLocation(GetVelocity() * 100.0f, GetActorLocation());

the 100.0f is being hardcoded and is not being stored in a variable. This means you would never see this in blueprints even if you wanted to. The easiest way to do this in blueprint while also using the code function would be to create a int UPROPERTY with the specifier EditAnywhere and BlueprintReadWrite in the code, initialize it to 100.0f in the constructor, replace the 100.0f with that int, and then you’ll be able to edit it in the blueprint and change how that function reacts.

If you don’t know much about how C++ and blueprints interact, I suggest this tutorial. Hope this helps.

I think the issue is that we are talking about separate classes?

My concept of projectile is essentially an actor with a mesh and its collider, plus this blueprint component ProjectileMovement which handles its movement.

In other words, I don’t have as of now any ‘projectile’ class per se, neither in C++ nor in BP land.

So you are saying that there is a projectile class in Unreal? I might want to create a new project from the FPS template then, since that class might be in that template. In the meantime, I did look into the source for the component I am using in the graph I linked (ProjectileMovementComponent.h/cpp) but there is nothing explicitly imparting an impulse. I think this class just sets the velocity on the rigidbody component and handles a few ‘projectile’ ish things but otherwise relies on the underlying collision mechanism.

Ok I just created a fp template based project and I see the projectile class and the calculation you were talking about. I’ll try to figure it out from there. Thanks!