That makes sense. The most common use for the cross-script method is when writing modules or when you need to fire a signal from a different script, or make a new connection from a different script. Once again, the most common case for this is for modules. You may come across this in the future. Also, that being said, even if you do not want to use the extra functions, there is nothing stopping you from just not using them. They function differently from Quenty’s, and with the benchmarks, it works pretty fast, so you can still use this, even if you do not want to use the extra functions.
1 Like
Yes, this is more modular and less “tacky”, also this more really replicates the behavior of custom events, which arguably are already similar to BindableEvents. Also, these are meant more for connecting code to a certain thing that may happen or occur, such as the pre-existing RenderStepped or Changed. Also, really, a BindableEvent is just an instance that holds an event, so it really is no different from an event itself.
2 Likes
Nice resource, seems useful. As far as I have tested it, it seems to work like advertised. Though, I don’t really see the point of the WaitFor function, but apart from that, nice work.
2 Likes
I think I used this in BadgeService3 and didn’t even realize? The way you do connections is the same I did manually a while ago.
You save a UUID and stuff and fire all functions, that’s also what I used to do a while back.
I might make my own signal API.
By the way, on one of the functions it seems as if there’s a variable not defined or something, “signal”, not sure. It was underlined when I looked at the code.
1 Like
This disconnects everything right? (And “garbage collects” it? Deleting everything and setting everything to nil, etc.) Currently I just made sure by looping through the connections and disconnecing them, then destroying all my connectors.
1 Like
Yes, it removes them completely, all trace of them
3 Likes
Thanks for sharing. BindableEvents are pretty limited when it comes to passing custom objects, so this is an easy solution! 
2 Likes
Just a suggestion, usually signal:Wait() returns the arguments that were fired as well, you may want to consider adding that feature.
1 Like
Has this been rectified? I will not use this module unless signal:Wait() actually returns the fired arguments.
1 Like
I am not sure, but you should be using the following module instead:
This one is made by me as well with various improvements
1 Like
You should add :disconnect() to the signal object.
What are you talking about? The new or old signal class?
Also are you talking about a way to destroy signals, you can use :Destroy() method.
If you are talking about a way to disconnect a connection, that is already included.
1 Like
Care to explain this?
I simply provided two answers for the two possible questions you asked without any extra words or any thing that accuses you of anything. How is that “going Karen on you.”
Honestly ridiculous.
3 Likes
Hi, i just improved this Signal module with new things.
New things:
- Added Queue System (with custom max_rate & max_workload)
- Thread Re-use System (Optimization)
- Minor Improvement
- Minor changes for better
Download here
Signal.lua (4.7 KB)
2 Likes
There’s an error output btw, ‘Failed to receive signal [example] - Server - signal:99’ I tried using the example if it would work but it still gives that error output. Even if the client-script and the server-script would interchange the codes but it still gives that error output.
i prefer u to just use other signal module over this. and its 2y ago post too.
damn, I can’t find the other signal module; It said it’s been deleted.
I used the Signal Class 2 that was made by the OP
why not give FastSignal a try, it works fine for me.
The roblox asset page for this and Github are 404 errors, am I the only one seeing this?