The same thing was posted in December:
add a time parameter for event:Wait(), a thread will only wait on that event for that many seconds before continuing. will return true or false based on whether the event was called before the waiting limit was reached
local WasTouched = part.Touched:Wait(3) -- waits for .Touched up to 3 seconds
if WasTouched then
--part was touched before 3 seconds
else
--wait timed out before part was touched
end
I said this about the suggestion of making it return nil:
There are built-in events that don’t have parameters, so your suggestion doesn’t work there. So implementing that would mean you have pretty inconsistent behaviour based on what APIs you use, which doesn’t seem good. As you point out, you’d have to add a dummy parameter to BindableEvent as well if there are no arguments to begin with. Really hacky!
Throwing an error when timing out would (seem to) be the only option to both provide backwards compatibility for all cases and also implement your feature in a clean way.
Making it throw an error when it times out is much more consistent API-wise than having it return nil, because some events don’t return parameters. So I would suggest that over returning nil.
3 Likes