Well, greetings everyone.
I’m working on a personal project. I got pretty nice building skills, but uh, I need to script too,
I managed to make a door, that slides up, firstly very slowly but gains speed while moving.
Anyways, I fear that this script will make the game lag.
Will it create lag, and is there another way to script it ?
This won’t lag, but you should use Heartbeat or RenderStepped in RunService for consistency.
I have understood no word. But thanks, I’ll make researchs on it.
local door = workspace:WaitForChild("Door")
local c0 = door.CFrame
local prog = 0
local dist = 4.729
local deb = true
function onClicked()
if deb then
deb=false
local dir = prog==0
if dir then
local con;con=game:GetService("RunService").Heartbeat:Connect(function(dt)
prog=prog+dt
if prog>=1 then
prog=1
door.CFrame = c0+CFrame.new(0,prog*dist,0)
deb=true; con:Disconnect()
else
door.CFrame = c0+CFrame.new(0,prog*dist,0)
end
end)
else
local con;con=game:GetService("RunService").Heartbeat:Connect(function(dt)
prog=prog-dt
if prog<=0 then
prog=0
door.CFrame = c0+CFrame.new(0,prog*dist,0)
deb=true; con:Disconnect()
else
door.CFrame = c0+CFrame.new(0,prog*dist,0)
end
end)
end
end
end
This might work, not tested.
An explanation of what I mean:
wait() yields the current script for a short amount of time that can vary in case of lag. Your script also sets the door at regular position offsets, meaning that it will move fast without lag, slowly with it.
Heartbeat/RenderStepped/Stepped are events which you can bind a function to fire per-frame. One of the parameters it gives is called “step” a time difference between the current and last frame; in other words, dividing 1 with it will give you the current frame rate. By knowing this time difference, you can sync your door to the lag, making larger offsets if the frame rate is lower to compensate.
Every connection, when the :Connect method is used, returns a userdata object which you can cancel the connection with by calling its:Disconnect() method. I used it to cancel the door’s movement when it reached its target.
There is also a debounce value (deb) which blocks interaction until the current movement is over. It can be removed to allow reversing midway through, but it’s much harder.
Heartbeat fires after each frame, meaning that it’s perfect for complex physics simulations, while RenderStepped fires before each render frame, which might cause lag if the function takes too long.
Thanks, also, the script don’t works.
Probably because onClicked isn’t connected to anything. You need to add the same last line as in your code.
I don’t favor the use of using RunService, but TweenService is the best method for me to animate the doors. Such doors can be found under my profile’s creation tab(specifically nameless).
Example:
local TweenService = game:GetService("TweenService")
local Door = workspace.Door
local debounce = false
local doorInfo = TweenInfo.new(3, Enum.EasingStyle.Linear, Enum.EasingDirection.InOut) -- wow you can select time, easing and stuff!
local doorOpen = false
local goalCFrame = Door.CFrame * CFrame.new(5,0,0) -- offset from door
local originalCFrame = Door.CFrame
local function onClicked()
if debounce then return end
debounce = true
local doorTween = TweenService:Create(Door, doorInfo, {CFrame = doorOpen and doorCFrame or goalCFrame})
doorTween:Play()
doorTween.Completed:Connect(function()
debounce = false
doorOpen = not doorOpen
end)
end
Make sure you hook the function to the button by using:
button.ClickDetector.MouseClick:Connect(onClicked) or similar.
There is a thing to consider while using TweenService. It’s that it is inapt for anything execution time sensitive. Just setting a tween up requires you to access 5 tables and run 2 functions. Then you need to run another 2 functions to start the tween together with a table. And finally, you need to access the userdata and use another function to bind another function to an event.
Meanwhile, when using Heartbeat, you can serialize multiple of these, easily creating a single script that can handle hundreds of doors without much lag.
What do you mean here? Creating tweens is not an expensive operation.
Not sure where you get these numbers from. Correct me if I’m missing something.
Creating a tween requires:
That’s one table and two functions, not 5 tables and 4 functions. Both functions are not expensive and are ran in the backend.
Is there some kind of bias here or a misunderstanding of how to apply the service correctly? We’re comparing running something fully in Lua to interfacing with the backend (CPP, which is quicker). You can still create a single script, serialise and reap the same benefits of the aforementioned solution with TweenService.
:GetService(“TweenService”) -Methods are functions. Even with the recent changes they still stay functions and there is a small overhead when calling them.
TweenInfo -A global table.
.new() -A simple function.
:Create() -Another method.
:Play() -Another method
doorTween -A userdata, need to get the value from a table.
:Connect() -Another method, as well as the function connected to it.
I’m not saying that this isn’t efficient. In fact, TweenService is one of the best features that ever existed. But in cases where multiple objects can share the same values and the time is critical (per-frame updates), it is much better to use Heartbeat, granted you know how to efficiently perform that.
Also, Lua is fast as hell on its own, not to mention all the upgrades to the interpreter the Roblox team made. So the functions being run on the C++ side are only faster because they get to access data in a more direct way.
The “overhead” is negligible. Tweens are still viable in time critical situations. There’s no point in reinventing the wheel when an API is already provided for you.
Just don’t tween on the server. Tween on the client and you’ll get buttery smooth animations as expected.