local Player = game:GetService("Players").LocalPlayer
local Mouse = Player:GetMouse()
local helddown = false
Mouse.Button1Down:Connect(function()
helddown = true
while helddown do
task.wait(1)
print('held down')
end
end)
Mouse.Button1Up:Connect(function()
helddown = false
end)
Your logic isnt really optimized,
here’s a better version
local Holding = false
Mouse.Button1Down:Connect(function()
Holding = true
end)
Mouse.Button1Up:Connect(function()
Holding = false
end)
while true do
if Holding then
print("Holding")
end
task.wait()
end
it would be better to have the while loop inside the Button1Down function because the loop will end and never happen again. also you forgot to use any delay like task.wait() inside the while loop it will crash i think
It’s a good idea to avoid spawning and destroying loops as it becomes difficult to manage them. So Instead, you can simply create one loop kind of like what @capsori did here. Except with some small modifications.
local Player = game:GetService("Players").LocalPlayer
local Mouse = Player:GetMouse()
local Holding = false
Mouse.Button1Down:Connect(function()
Holding = true
end)
Mouse.Button1Up:Connect(function()
Holding = false
end)
while true do
if Holding then
print("Held down")
else
print("Not held down")
end
task.wait()
end
@urgentnotice had the correct solution. Your while loop will won’t work, because one, when the game starts the helddown bool will be false and it will skip right over the while loop due to the condition being false, and two, even it were true starting off, the loop would end once helddown equals false, and never run again.
Okay, this is better in the sense that now it will work with an identical functionality as urgentnotice’s code. However, it will use more resources for the exact same result, because you’re running a while loop every frame with an if statement within. Since the condition will be false the vast majority of the time, running this while loop is marginally more expensive than just running the loop only while the button is being held down. If the button isn’t being held down, then we can automatically assume that the helddown variable should be equal to false.
I’ll concede on the functionality since you fixed that aspect, but it’s good to keep in mind performance as you scale your projects up.
You take the input to set a local flagged state of true or false. onpressed, on released respectivily.
You hook into your choice, render/heartbeat/stepped.
Within that setup if not pressed it just immediantly bounces out. IF pressed is true run your process.
Keep it lean simple easy yo understand. DONT USE while, unless you are somehow intentionally wanting to yeild thing, but I would suggest other means of doing this.
What’s more important than whether your code was performant or not, however, is the passion for code formatting you displayed. For without motivation for improving code, you wouldn’t be a successful programmer. You displayed it clearly: Though someone posted a solution, you figured the code could be reconfigured to be equally as efficient but with a cleaner look. Though the former was not true in this particular case, it may well be in the future. So keep up the good work; keep, as you already are, striving for readability and style, as we all ought to be!
lol did i make myself look bad, if so i didnt mean to
i always try to optimise my code as much as possible and am
actually experienced enough in coding in general lol
its just that i replied quickly without rlly checking what i wrote
Kind of. Having a while true do statement with an if statement within it is usually bad practice, as the “true” can often be replaced by a condition, and used in a function to save performance. Since while true do infinitely loops regardless of whether it’s needed in that moment, you should try to avoid it if unneeded(especially if the delay of the while loop is an empty task.wait instead of task.wait(0.1)).
A rare use-case of while true do would be a script that needs count server time, as it will be needed for the duration of server’s runtime. In this case the delay would be 1 second, which uses very little system resources.
The replies in this thread explain it better than I could: