Why door part is lags behind?

Help and Feedback Scripting Support
#1

Hello. I recently noticed in game that the same part of the door is lagging behind but it appear with chance 30%, i didn’t noticed this bug in studio when i tested my game

The door part moment:

image
image558×638 30.5 KB

The lagging behind door part moment:
image

Maybe because need use wait a second to activate door in next time or no?
And also it is the channel for this bugs like this?

#2

Can you show a video of it lagging vs not lagging, that would help a lot for a solution, and yes, scripting support is for support for script related things.

  • Code would be nice too.
2 Likes
#3

Lagging:

Not lagging:

The script is requires the module script, in it located tween model function but idk why this bug appears

#4

I suspect networkownership being a problem here, try setting the network ownership to the server by doing :SetNetworkOwner(nil) to the parts being affected by the tween.

The reason why I suspect this is when the player was near the door it started to lag, but when it seems there is no players near it, it works smoothly. (Due to network ownership being unaffected)

Although this is a guess, try to implement it and see if that fixes the problem.

#5

I recomend opening the doors on the client rather then the server.
You could do this by firing a remote event to all clients that tells them to open the door.

2 Likes
#6

can you please show the code? I think its a tweenService error

#7

this is TweenService module:

module = {}

function module:Create(object,info,value)
	local success,msg = pcall(function()
		local TweenService = game:GetService("TweenService")

		local Tween = TweenService:Create(object,info,value)
		Tween:Play()
	end)
	if not success then
		warn(msg)
	end
end
function module:Model(object,info,cframe)
	local success,msg = pcall(function()
		local TweenService = game:GetService("TweenService")
		local CFrameValue = Instance.new("CFrameValue")
		CFrameValue.Value = object:GetPrimaryPartCFrame()

		CFrameValue:GetPropertyChangedSignal("Value"):connect(function()
			if object~=nil then
				object:SetPrimaryPartCFrame(CFrameValue.Value)
			end
		end)

		local Tween = TweenService:Create(CFrameValue, info, {Value = cframe})
		Tween:Play()
		
		Tween.Completed:connect(function()
			if CFrameValue~=nil then
				CFrameValue:Destroy()
			end
		end)
	end)
	if not success then
		warn(msg)
	end
end
return module
#8

ok thanks, i will try to do this

1 Like
#9

No problem, feel free to ask any questions if you need any more help.

#10

This causes a few problems as doors will still appear closed on players that join in, unless you make a script that opens the door on new players that join.

I also believe network ownership plays a huge role in this “door lag issue”.

#11

This is a simple fix.
1: Player joins the game
2: Check if this door should be open
3: Tell the client to open the door.

And even if this was some how unachieveable, the door will eventually syncronise as the game plays.

#12

SetPrimaryPartCFrame is a deprecated function and actually the specific problem you’re facing was caused by its weird model tearing problem after making many iterations

I made a boilerplate system which you can add onto that uses the superseding PivotTo and tweens the model on the client. Supports checking if the doors are open for new players. If the model tweens weirdly just change the Frame’s Pivot

ClientDoor_Tween.rbxl (39.9 KB)

I will admit it’s still sort of a “hacky” solution, but I found it to be easier to manage than welding and if done properly has little to no performance impact

Assuming you mean the method of welding the parts together, NetworkOwnership only affects the assembly part, which in this case would be anchored and therefore wouldn’t have fluctuating ownership

1 Like