You should upload it as a model.
11 Likes
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?
2 Likes
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.
5 Likes
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?
1 Like
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.
3 Likes
Here’s what I mean:
Client
Server
4 Likes
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?
2 Likes
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
2 Likes
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.
2 Likes
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.
2 Likes
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.
2 Likes
Citation?
7 Likes
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.
2 Likes
print(settings().Network.ReceiveRate) --> 60
3 Likes
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.
1 Like
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.
1 Like
I know I feel pretty stupid lmao
1 Like
This kind of information doesn’t have an obvious location to search for on the wiki, sometimes you can only know of their existence by doing experiments on your own.
Not all parts replicate at the same rate, see ReplicationFocus. If you’d like to know the current rate of a part, you can use the ReceiveAge property, because you can get the time it was updated.
4 Likes
Just released an update on both the github and the file download - a new function called ‘QueuePlay’. Docs:
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.
Here it is in action (clientside), the red dots represent server side requests for queuing of a tween, and each tween is set to take 2 seconds. The dots build up as they are created once a second, while the tween takes 2.
The reason I added this is that if you want zero latency between tweens, this function provides that. Simply call it anywhere between when you start the first tween, and when you want the second tween to start, and it will start pending clientside, therefore when the first tween finishes, the second one instantly starts clientside without network lag.
5 Likes
This new function should fix that.
1 Like