Is there any reasons why not use GoodSignal over this?
Is there a reason I should use your signals over the default signals? Are they more secure or faster?
Edit: nvm I misre
There are some on GitHub’s README file.
Update
7.1.5 → 7.1.6
Changelog
- Added
.Isto check if the object passed is a ScriptSignal - FastSignal is now on Wally as
lucasmzreal/fastsignal!
- Legacy versions of FastSignal were removed.
We now have Moonwave documentation! (It’s on testing, contributions are welcome)
Update - FastSignal is now stable! 
7.1.6 → 10.0.0
Changelog
This is the beginning of the stable era for FastSignal! This will mean that FastSignal will take less risks with messing / removing features from the library.
FastSignal was deemed stable enough for this release. Any bugs, weird behaviour, must be reported immediately.
- Fixed issue where
:DisconnectAllwouldn’t actually disconnect connections - Finished moonwave documentation / comments
- Immediate and Deferred now have a bigger separation, as they don’t any code that the other one needed to function properly
- Optimized
:DisconnectAllas well, so now it’s much faster - Adaptive now requires that Deferred and Immediate exist, it longer is a separate version, instead, it just requires the right one
- Adaptive’s Signal now contains
.Deferredand.Immediatewhich point to a specific mode
There are other smaller / forgotten changes.
It’s important that you update your copy of FastSignal. It fixes, as stated above, a typo, which could cause memory leak which was caused :Destroy / :DisconnectAll not disconnecting connections.
Note: Adaptive is going to be removed, Deferred is going to become the main version soon. This will happen when Deferred Events fully launch, and when it is no longer something you can choose anyway.
Note 2: FastSignal is now gonna follow SemVer for versioning.
Update
10.0.0 → 10.1.0
Users, please read:
So, this is embarrasing.
If you look into FastSignal’s changelogs, you would have noticed that :DisconnectAll was not actually disconnecting connections because of a typo. This happened again, with the same exact typo, except it’s not :DisconnectAll , it’s :Disconnect . While it wouldn’t fire those connections, the nodes were still there, so it was essentially leaking stuff. At least I caught it now.
Kinda embarrassing to say that right after saying FastSignal is stable, but yeah lol. This was probably a side effect of moving away from connections being one single reference, and me just not noticing it.
Anyway, yeah… Please update :) It’s pretty serious :/
Changelog
Other than that, there are some nice things 
-
FastSignal now has extremely specific, dedicated internal types, this will help debugging in the future, and also solves this issue on Studio, it causes some weird side-effects, but it doesn’t cause actual issues. This is really nice for intellisense.
-
Internal comparasions are now explicit.
I’m fairly certain this will be the last major update to FastSignal, I’m probably gonna have a silent update soon when Moonwave updates to simplify some things, but nothing too big, it’s just comment changes and so not worth announcing.
Hey, how did you make da event like
local sig = signal.new()
sig:Connect(function()
end)
I wanna know how you made the :Connect(function().
Update
10.1.0 → 10.2.1
Hello! Welcome back! It’s been some time! 
Changes
Nothing too big changed, this update is backwards compatible.
-
Roblox is now releasing a new RBXScriptSignal function which will be
:Once, FastSignal already implemented a similar function which was:ConnectOncewhich was then even added on sleitnick’s fork of GoodSignal. For API parity, it has been renamed to:Once, however you can still call:ConnectOnce. -
:Oncenow returnsScriptConnection. -
Fixed type issue where no intellisense worked on Roblox’s Script Editor.
-
Moonwave page finally updated.
Important notice
Because :Once hasn’t actually launched, we also don’t know exactly how it works.
Because of that, if :Once behaviour is not the same as the one we expect by how it works and how it is implemented here, then its current implementation here, will then be moved to :ConnectOnce and :Once will by replaced by a Lua implementation of how it works on Roblox.
Would like to add that it seems like FastSignal’s implementation seems to be just like Roblox’s :Once and so expect behaviour to be the same, if you think otherwise please bring it up over here (or well on GitHub, I’ll notice it faster there.)
What’s your reasoning for not re-using the same coroutine?
As far as I know the only “benefit” to doing so is all spawned threads being halted immediately / connections being disconnected when a script is removed if you use a new coroutine every time as with a simple task.spawn. In my experience almost everyone who wants to use a signal class wants to do it from a centralized system of modules where there are not script objects being created and destroyed anyways so that’s why I prefer the additional performance of reusing the coroutine.
Is that just in the name of matching the RBXScriptSignal behavior more closely or do you think that behavior is actually more desirable in practice?
I’m not sure why you thought I didn’t, but I do thread recycling on Immediate mode, not on Deferred because it doesn’t seem to be possible / doesn’t make sense. It also doesn’t happen in RBXScriptSignals on Deferred, but it does on Immediate.
The only thing that is different I believe from GoodSignal is how it recycles threads, I noticed the argument leak issue when first creating a coroutine before it was mencioned to you and I believe I updated my code to deal with that before, I’m not sure how you do it on GoodSignal since I haven’t really look at it for a while, but FastSignal should have some more cost when first firing and creating a thread to reuse than GoodSignal (at least when that was not patched) but should run the same way if no extra threads need to be created because a connection yielded for example.
This is one thing that I’ll never try to change for API parity, FastSignal tries to be as similar as it can, REASONABLY, to RBXScriptSignal behaviour, I wasn’t really aware of this, but things like disabling, destroying scripts is wrong enough to me to basically do anything for it to not matter to me, and I would never change my library for that much of a performance hit for the sake of something that is to me, deprecated ways of doing something.
Thread recycling has pretty big performance improvements even if its not just running the connection directly, which you can notice with a lot of connections running like you know, and while I usually am the person that would try to create completely unbiased libraries, disabling/enabling scripts is one of those things that even if a person isn’t using my library they will run into problems anyway, so I found that to honestly just not be important especially if it means losing the performance gains that Immediate has from thread recycling. (Which seems to be one of the biggest issues for people moving to Deferred when they relied on how Immediate performance logic worked)
I don’t plan on maintaining this anymore, not actively anymore anyway. I am out of the development scene at least here, and unfortunately do not have proper access to Roblox anymore due to Linux/Wine being blocked.
PRs are still welcome! I am able to check out Studio and stuff, just not Player. If anyone wants to implement the better typing introduced by another Signal class out there that I don’t remember the name then go for it. If anyone wants to fork and start their own, go for it, I might advertise it here.
Is there any way to get a connection from another script?
Let’s say
--First script
local Signal = Signal.new()
Signal:Wait()
--Second script
local Signal = Signal.get(--The signal from the previous script)
Signal:Fire()
Use module scripts.
LocalScript.luau
...
local ModuleWithSignal = require(path.to.module)
ModuleWIthSignal.Signal:Connect(function()
...
end)
...
ModuleScript.luau
...
local module = {}
module.Signal = Signal.new()
...
return module
Yeah I made my own “get” function in like 2 minutes after posting, now I feel kinda dumb for asking that but thank you!
1 Like
A few updates were launched. Generic types has a beta implementation…
I recommend also checking out LemonSignal.
They’ve implemented the double sided linked list also used in FastSignal for better disconnecting.
Important after the fact note: LemonSignal does not seem to support Deferred, therefore it isn’t as future-proof. Beware. Ideally you want to start moving your games to use Deferred behaviour and FastSignal can help you with that with its adapted mode.
1 Like
I have made a library that can not only replace fastsignal but also remotes: FastValue A replacement for the Value Instances
What script editor is that? It seems really useful… or is that the plugin you’re using?
That is Visual Studio Code, the most used external IDE on Roblox! VS Code is wildly popular among professional programmers outside Roblox, and if you pursue a programming (CS) career, it’s really helpful to be familiar with how the editor and Git works - definitely worth a shot!
If you’re interested, here’s a guide: