2 CFramed models same script, not synchronised

Help and Feedback Scripting Support
1

So, I’m developing a system where you click a button, it ungroups a model and moves all the children to a different model, and there is another model that also is CFramed up aswell, not the same model but the same script.

Imagine it like this:
LiftOperator (group)
Prop (group)
Props (group)

So there are 5 different groups inside of Props and when one gets ungrouped, it gets moved to prop.
The script then moves that prop into the correct position, and when another button is clicked, the Prop and the LiftOperator both go up, synchronised, perfectly.

However when it comes down, it is a different story as Prop moves faster and goes down further then the lift operator, and then going up again is also affected as it makes Prop go faster and higher then the LiftOperator.

I want to make it perfectly synchronised and in sync for going down, like it is when it is going up.

Here is a snippet of code, ‘items’ are both of the models children.

`

for i = 0,17,0.02 do 
    for _,v in pairs(_items) do 
        --v.CFrame = v.CFrame + Vector3.new((0.00*(-d)), 0.015*(d) ,0) 
        v.CFrame = v.CFrame + Vector3.new(0, 0.02*(d) ,0) 
    end

`

Sorry if that came badly formatted, I’m writing this post on mobile.

Here’s a gif of what’s happening when it’s going down:
https://gyazo.com/0a5aa545f1180ede10beb9a9a93f625f

I’m probably just being really dumb and not realising what is going on.

1 Like
2

I think it might have to do with tiny, unavoidable calculation errors adding up over time. Every time you add 0.02 to the coordinate, your computer tries its best to do that exactly. Unfortunately computers have very limited precision, and so it ends up adding 0.02000000000000001 or something like that instead.

You can’t avoid the tiny error, but you can avoid it adding up over time. Right now you solution looks a bit like

local y = 0
local goal = 17
local stepSize = 0.02
for _ = 0, goal, stepSize do
	y = y + stepSize
end

Eventually, the tiny error from adding 0.02 accumulates. Instead, consider this:

local start = 0
local goal = 17
local stepSize = 0.02
local y = start
for progress = 0, goal, stepSize do
	y = start + progress
end

It might look similar, but the important difference is “y = start + progress”. In the first example, the value of y always depended on the previous value of y. Since a tiny error is added every time, and it never gets “reset”, the error accumulates over time.

In the second example, consider “y = start + progress”. start is always the same, and might have a tiny bit of error depending on which value it has. Same with difference. But every time y is set to a new value, the old value gets thrown away, along with the error that had accumulated up to that point. That means the error doesn’t accumulate over time, and always stays below what is actually visible.

I hope this makes sense (and is correct :I ). Let me know if you need help actually using this in your specific example :slight_smile:

2 Likes
4

You should use :setprimarypartcframe and then use the loop

1 Like
5

You are not including what d is defined as. Correct your post and include the full code so that your problem can be diagnosed.

6

This is tested, and it works.

you can try doing both actions using heatbeat that fires every frame like , for example if you use a local script in StarterPlayerScripts you can do

in a local script, in StarterPlayerScripts :

local folder_containing_parts = workspace.Folder2
 
 local children = folder_containing_parts:GetChildren()
     for _,kid in pairs (children) do
	 if kid then 
		
    game:GetService("RunService").Heartbeat:connect(function(dt)
	
     kid.CFrame = kid.CFrame * CFrame.Angles(0, math.rad(1)*dt*60, 0)
end)

		
		
		
	end
end

**Adjust CFrame to your requirement, rest’s all good.