Countless times we are required to move objects without bothering about players standing in it’s way or the object hitting other bricks.
Such as when you: move a big ship, move a helicopter along a certain path, move heavy doors that shouldn’t stop moving just because a player stands inbetween. These are all times where a simple command like: part:MoveTo(endCF, 2) would come in handy.
Example:
local part = workspace.HeavyDoor
local endCF = part.CFrame + Vector3.new(0,-10,0)
part:MoveTo(endCF, 2)
This would move the heavy door down 10 studs over the timelapse of 2 seconds.
Currently these issues are all solved by welds, motors, simple for loops etc.
Most of the solutions create visible lag when moving the part.
With this function we could make scripting these doors much easier, the movement of the part would not lag like it does with all our current solutions.
Like if you think this is would be a great addition to roblox.
This would cause issues with rounding and the parts would slide into/away from each other unless roblox did something really inefficient. Have you considered local CFrame lerping? The “new” lerp() function is pretty neat.
It should be noted when this function runs the part behaives as an anchored part.
Local lerping is what I am doing now and it’s not very efficient nor does the code look very nice. Not to mention the unflexible nature of it. Changing the movement direction live would require remoteevents and such.
All just a big mess compared to a single funciton call.
Sounds like a personal thing because lerp is pretty efficient and very flexible
The method you provided is even less flexible than lerp.
What happens if I want to abort your function call? Or if another script moves the part unexpectedly mid call? These are things you can account for when lerping if needed
If you’re getting visible frame lagging when moving a part locally, consider lerping by a function of time instead of a static amount. Wait() returns the true amount of time yielded
Creating a localscript and pasting it brutally to 20 clients forcing them to lerp a brick along a predetermind path every frame-update is not more flexible than doing one call to MoveTo on the server.
If the brick is moved after the MoveTo has begun then it should stop the MoveTo. Or if another moveto has been called the previous moveto stops.
Do you have a different definition of what flexible means? A raw lerp function lets you design how the function should work and start/stop. You’re asking for a function that implements lerp in a very specific way. Thats the opposite of flexible.
You would still see latency with :MoveTo() because it takes time to send positional data to all of the clients unless you’re also asking for ROBLOX to automatically lerp the positional data on the clients.
I also noticed that you’re using a lot of buzzwords. Pasting them ‘brutally’ to 20 clients. All local things get replicated or “pasted” and none of that is ‘brutal’ We ‘force’ the client and server to do everything our code does.
Uhh that still doesn’t counter my point that you asking for a specific implementation of lerp is less flexible than just the raw implementation that you can add behaviors around.
I don’t think a function for this is really necessary. It would add bloat that already exists. With the lerp we already have implementing what you’re asking is fairly basic. If we are going to simplify things it should be something complicated.
This seems quite similar to another feature request in that both wants some interpolation of given properties.
I’ve put up a fairly simple solution, but it’d be better to have a TweenService handle that sort of stuff for us - I do agree with sparker22 and GollyGreg’s points on this issue. All the solution in the link above would solve is the actual interpolation - so you’d either tween on the server, or signal all clients to tween using a RemoteEvent. Problem is just that there’s no guarantee when the signal reaches the client, so everyone will see the part you’re tweening/interpolating at different times.
That tween stuff looks nice, but I think lerp would do fine in this case.
Simplest solution I can think of:
LocalScript that connected to a RemoteEvent that lerps incoming parts each frame.
RemoteEvent
Server Script that makes sure the part teleports to endCF after given time.
You also have to make sure the localscript (and the remoteevent) isn’t removed which it can easily be by hackers or by the game itself.
Isn’t that what interpolation is for? Making lag “invisible” so to speak?
No matter what you do, you will experience latency in some form. Thats the nature of online games. As GollyGreg explained the original lerp function gives you the ability to write your own behavior overriding lerps. As8D also provided an implementation. Overridable tweening isn’t that complicated.
Wouldn’t this also be an inherent nature of latency? When data is sent to or from a server, the time it takes to receive one is dependent on the distance away you are. The only way I think you could counter this is adapt the update rate to the player’s ping.
If you got a simpler solution than what I just provided then please share.
Because the one I provided is still VERY complicated and unreliable compared to a single function call.
Not to mention, if a player joins during a brick movement then he will not see it at all.
How is what you provided any less reliable compared to a single function call? Roblox has guaranteed reception for remote events, and if people are deleting remote events and scripts, there’s nothing preventing them from deleting bricks too. As far as animations not playing when people join? That’s easily fixable: just track where the objects are supposed to be, and when a client joins, it asks for the current positions.
Is this something you can make use of? It can handle players joining while the door changes state, and besides the lack of a cooldown (why did I even put in that debounce variable, I don’t even use it lol), it seems to be not so much work for a generic usage here.
Surely, having it integrated would be much more pleasing - but the actual code for moving the door is mere one-liners! (that is, 2 lines in the LocalScript inside StarterPlayerScripts)
So:
Wokspace
InteractableDoors
IsOpen (BoolValue) = defines if the door is open or closed
OpenOffset (NumberValue) = defines how far down the door part moves in studs
Clicker (part with ClickDetector to toggle on/off from the server)
Door (part to be moved!)
ReplicatedStorage
TweenUtility (module that tweens the door part)
StarterPlayer
StarterPlayerScripts
ClientDoors (small client script to handle all doors.)
I didn’t bother with RemoteEvents whatsoever, because who even notices the 2 seconds used for moving the door up/down? Your character is barely spawned during that time.
The stuff that’s inside the ModuleScript could/should really just be part of some TweenService method. Then it really is just those two lines to move the door, and the rest to handle the clicking detection and opening state.
