[v.69] SimpleSignal | Very Simple & Silly Fast Script Signal

Alright the main post has some pretty simple docs now, glad broken spawn taught me how to format tables :slight_smile:

3 Likes

I can’t believe I’ve been missing out on such a cool markdown feature. How do I do those tables like you just added in the documentation?

3 Likes

It’s made like this:

| Column1 | Column2 | Column3 |
| --- | --- | --- |
| A | B | C|
| D | E| F |

This turns into this:

Column1 Column2 Column3
A B C
D E F
3 Likes

Package Version 43:

  • SimpleSignal is now distributed under a modified MIT license

  • Added error handling for event handlers, disconnecting all handlers if an error in one occurs

  • Removed the Connections field, opting to turn the entire RBXScriptSignal into what is essentially an array with a metatable

I’ve never heard of this? SimepleAnimate? SimpleComplete? What exactly would this primarily be used in/for? Is there some videos on youtube about it?

3 Likes

SimpleSignal is used in any usecase where you wanna have a signal, for example, in my module SimpleZone:

local zone = SimpleZone.new(...whateverparamsitdoesntmatterrn...)

zone:BindToHeartbeat()
zone.ItemEntered:Connect(function(item)
      print(item)
end)

ItemEntered is a Signal created by SimpleSignal, it’s just like the normal RBXScriptSignals roblox provides like game.DescendantAdded or BasePart.Touched, except you can completely customize it!

The difference with SimpleSignal is that it’s silly fast at firing events, most other modules take way too long to fire.
Also the fact that SimpleSignal is… well… simple. It’s only 162 lines + MIT license not including the Types module which is there purely for types

Any videos that teach you about stuff like GoodSignal (a module @stravant made) would teach you about SimpleSignal too, since both are the same thing in terms of function names and functionality

3 Likes

Ah interesting. Im surprised ive never heard of something like this. I didnt think there was a thing to modify the speeds of firing events. Do you know at all how this preforms on larger scale projects? I forgot where I saw the documentation but there was something similar to this but in larger scales its affects actually fell off like in an exponential graph.

2 Likes

There isn’t, the speed is an optimization :V

Well… SimpleZone is somewhat of a large-scale project, so is LessSimpleZone, infact the creator of Warp themselves uses the latter one!

Also, the time complexity for SimpleSignal:Fire() is veeery close to O(1) (in fact it might actually be O(1)) since it’s only looping through an array, and coroutine.resume() itself is O(1).

So for a large amount of connections, you can be assured SimpleSignal will still be quite performant :slight_smile:

4 Likes

Yeah Il’l give this one a shot and play around with it.

2 Likes

Yeah by the sounds of it I’ll do the same

Perfect thank you learning lots of new things!

1 Like

I have found an issue. Memory leaks. :scream:

So in Once and Wait connections, you’re calling :Disconnect(), which closes the thread.
If you didn’t catch it already, you’re trying to close the thread from the thread, which isn’t possible.
It actually errors, but you don’t get the output since you use coroutine.resume instead of task.spawn.

This is actually a flaw in the thread storage system, which is problematic because i just released an update including it in my signal module. :frowning:

I’ll see if you have a solution for this. I haven’t been able to find one. I might have to unrelease the update for Signal+.

2 Likes

Ahh that makes sense, I can think of a solution right now. However… I gotta sleep :frowning: I’ll see you tomorrow

1 Like

Package Version 53:

  • Fixed memory leak (thread not being closed) when calling RBXScriptConnection:Disconnect() (it also works properly now)

The issue was not :Disconnect(). It was Once and Wait.

I know, and Once and Wait uses :Disconnect(), so the new fix means they get cleaned up properly now

1 Like

You can’t just do a check. Sure, you’re avoiding an error, but the coroutine is still not being closed…

It is being closed; the coroutine returning means it is automatically turned into a dead state (see threadWorker), the closing is just when the coroutine isn’t doing anything aka is waiting for a signal, so you can just close it immediately

I see. I don’t think the method is worth it anymore. I won’t be using it, because you’re loosing a lot of speed many other places, and it wasn’t even near the 10x fire improvement which I first expected.

task.spawn is the true speed killer. But it’s really unavoidable. :frowning:

Yeah there is quite a bit of speed loss with Connect and a little with Disconnect, however not enough to notice since most of the time you’re only doing Connect once; imo fire times is much more important

Idk man I’m still getting around 10-12x fire improvements for my own benchmarks