I am trying to increase performance by making the sliding doors in my game only move on client. The first time they work fine, but once they open a second time this happens:
The scanner is supposed to move all the way down, and back up. Then the doors should open.
This is the server code to open the doors:
local Door1 = workspace.Deur1
local Door2 = workspace.Deur2
game.ReplicatedStorage.MoveModels:FireAllClients(Door1,Vector3.new(0.1,0,0),40)
game.ReplicatedStorage.MoveModels:FireAllClients(Door2,Vector3.new(-0.1,0,0),40)
wait(1)
Door1:SetPrimaryPartCFrame(CFrame.new(-177.126, 91.24, -1201.281))
Door2:SetPrimaryPartCFrame(CFrame.new(-192.126, 91.24, -1201.281))
And this is the client code:
game.ReplicatedStorage.MoveModels.OnClientEvent:Connect(function(model,increment,count)
local a = 0
local oldpos = model:GetPrimaryPartCFrame()
loop = game:GetService("RunService").RenderStepped:connect(function()
if a < count then
a = a+1
model:SetPrimaryPartCFrame(CFrame.new(increment + model.PrimaryPart.Position))
else
loop:Disconnect()
end
end)
model:SetPrimaryPartCFrame(oldpos)
a = 0
end)
The weird thing is that it does not error or anything. I also checked if there was maybe some if not debounce then code where the debounce would not return to false or something, but that was not the reason as to why its behaving like this.
You can send arrays with remote events. Also, do not use get and set primary part cframe. These should only be used if you are moving a model one time instead of consistently.
You also do not need to use a connection like that because you can just do it in the event itself.
The problem with 3 of your solutions is that they all require the part to be unanchored. However, in a certain segment of my game, explosions happen everywhere randomly, which can displace stuff. And I do not know what exactly you mean with the 4th option…?
It is not my fault you are using default roblox explosions instead of custom ones and also the 4th one requires u 2 store and set part cframes as local offsets from the primary part as opposed to computing them per movement like SetPrimaryPartCFrame does
What’s the downside for using SetPrimaryPartCFrame to move a model like a door? I use it frequently and it appears to be a good working solution that works great on the client? Especially when used with TweenService
@RuizuKun_Dev Please do not use that. I should probably make an informal note on the original post stating that the provided method is not reliable at all. For best performance with that kind of stuff, you want to weld a series of unanchored parts to an anchored root, then tween that root. Weld with Motor6D.
After using SetPrimaryPartCFrame enough times, you will begin to notice your model tear apart due to floating point errors.
again the offsets are computed per movement call.
Doubles are floating point which means calculations arent entirely accurate. Eventually snce ur never using the original offset values the numbers start to get less and less similar (ninjad by above )
Heartbeat would be better in this scenario, as it adjusts to the users framerate iirc, whole RenderStepped fires every 1/60th of a second, thus being “wasteful” if the user doesn’t have a constant 60 FPS.
Um no it fires every time a frame is drawn… the event is literally called RENDER STEP and why would cameras and stuff run on RENDER STEP if it moves the camera when not needed, please do not make incorrect assumptions. Not only does the wiki state this but it also says “around” meaning it isnt always 60 FPS.
It’s still better to not use SetPrimaryPartCFrame for these kinds of things. Server or client, your model will still tear and be subject to float point errors. It may take several times before you can see giant cracks, but the tearing begins at the first set. It’s better not to have tears at all, you don’t know how many times the client will run the function.
)