Node Bug: Predict Projectile Path - Inaccurate

[anonymous_user_bba64342]

Short Version: The velocity provided by the “Suggest Projectile Velocity” is functioning accurately. However, plugging that Velocity into the “Launch Velocity” input for the “Predict Projectile Path” node results in a path that doesn’t match. See pictures for proof.

Long Version: I’m setting up a method for AI turrets to shoot arcing projectiles at moving targets, so need to predict where the target should be when the arcing projectile would get there. To do so, I needed a launch velocity/angle that would make a projectile moving at a known speed hit the target, and to know how long the projectile will take to get there, which I can figure out from its speed and total path length.

So to start I used the “Suggest Projectile Velocity” node, plugging in the start position, target position, and projectile speed, leaving gravity alone and selecting Favor High Arc.

Then I move onto the “Predict Projectile Path” node, using the same start position and plugging the Toss Velocity from the “Suggest Projectile Velocity” node into Launch Velocity.

Finally I use the Toss Veloctiy to get a pitch rotation for the launcher and spawn a bullet with the preset speed used to calculate everything.

In theory, the debug line of the “Suggest Projectile Velocity” should match up with the debug points created by the “Predict Projectile Path” and the actual path the bullet travels. Unfortunately, only two of these happen, with the “Predict Projectile Path” node’s visuals being inaccurate.

The reason I need these to match (other than the fact that logically they should) is because I’m setting up predictive aiming for moving targets. I need to know the total distance the projectile travels along its arc so I can calculate how long it takes to get there, and then predict where the target will likely be after that amount of time, adjust the aim, and then fire.

I can find the total distance of the arc adding the distances between the projected points along the path, and everything else will fall into place easily, but only if the predicted path is accurate. And right now it’s not, which makes the whole process fall apart.

[anonymous_user_bba64342]

Note that in the above image, the target is stationary. Not moving. This is the result of the two nodes’ debugs using the same start/end/velocity information for a static target, which theoretically should match up.

I’m hoping I’m just doing something wrong, since these nodes have been out since 4.13, and I haven’t seen mention of this issue. I really need this to work for this game project, and while there are work-arounds (such as making the projectiles home-in, or accepting the miss and giving it splash damage) but those feel rather cheap when it should be entirely possible to gauge how long an arcing projectile will be in the air.

[TJ_V]

Hi Last_Mavrik,

Try upping the Sim Frequency value on the Predict Projectile Path node. You are using a value of 2 and the default value is 30 because that is the recommended size of each sub-step to get an accurate prediction. It will be more heavy this way but that is expected with more accuracy.

Let me know if that helps at all.

[anonymous_user_bba64342]

I unfortunately don’t know the trigonometry involved in calculating the distance along the arc, but I would very much like to. I’ve been looking for it for a few days now actually, even trying to look at the node’s code in C++ and only finding a long list of references to other engine functions to try to further dig through.

In the meantime, I’m adjusting the settings as you suggested and experimenting with possible solutions and workarounds. I’ll respond with additional things I find out shortly, but from the initial attempt with the fix you suggested I can say that while increasing the sim frequency does bring the predicted projectile path close to the actual path, the amount of processing cost increase seriously isn’t worth it, at least for constant predictive aiming.

Given a high-arcing projectile with a speed of 2500 aimed at a single target only 4500 units away, the size of the projectile’s arc in a realistic scale setting needs the Max Sim Time to be at least 5.1 or it doesn’t simulate to the end of the arc. Setting the sim frequency to 30 with a single turret running this on tic has a solid 50 fps drop, and I’ve got a really good computer.

This of course leads me to believe that this isn’t meant to be run on tic, like most blueprint, which is entirely understandable. To call this function sparsely (once per shot) and not update the turret’s orientation per frame will require additional calculations, such as factoring in the turret’s rotation speed, how long it will take the turret to get from it’s current rotation to the desired rotation, and adding that into the lead time as well.

Ultimately though, even with a sim frequency of 30 the predicted arc is closer, but still not in line with the actual projectiles path like the Suggest Projectile Velocity node’s debug line is. If there was a way to get its length, this would be much easier. Regardless I’m continuing to experiment with it, and if there’s a C++ answer to this, please let me know.

[anonymous_user_bba64342]

Ran out of characters, but I’ll respond with anything else I figure out as I experiment today. Maybe there’s a way to account for the inaccuracy if it’s fairly constant with distance, and adjust for it.

[TJ_V]

Since the Suggest/Predict Projectile Path nodes are working as intended and this has become more about a code solution to your specific feature, I’m going to move this over to the C++ section in hopes to get you the code solution you require.

I’ll run this by our coders as well but it will probably take a member of the community that has the time and knowledge to dig into this. I would also recommend making a post on the C++ Gameplay section of the Forums as well.