Part not updating fast enough

Help and Feedback Scripting Support
#1

Im Trying to make a system for my vfx but a part is not updating fast enough

touching functions raycast and inboundboxmagintude

					runservice.Heartbeat:Connect(function()
						local params = RaycastParams.new()
						params.FilterType = Enum.RaycastFilterType.Exclude
						params.FilterDescendantsInstances = {character,clonepart}
						local velo = clonepart.AssemblyLinearVelocity
						local raycast = workspace:Raycast(clonepart.Position,velo,params)
						
						if raycast then
						--	clonepart:Destroy()
							clonepart.Anchored = true
							clonepart.Position = raycast.Position
						end
						end)
1 Like
#2

Fast enough for what??? It’s not clear from your post what you want help with

#3

Try using Render Stepped if its a local script instead of heartbeat as render step before every frame while heartbeat is after physics simulation after every frame.

runservice.RenderStepped:Connect(function()
	local params = RaycastParams.new()
	params.FilterType = Enum.RaycastFilterType.Exclude
	params.FilterDescendantsInstances = {character,clonepart}
	local velo = clonepart.AssemblyLinearVelocity
	local raycast = workspace:Raycast(clonepart.Position,velo,params)

	if raycast then
		--	clonepart:Destroy()
		clonepart.Anchored = true
		clonepart.Position = raycast.Position
	end
end)

Edit: Note this may cause performance issues if used incorrectly and this can only be used on local scripts, I don’t know if the script your running is a local script or not though.

1 Like
#4

I meant that anything psychical that i change will not update as fast as i would want it to be or is delayed

#5

Im doing it server sided and i tried changing it to stepped to see if it would work but it pretty much does the same thing

#6

Try moving some stuff out of the heartbeat that doesn’t need to be there, I believe this would speed everything up

local params = RaycastParams.new()
params.FilterType = Enum.RaycastFilterType.Exclude
params.FilterDescendantsInstances = {character,clonepart}
local velo = clonepart.AssemblyLinearVelocity

runservice.Heartbeat:Connect(function()
	local raycast = workspace:Raycast(clonepart.Position,velo,params)

	if raycast then
		--	clonepart:Destroy()
		clonepart.Anchored = true
		clonepart.Position = raycast.Position
	end
end)```
1 Like
#7

i cant move velo out and it wont really change much it may change things by a little but theres nothing stopping the execution so it wouldent really make a difference

1 Like
#8

What are you expecting to happen in your example? I read your code, and I kind of doubt that what it’s doing is what you actually want. Specifically these bits:

So what you’re doing here is on every Heartbeat (60 times per second on a healthy server), you do a raycast from the center of the ball (not the leading face), in the direction it is moving, and the raycast length is roughly how far it will go during the whole next second (not frame), because velocity is studs per second and you’re not multiplying by the Heartbeat timestep–the “dt” function parameter you see in most Heartbeat functions. If this raycast hits anything that matters (according to the params), the ball will be Anchored and set so that it’s center is at the hit position.

There are 3 problems I see with this:

  1. Raycasting ahead a full second is going to stop the ball as soon as it gets to a point where it would collide sometime over the next second. The end result is that this means the ball can appear to teleport up to 1 second’s worth of travel distance in a single frame, which is potentially a big visual jump.

  2. Anchored parts can overlap, even if collidable, and the overlap will not be resolved. Because of this, and because you’re not taking into account the radius of your ball, the expectation is that it will end up embedded halfway into whatever the raycast hits.

  3. Roblox physics is interpolated on the client. This means that if you anchor it from a Server script, at wherever it currently is on the server, you’ll still potentially see it still moving for a few frames until your client gets the Anchored property replicated from the server, which is why you see the ball bounce off the wall and then snap back to where the server anchored it. If your game is replicating a lot of part positions, or if a player has a particularly bad ping, the delay could be even longer.

The bad news is, that while you can fix issues #1 and #2, there’s no quick fix for #3. The only way to really make it look perfect is to do it client-side, and use the server’s final Anchored position as the authoritative one, which will then only make the ball glitch visually if the client and server raycasting somehow comes up with significantly different result.Position values; unlikely for a slow projectile like this, but increasingly more likely as things speed up.

2 Likes