You are basically trying to find the point of intercept, and to aim the projectile at that point of intercept, I assume.
To accomplish that you need to find that point of intercept. This is done using the formula Ip = Tp + Tv * t, where Ip is the position the intercept would occur, Tp is the Position of the target, Tv is the velocity of the target, and t is the time it would take for the projectile to reach the target.
However, t is unknown. To derive t, you can use the equation d = s * t and re-arrage it into t = d / s so d would be the distance between you and the target* and s would be the speed of the projectile. This would allow you to find the time taken for the projectile to reach a certain position, in this case, the position of intercept.
Now that you’ve found t, you can then plug it back into the initial equation: Ip = Tp + Tv * t where the position of intercept is the targets current position, plus the distance it will move in the time taken to reach the target.
(I am using a simplified equation that is not very reliable, I personally am also trying to solve this.)
Blockquote
Yes, you get exactly what I am saying. How do I calculate (in Robolox/Lua) the point of intercept assuming the velocity of both remain constant and gravity is not involved. I can then use this to set the Velocity of the projectile.
I know there is some big brain Robloxer out there that knows how to code/calculate this.
Yeah. Because through practice, you will notice that if you derive t from the position of the target at the time of launch, by the time the projectile reaches the target, t would have changed. So you would instead need to derive t from where the point of intercept would be, which you can’t find without t.
Looking online, this is a common mathematical problem. There is even formulas for this. I just have no clue how to translate this into Roblox + Lua code.
I’ve attempted to but without much success. The closest I’ve gotten was having a loop that constantly refines t based on the already-calculated point of intercept.
The problem, is that I cant update the projectile on the fly. I have to calculate it once and shoot cause I perform a remote event to client to have the projectile played on the client system as closely as what will be calculated server side.
I meant that the projectiles wernt guided, just that the script that dictates the direction the projectiles would travel in did the calculations. So the first few rounds would miss as t was incorrect, but as the loop ran, it would use the old value of t to get a value closer and closer to the correct value.
You can calculate the future position by treating it as a derivative, where h is your targets position and the future position being h.Position + (h.Velocity * seconds). From there we can create a virtual point in a sense from the value we got from h.Position + (h.Velocity * seconds) because velocity just describes, well velocity. It isnt absolute rather constantly updating. However like I said treating it as we did with h.Position + (h.Velocity * seconds) we can find its new position. From there I am sure you already know the rest based on what you said earlier of knowing how to calculate the velocity needed based on the direction and time.
Well I figure I can just calculate the trajectory of the TargetPart and just run a calculation for each position on that Trajectory to see if the projectile and and the TargetPart are close enough to each other at the same time.
Just feels like a lot of extra calculations for something that should be able to be calculated once with a formula.
(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)
