RBXScriptSignal:Wait() should be changed to include an argument

[Xan_TheDragon (Xan)]

I don’t know the general appeal for a feature like this, so this is a shot in the dark. Bear with me.

I think the :Wait() method of RBXScriptSignals ( i.e. part.Touched:Wait()) should accept a number argument that defines the maximum wait time until it just gives up and returns nil.

An example of when to use this:
There’s a part in a game where the player has to run and eventually make it to some goal area. There’s an invisible wall that has no collisions, and it listens to a touch event. If the player makes it to this part, they are safe, but if they don’t make it there in 5 seconds, they die.

The code to create this solution with my idea here would be:

--assume there's stored character variable, Character
local Part = SafePart.Touched:Wait(5)
if not Part then
Character:BreakJoints()
end

Simple enough. Feedback?

[Partixel]

I would definitely use it, have to work around with spawns and loops atm.

[Merely]

When this was suggested previously I wrote a function that does what you are asking.

Timeout argument for Event:Wait()

Fairly straightforward to code. local RbxUtility = LoadLibrary("RbxUtility") local function waitUntilTimeout(event, timeout) local signal = RbxUtility.CreateSignal() local conn = nil conn = event:Connect(function(...) conn:Disconnect() signal:fire(...) end) delay(timeout, function() if (conn ~= nil) then conn:Disconnect() conn = nil signal:fire(nil) end end) return signal:wait() end -- Example us…

[GuestCapone]

I would also like to wait for a specific return as well…

[buildthomas]

Use the search feature to search for similar threads:

Timeout argument for Event:Wait()

So there’s this issue I’ve ran into a few times by now; I regularly write code which waits for a ‘response’. Often times the response is given by my framework’s font- or back-end so a response it pretty much always guaranteed to be given. Sometimes however the response is given by a player. Players can be really unexpected sometimes and might not give a response at all which could complicate some stuff. Let’s say for example that I’m making a dialog system. Some parts of the dialog allow you to…

Add timeout parameter for Event:Wait()

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

See discussion on those pages.

This suggestion won’t work generically for all events: in case an event returns no arguments there is no way to distinguish between a timeout or an event actually being fired with just this suggestion. So I wouldn’t approve of this addition simply because there’d be exceptions to the rule that aren’t properly handled.

The workaround linked by Merely above seems elegant enough, and you can modify that to properly distinguish between a timeout or actual event.

PS: this is typically a client feature, it doesn’t apply to just Studio