Im confused by your explanation alone. I hate to be that guy but could you put that in code given the example code I gave above?
Assume it is, yes.
(I scribbled this in like 30 seconds sorry for the quality)
If we calculate the time it’d take from the time of launch, and calculate where P would be, then by the time P is at the correct point of intercept, the distance would have changed as seen in the pic.
local target = workspace.Part
local bv = target.BodyVelocity
local function calcFuturePosition(seconds)
return target.Position + (bv * seconds)
end
@AntiSocial_Taco I suppose on a micro scale? I guess that can be a problem if the target is really far away. Perhaps make a tick() count busy wait queue which waits the alloted delta for our body mover (1 second)
Hm possible, but would run into a similar issue.
No because we have accounted for the second delay.
Will the direction of the projectile always be the same, as depicted in the drawing or will we need to calculate that too?
That is what I was saying, if the velocity changes within intervals I suppose he could get the average of them
For the moment assume it is like a bullet, without bullet drop however.
I’m wondering if its possible to work backwards from an unknown solution, I’ll try figuring it out and get back to you if it does.
Thats what I was thinking, given a objects future position how could we calculate it. perhaps an inverse function of the f(t)??
and the t0 * () is a + not a *
Yeah I’ll probably try working backwards for this.
Honestly Im thinking the easiest solution is to calculate the trajectory of the target part and then calculate each point on that trajectory (based on radius of projectile) and the arrival time of the projectile to that point and the arrival time of the target part to that point. Whichever point has arrival times for both objects most nearly equal to each other is our (close enough) future position.
I would know how to do this, it just feels like there should be a formulaic way of doing this.
Perhaps
velocity = (-startPositionOfTarget + endPositionOfTarget)/delta time * speed
I would have no clue how to translate that into code.
I would know how to do what I just suggested.
Im gonna ask again cause I never got an answer…
Are we calculating both the speed and direction of the projectile, or just the speed, or direction by themselves?
We know the speed of the projectile (as illustrated in my code example in original post) but given speed calculate the direction. Based on the future position of the target parts velocity and the time it would take for the projectile to get there. So that they intersect,
Alright thanks for the clarification, knowing this would be the difference between a nearly impossible calculation, and a “relatively” easy one
Yea that’s what I was going for, I figured it’s calculable without having to do some iterative point for point calculation to determine when both will arrive at each point on the trajectory of the target part.
I’ll see if I can come up with something, no promises though 
1 Like
Ha I’ll take whatever you can give me.