What do you want to achieve? I want to have tweens be played clientside for all players. I saw how to do it in a tutorial once but have since forgotten. I want to do this because tweens played serverside (and then replicated to players) look really choppy and awful.
What is the issue? It appears that tweens created serverside do not replicate their TweenInfo (and TweenProperties) to clients as per the prints. Meaning, the tweens technically play, but since their values aren’t replicated, the tween doesn’t do anything.
What solutions have you tried so far? I have done much googling, looking around on these forums, and searching through my previously watched studio tutorials, to no avail. I have no idea how I can force the TweenInfo to replicate.
Attatched is a place file with this issue isolated, but I am also pasting the two scripts I use below.
Server script
local TweenService = game:GetService("TweenService")
task.wait(3)
local ReplicateTweenEvent = game.ReplicatedStorage.ReplicateTween
local part = workspace.Part
local goalPart = workspace.GoalPart
local tweenInfo = TweenInfo.new(
3,
Enum.EasingStyle.Linear,
Enum.EasingDirection.InOut,
-1,
false,
0
)
local tweenProperties = {
["Size"] = goalPart.Size,
}
local tween = TweenService:Create(part, tweenInfo, tweenProperties)
tween.Parent = part
print(tween.TweenInfo)
ReplicateTweenEvent:FireAllClients(tween)
Localscript
local TweenService = game:GetService("TweenService")
task.wait(3)
local ReplicateTweenEvent = game.ReplicatedStorage.ReplicateTween
ReplicateTweenEvent.OnClientEvent:Connect(function(tween)
tween:Play()
print("playing tween")
print(tween.TweenInfo)
end)
It’s not a very good practice to replicate stuff one tween at a time, but if you really need to do it this way, then I would recommend sending the tweens parameters rather than the tween object itself.
I would recommend sending the tweens parameters rather than the tween object itself.
So, have the server create its own tween, and then send the tween parameters over the remote event to the client, and have the client create yet another tween?
It’s not a very good practice to replicate stuff one tween at a time
For question one, you wouldn’t want to create the tween object at all. Instead you’d just fire the remote with the stuff you’d normally put into your tween object. (EX: Remote:FireAllClients(Inst, TweenInfo, Properties), though I am unsure if remote events handle the sending of TweenInfo’s at all)
As for question two, I usually create an effects remote where the server can fire to the clients the ID of an effect and some extra specifications.
So for example; I could have effect: RaiseWall, which is stored as its own function or module. When the server fires the remote with “RaiseWall” as its first parameter, and then the ID/Instance of the wall as the second parameter. The clients would call their RaiseWall(Wall) function, and the specific tweens would be made entirely there, rather than on the server.
though I am unsure if remote events handle the sending of TweenInfo’s at all
They do not, but an easy workaround is using a table. In the game I’m working on where I’m trying to implement this, that’s how the server gets the tween parameters in the first place. A client sends it to the server, server creates its tween, then server tells all clients to play the tween.
you wouldn’t want to create the tween object at all.
Why wouldn’t I? What if a player joins in the middle of a tween? The server has to stay updated on what things are getting tweened, lest you have people walking through closed doors on a newjoiner’s screen
If your using it to transition between object states (like a door opening/closing), then you can store the current state of the object as an attribute on it.
Then, when a player joins a game, simply loop through all objects that have states and set their positions to where they’re supposed to be.
You could also have the server set the position directly after so much time has passed, so that joining players will just see it pop into the right position and wont see people walking through it.
Oh, sure, but still, having the server also tween would achieve the same thing, and joiners would see the tween mid-progress (even if stuttery). Why wouldn’t I want to tween it serverside?