In that case physics is tied to the client, meaning you’d have to use a custom physics solution.
I’m not using the physics, i’m just moving the part with RenderStepped but looks like you are just replying randomly to the posts. Just go look into other posts if you cannot help 
Why not try using heartbeat? Might solve the issue?
I honestly have no idea what you are doing here, but I can pick up a few key ideas…
emissionNormal = scalar multiplier to final offset [otherwise im lost]
PhysicalAcceleration = a constant which should increase the final offset
alpha = [ absolutely no clue ] although it should dampen the offset; given by the name it could be within the range from 0 <= alpha <= 1
noise = The actual randomness to the final offset
heartbeatspeed = ?? honestly im just going to get rid of this as it makes absolutely no sense in this context
This is a lot of things to take into consideration, and still to this extent so many things are left to assumption?
Edit: To me it just looks like you are just throwing random values at the wall and seeing if something sticks
Yes there are definitely some missing critical information. Also, HeartbeatSpeed is likely the DeltaTime.
HeartbeatSpeed it’s the speed of the particle, you can downlaod the source from my custom particle system in this post and you will see the entire source
https://devforum.roblox.com/t/particlesplus-v0-11-make-awesome-visual-effects/1372660/7
I’m sending only a part from the code because this is the next update from my module.
That’s what I’m doing while fixing this issue as I have no idea about math operations to compensate the time between the RenderStepped event fire.
Less framerate = more time between RenderStepped update = the particle movement just goes into that direction until the next call of RenderStepped with a noise that compensates = makes the noise go crazy
High framerate = less time between RenderStepped update = the particle movement goes into that direction until the next RenderStepped updates = the time between updates it’s too small and barely makes an effect on the particle movement because of the amount of updates (like 200 fps)
So what are you trying to accomplish here? Are you trying to lower the speed at which the particles move around?
If the framerate it’s lower, I want to remove to compensate the lack between framerate update, if the framerate it’s high, I want to add to compensate the overload of event update
Are you using the delta time argument of RenderStepped?
I am using it to compensate the HeartbeatSpeed variable but as it’s a constant, I have no problems because does not generate randomly.
I asked a moderator to delete my free resource from the page, no more errors :D!
Listen… deltatime, the argument passed to you when you call the RunService loop is exactly what it says it is, its a value describing in SECONDS the amount of elapsed time between subsequent frames.
This is useful for updates that rely on movement on a per TIME basis, for example something like velocity. We know the equation for velocity to be (speed or distance) / TIME. So we can use delta-time in this scenario as it can represent a value for TIME…
-- Lets add some velocity to our part
speed = 10
proportion = deltaTime / 60 -- proportion is a percentage of 60, if it is 60 then we would update one speed increment
velocity = speed * proportion
position = position + velocity
Hopefully this cleared deltaTime up for you, and maybe you can use it more clearly now :-/
Bumping this topic as I found the solution, a better title would be “Movement alpha with High Framerates”.
Solution:
local Noise = (1 - 0.5 ^ deltaTime) * Multiplier
Basically it’s a framerate independent alpha, this post explains it better Frame rate independent lerp? - #18 by EmesOfficial
1 Like