It allows you to create events inherited from a structure that contains functions you will need throughout your core script of the game.
Three Points
It is adaptive, fastened, and familiar.
What you need to know
When is script interface which gives a developer an ease of mind from creating Bindable Events. The methods are based off of Roblox’s way of doing so.
Notice
The Roblox package currently cannot be retrieved due to Roblox’s issues on the backend currently. Obtain the library through GitHub. I will have to wait for tomorrow. In addition, this topic is quite rushed and the documentations are now available for you to understand and incorporate this into your project.
How to use?
Require the module (if not obvious enough)
local when = require(game:GetService("ReplicatedStorage").When)
Creating an event
local event = when.new()
Be comfortable
event:Connect(function(inp)
print(inp)
end)
Go as far as you’d like
Across the script or anywhere, as long as it gets in time and sends a signal at the perfect moment.
event:Fire("Hello World!")
Call out once
event:Once(function()
print("in a while")
end)
Disassemble it
event:Destroy()
Performance Testing
Performance Testing
Even though When isn’t built mainly for performance, this is for my curious people. These are the tests performed using os.clock to measure. If you’re looking for performance, which should you choose?
The sample code:
print("Hello World!")
Connections
First connection testing
Module
Delta Time (μs)
Order
Signal
0.6002374
3
When
0.90012327
1
Lemon
1.60001218
2
Second connection testing
Module
Delta Time (μs)
Order
Signal
0.6002374
1
When
1.49989501
2
Lemon
2.09966674
3
Third connection testing
Module
Delta Time (μs)
Order
Signal
0.69988891
3
When
1.40024349
1
Lemon
1.6996637
2
Mean connection
Ordered from least to most
Module
Delta Time (μs)
Signal
0.63345457
When
1.26675392
Lemon
1.79978087
Firing
First firing testing
Module
Delta Time (μs)
Order
Signal
106.899999
3
When
172.10003
1
Lemon
192.699954
2
Second firing testing
Module
Delta Time (μs)
Order
Signal
254.500192
1
When
167.599879
2
Lemon
185.200013
3
Third firing testing
Module
Delta Time (μs)
Order
Signal
227.000099
3
When
237.299595
1
Lemon
261.100009
2
Mean firing
Ordered from least to most
Module
Delta Time (μs)
Signal
196.13343
When
192.333168
Lemon
212.999992
I don’t know how When performed well compared to the other one, but I’m glad it did.
1 - What are the benefits of using this over a generic ScriptSignal module?
Almost all of the methods listed in the API cheat sheet are already available with resources like Signal - Sleitnick which is widely used, so I’d really like to know if there are any distinctive features to this.
(Taking back Q2 because of a misconception on my side)
I’ve heard of Signal, but never actually looked into it. I was looking into Discordia’s framework for making bots in Lua and wondered why Roblox does not have these convenient functionality such as being able to have a one-time connections.
I’ll check out Signal.
(Yes, this might be in the style of Signal but with more control)
After the previous question, I’ve checked out Signal. I’ll be honest, Signal offers almost-similar product. When is made for scripters like me who struggles to get comfortable with doing scripting in separate modulescripts and it offers functionality for reusability (such as rules which gates).
The preferred product is the script in GitHub.
Regarding naming issues, it’s just a reflection of “When” it happens. In the documentation, When will usually be capitalized. I don’t find it confusing, it just makes more sense.
There’s a bunch of other interpretations of RBXScriptSignals. With so many though, it kind of all comes down to speed, which I suppose isn’t the purpose of this project. That’s why I don’t really see any point in using this over other things. Sure you’re doing some unique things but in my opinion it is not enough. No offense.
No problem. It is still in perfecting phase. If you want this to be useful to you, you can suggest features that would help you out a lot that much of others doesn’t offer. It’d be nice if other replies actually give advices and feedback instead of personally questioning the existence.
I actually have a really good suggestion that you could implement, which are header arguments that are fired along with the arguments, terminate and respond for example. The respond function would be used for sort of like BindableFunctions, and the terminate one as just self:Disconnect() I use this a lot in my projects because of the versatility and convenience. This could be implemented like this:
Connecting to a response
someSignal:OnResponse(function()
... -- Only fired when respond() is called
end)
Responding
someSignal:Connect(function(respond, terminate, ...args)
respond() -- Fires the OnResponse connections of this particular event
end)
Termination
someSignal:Connect(function(respond, terminate, ...args)
terminate() -- Disconnects the event from the inside, no outside reference needed...
end)
Even though the respond function is basically a BindableFunction, I haven’t seen a single implementations of BindableFunctions in Signal modules. Another way you can do it is by basically just adding BindableFunctions, which should be pretty simple. Also the reason why I’m suggesting the respond approach is because having multiple different classes for the same purpose can be annoying.
i highly recommended LemonSignal because its way more faster than FastSignal and GoodSignal. but LemonSignal likely a bit unflexible here because where you cant defining a identifier to the signal event.
Not sure if I did the test and estimations incorrectly, but LemonSignal seems to be slower compared to Signal.
Aside from that, I did a simple performance testing for the general public that’s curious.
When is 29.6% faster than Lemon in connection.
When is just only about 2% faster than Signal in firing. (Clutching lmao)
I will add some features suggested by @CEO_OFTrolling while minimalizing unnecessary invasions into When’s Events…possibly extensions.
I think that’s exactly opposite, tbh. With so many implementations of a similar concept and when benchmarking differences are miniscule (even being 200% faster than something that takes a hair of a second is just a dressed-up micro-optimization), the only valuable distinguishing feature is API methods.
Once performance is at point, such that speeds across varying approaches are functionally the same, expanded (and purposeful) API methods and controls should be the priority.
I totally agree, and also personally prefer functionality over performance if the performance difference is negligible, but in this case there’s basically no functionality offered over others so that is why I’m comparing them with performance. But that makes me think, out of all those iterations, what can be expanded? Almost all of them have a complete and fully functional API. You technically don’t need any more functionality from any of them because they do their job.
Originally, When was made in praise by me for being compatible with Lua 5.1 within few changes. As I shift this products towards Roblox developers and adding extension, should it go further away from the goal but rather be useful for once?
point, such that speeds across varying approaches are functionally the same, expanded (and purposeful) API methods and controls should be the priority.