TweenService V2

[SteadyOn]

TweenService V2 is a module that helps with efficiently replicating tweens between the server and client. It allows for the server to run the tweens as though you are running them on the server, however, the tweens only run clientside. This reduces serverside lag as it’s not tweening the object itself, or continuously replicating the property to the client. Although the tweens only run clientside, the end result of the tween will be reflected server side once the tween has finished. I decided to make this module because of this post.

some tutorial video

TweenService V2 | Roblox Scripting Tutorial 📜📜 - YouTube

see it in action"

TweenService V2 - #10 by SteadyOn

You can get it here:

GitHub - Steadyon/TweenServiceV2: TweenService V2 works to help efficiently...

Or as a model file:
TweenServiceV2.2.rbxm (4.5 KB)

Documentation:

TweenServiceV2

TweenService V2 works to help efficiently replicate movement between server and client, using TweenService. It does this by running the tweens clientside, and then doing a single update server side.

Module:GetTweenObject(instance [Instance], TweenInfo [TweenInfo Object], PropertyTable [Table]) [Tween]

Parameters are exactly the same as TweenService:Create(), it returns a fake Tween object with Play,
Pause and Stop functions.

Tween:QueuePlay(Yield [Boolean, optional], Player [Player Object, optional])

Add the tween to a tween queue which will start playing the queue automatically immediately after the previous tween on that instance completes. Behaves exactly the same way as Tween:Play() once started, except the initial firing of the tween is managed on the client. For this reason, best practice is to fire this event as close to when you would like it to be played on the client to maintain alignment between tweens. If fired multiple times in a short time frame, this may result in clients becoming out of sync over time.

Tween:Play(Yield [Boolean, optional], Player [Player Object, optional])

Runs the tween. The player parameter will only play the tween for that specific player.
The Yield parameter specifies whether the function should yield until the tween has completed or not.

Tween:Stop(Player [Player Object, optional])

Stops the tween. The player parameter will only stop the tween for that specific player.

Tween:Pause(Player [Player Object, optional])

Pauses the tween. The player parameter will only pause the tween for that specific player.

Check this reply for a working example:

TweenService V2

ReplicatedTweening.rbxl (38.2 KB) This Module is very useful and makes Tween Replication a breeze. I noticed several people having issues making use of this module due to various errors. Here is a place file with a basic working example.

[Festivereinhard2 (Festivereinhard)]

Amazing! Will definitely use!

[cm_an]

This looks awesome, can’t wait to use it!

[SteadyOn]

Thankyou!

Be sure to tell me if you experience any bugs!

[RuizuKun_Dev (Kitsune)]

You should upload it as a model.

[acreol]

I imagine this wouldn’t be useful if the client needs extra data passed with the tween (e.g: if the client is told to tween an NPC’s health bar, then it is probably useful to also know the health as well - so it would just be better if the client updated the health bar on its own just as it does all other UI)
Also I don’t think its useful if the tweening is not triggered by a server side event, because the client could just start it itself (e.g: on game start perhaps the client should make something infinitely change color idk)

So I think that it’s only useful when the client needs to tween something without any auxiliary information and based on a server-sided (or other client) event
My question is when would this be the case?

[SteadyOn]

If you’re tweening a large number of objects from the server side, this module allows you to start, stop and pause that tween from the server without it affecting serverside performance. What this is essentially is clientside tweening controlled from the server. I’m not sure I completely get what you mean when you talk about extra information, you use this in exactly the same way as the normal TweenService.

This isn’t meant for tweens that would usually be done clientside as is your example, in those cases you should use the normal TweenService. An example of a use case for this is an automated car system, there are a large number of objects in the game that you don’t want the server to have to continuously keep track of, but the server needs to control them to make sure every player sees the same cars, therefore using this module you can run all the calculations clientside, whilst still being able to control it as though it was a server side tween.

[acreol]

I think if the input is dependent on one client (such as client collision with npc car) it would be useful for that client to be able to modify the npc car’s position before a response is received from the server
If you mean that the cars are soley aesthetic, then what (server-sided) event (that the client is unknowing of) will trigger their display?

[SteadyOn]

This is really for aesthetic things, as you said. It’s useful if you want every client to see the objects in the same position. For example in the car use case, which I am actually using it for, I want every player in the server to see the cars, in (roughly) the same position, and they also need to look the same. This could be done with firing the client where you want the car to be, positioning it there and tweening it too, this is just a simpler method.

In a game with any kind of moving object which is present on both the server and the client this is useful to prevent server side lag, and replication lag, caused by the frequency which TweenService changes properties when tweening from the server. It also allows you to have complete control over the objects despite the fact they are being moved clientside.

It’s also not really specifically designed to be used with only a specific player experiencing the tweening, I just added that in case people needed it. That parameter is optional.

[SteadyOn]

Here’s what I mean:

Client

Server

[FieryEvent]

The cars seems to have multiple sequential tweens to go through the tracks, so if the server controls them, wouldn’t they have a delay between the tweens?

[acreol]

I guess you could argue that it is useful if the initial state is passed (to keep all the clients synced) (because this would require client-server communication and thus not a direct translation of your tweening from server to client) but in your situation I don’t understand why the server needs to tell the clients explicitly how to tween the cars

[Rocky28447 (Rocky)]

So the server tells clients to tween something on their own, then after the tween time has elapsed, the server updates it to the final goal? Interesting. I feel like this should be the default behavior for tweens being run server side. Though I can see a few issues with this being default behavior, such as problems that may arise for players with slower connections.

[SteadyOn]

I thought the same as you but after doing this I realised there are a few issues with it, such as the fact that you can’t process touched events for collisions or use the objects properties to tween something server side. Im assuming default behaviour is like it is because it covers all use cases, if it didn’t tween server side some unexpected behaviour would be common.

[daireb]

EDIT: This part is completely wrong please disregard

This actually looks really useful, although I assumed that something like this was already in place in the normal TweenService. I think there is some sort of proper network replication going on at least (in the standard TweenService), because when you look at a tween on the client it runs smoothly, much better than the 0.1s network refresh rate. When you manually lerp the position on the server, even at 30/s, it still looks jerky on the client, so simple replication of the server’s movement isn’t likely.

/Incorrect

I’d be interested to see some benchmarks for the server performance vs normal tweenservice as well.

Can I also ask, how does it handle if the signals get mixed up, for example if someone briefly disconnects and then they get the event firing twice with different targets for the tween?
In a project I’m working on I am using TweenService a lot, and this module looks like a perfect fit for what I’m doing, but it depends on the performance and the reliability, including even brief network outages.

[sircfenner]

@daireb

0.1s network refresh rate.

Citation?

[daireb]

Ok upon actually looking, 0.1s is completely wrong. I’ve never actually looked into it and I think I just picked that number up from someone else’s post. Not sure if it’s outdated or just completely wrong, my mistake anyway.

I am still interested about the other points though.

[FieryEvent]

print(settings().Network.ReceiveRate) --> 60

[SteadyOn]

If someone disconnects for a second, it wont re-send the event call, since the tween is running clientside it would continue running. However, there isn’t anything in place to stop the client missing the tween request event while they are disconnected for that split second if that’s what you’re asking.

[daireb]

What I mean is are the tween signals time-stamped so if one signal is delayed and they arrive non-chronically it handles it as expected.