Hi, I have ran into a problem when trying to calculate velocity of a moving part without using roblox’s built in AssemblyVelocity, however when the calculation is run at more than 60 FPS it starts to act weirdly.
It is still not perfect because FPS can spike to 58 FPS or 61 FPS.
Here is the script that does the calculation:
local missile = script.Parent
local target = workspace.etget
local function getVelocity(before, after, delta)
local d = after - before
return d / delta
end
local msl_prev = target.Position
game:GetService("RunService").Stepped:Connect(function(_,deltaTime)
local msl_now = target.Position
print(getVelocity(msl_prev, msl_now, deltaTime))
msl_prev = msl_now
end)
Can I make it consistent across all FPS values? AssemblyVelocity is working almost perfectly, but I cannot use it because I am working with anchored parts.
Been a while since i dealt with movement myself, so i went to an old Godot project and saw that i multiplied by delta time, try multiplying instead of dividing.
I probably made it sound confusing, but yes I am planning to use this on anchored parts, but right now I am testing it on unanchored ones so I can compare AssemblyVelocity and my script.
Well then how are you gonna move the part then, that should narrow down your solution.
If you are computing the velocity of a part moved by linearvelocity , the linearvelocity solver updating the position and your computing need not be in sync, thus providing off values. Now for anchored parts you would be updating the position manually, that way you can guarantee that it would be in sync.
Your formula is correct, but I think the problem is some scheduler timing shenanigans.
I don’t know exactly, but I have a strong suspicion that both adaptive timestepping and too small wait times both contribute to the inconsistent timings in the scheduler. Sometimes a step occurs but a physics step hasn’t passed yet. You’d assume so but not when adaptive timestepping is enabled.
This is why your code outputs 0 velocity every couple of frames. A step has happened, but the part’s position hasn’t yet changed.
I think decreasing your timestep with higher framerates makes this effect worse and worse, although I think its related to something else, just adding on top of adaptive timestepping.
The solution is to use a timestep that is big enough to guarantee that this doesnt happen. I used a while loop with a 0.1 wait which was more than enough to counteract this, and it gave accurate results every time no matter my framerate. Its not a very satisfying answer but its what we have. You could also try forcing the thread to wait another step if it detects the part’s current position is the same as the previous. I also found 0.05 to be pretty accurate if you turn off adaptive timestepping.
Looks like I found what causes this and it is very odd. When I was experimenting with this I found out that in roblox studio server’s FPS and client’s FPS are the same. So I decided to test this in the actual roblox client and sure enough.
