So, as I established in this topic, its more beneficial to use Tweens on the client.
HOWEVER, I came to the realisation:
Ping could be an issue, after my testing it seems like doors would teleport around with high ping.
Also you CANT override tweens with the script I used since theres a wait() that automatically sets the properties on the server.
I realised that I wouldnt actually need to replicate any of the tweens to the server, but there is still one issue:
If a new player joins, they wont see the completed tween, since its client only.
So, would this be a good solution?
Server:
local object = workspace.Door.PrimaryPart
local info = {
5,
Enum.EasingStyle.Quad,
Enum.EasingDirection.InOut
}
local goals = {
CFrame = object.CFrame * CFrame.Angles(0,math.rad(80),0)
}
local remote = game.ReplicatedStorage.Events.TweenRemote:FireAllClients(info, goals, object)
game.Players.PlayerAdded:Connect(function(plr)
local newInfo = {0, Enum.EasingStyle.Linear, Enum.EasingDirection.InOut}
local remote = game.ReplicatedStorage.Events.TweenRemote:FireClient(newInfo, goals, object)
end)
Client:
game.ReplicatedStorage.TweenRemote.OnClientEvent:Connect(function(info, goals, obj)
local newInfo = TweenInfo.new(info[1], info[2], info[3])
local tween = TweenService:Create(obj, newInfo, goals)
tween:Play()
end)
Is it generally bad to have a lot of PlayerAdded functions on the server?
Thank you in advance
Unless it’s supposed to be a long movement, the best solution to newly joined players not being able to see the tween would be to fire the remote, then - on the server - move the part to the goal position after the (supposed) duration of the tween on the client has elapsed. It may result a bit inaccurate, but that’s how I’ve been scripting my doors for ages and they’ve always worked just fine.
…And you also cant do tween.Completed since the tween is actually on the client, and the property is set on the server
As far as I could see, you’re defining the Tween Information on the server through a table, therefore an easy workaround to Tween.Completed would be to simply get info[1] and wait that specific amount of time after firing the Remote (before setting the part to its goal position). You could have it so that it sets the properties (hoping that you were talking about, for example, someVariable = true or something along the lines of that, because otherwise I’ve misunderstood) AFTER moving the part on the server.
As stated by another user under your post about whether to handle Tweens on the client, hinges - although prone to physics glitches - are the best solution if you do not want to face these problems.
Forgive the way I’m thinking, it’s about midnight; my paragraph might be pointless for all I know. It’d be useful if you provided a snippet of your actual code.
Again, in this topic my code does what you said, wait(info[1]). But this still doesnt fix my main issue, if the tween gets overriden by another tween, the latest tween is going to play, but the properties are still going to be set by the server after the wait(info[1]) is finished.
I’ve just noticed that; as of right now, I don’t really know how to help you. Unless you’ll have already marked an answer, I’ll try to get back on this by tomorrow.
P.S. How come Tweens are able to override each other?, does your full code not feature some sort of debounce system in order to prevent that from happening? As far as my knowledge goes - as long as a second Tween is able to override the first one, there’s no supposed fix for this.
What I do is an an arbitrary wait on server, that takes into account BOTH tween duration and maximum normal lag (according to Roblox average lag is between 0.3 - 1.5). Then I make sure that after that time part position is updated on server:
wait(info[1] + 1.5)
object.CFrame = goal.CFrame
This way new players will see part as it should be at the end of the tween. At worst they will not see the tween, but unlikely they will notice, since they just joined. Warning! If tween is long/repeating, this may not be the best solution.