The wait function returns two values: the elapsed time and the time when it finished (which I believe is Workspace.DistributedGameTime). It’s not good practice to use it as a condition because it relies on wait always returning a number and it looks silly. while wait(1) do → while 1.0008942 do.
In Lua, anything not falsey (false or nil) is considered truthy (anything not false nor nil), which can include strings, numbers, tables, booleans (obv), etc. The use of while wait(x) do is misleading because it doesn’t guarantee it’s going to run the code how you want it to, and can create a small delay in your program if you use any waits in your code body - take the below solution for example.
while wait() do -- A small delay between the for code body
for i = 1, 20 do
prt.Transparency = i / 20
wait(.25)
end
end
And going back to what I said earlier - it looks silly. Imagine using it for a repeat loop-
repeat
print("I ran! Yay!")
until not wait(1) -- doesn't that just look silly?
Sometimes people rely on while wait(x) do due to their program crashing - but, imo, that just creates a mess, because if putting a wait(x) as the condition solved the issue, that means they either: A) didn’t put any sort of wait in the code body, or B) created an oversight/flaw in the program that they’re introducing a band-aid solution instead of fixing the problem itself.
It’s important to think critically and question whether you really need to use wait(X) in Y area of your code.
EDIT
My apologies - I misread the title/text as while true and wait(1). However, I believe most of what I wrote was relevant, except the wait(x) stuff (for the above obvious reason).
@ChickHenEn Kind of repeating what I shared earlier, in an easier-to-digest way to read, anything not falsey (false or nil) is truthy in Lua. Those values can be strings ("" or ‘’), numbers (1, 2, 3, …), tables ({ }), the true boolean, objects (Parts, Welds, Models, etc) and even functions to name some examples of truthy values.
As to the reason why the person whom wrote the tutorial used it, it was either the first thing that came to mind, they wanted to make a spin on it, or didn’t want to waste time and used 1 as a truthy condition. I don’t know why they used it, but those’re my theories as to why they might have.
For your second question, it’s keeping the part in the original position as it changes the orientation, probably as a fail-safe to prevent the part from offsetting from its original position. Instead of doing it like that, they could’ve opted to use CFrames instead, which would prevent said scenario.
while true do
wait()
part.CFrame = part.CFrame * CFrame.Angles(0, math.rad(5), 0) -- Adding 5 to the Y angle of the CFrame
end