Client side sliding doors glitch

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.

1 Like

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.

Okay, then how am i supposed to move a model if i cant use get and set primarypartcframe?

Theres literally several ways that I dont need to explain (at least that much) and a lot to list so here are a few:

  1. Weld + Tweens
  2. Weld + CFrame
  3. Constraint (which btw replicates really smoothly)
  4. CFrame (while storing the original offsets of the parts)
1 Like

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

1 Like

idk how to do custom ones :frowning:

1 Like

Here try this

and use print() a lot to debug

Use RenderStepped:Wait() instead.

95% of the time it’s your fault and 5% of the time is Roblox Fault.

1 Like

Yeah but why renderstepped

Isn’t heartbeat a better option

1 Like

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

1 Like

RenderStepped

it only needs to move when the frame is rendered

any more and you’re wasting

since the player can’t see between frames

@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.

3 Likes

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 :slight_smile: :dog:)

1 Like

so in short

Weld parts inside model with Motor6D then use Tween on the RootPart?

Can you use SetPrimaryPartCFrame instead of Tweening the RootPart, it’s on the Client so I don’t think that you’ll notice the

because it has to happen many many times before it’s noticeable right?

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.

1 Like

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.

1 Like

Essentially.

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.

1 Like