So this only works in player/local scripts?
No, it also works well in server scripts.
But you said it disconnects when the player leaves. So I can’t use this in an NPC, cause the NPC can’t “leave”.
You can make a custom group for that.
For example:
connectionManager:Connect("OnCharacterLoaded_NPC_" .. tostring(NpcObject.Name), NpcObject.CharacterLoaded, function(character)
warn("Character loaded", character)
end)
I also use my RBXConnectionManager for an NPC system too.
Then manual disconnect it?
At that point I would just make a list then on script.destroying
go through that list and disconnect all.
I do find the sorting pretty nice though
I’ll just have to use it first to see how I feel about it.
You can always manually disconnect events, or a whole group with events in it.
This feature that automatically disconnects connections that are no longer needed (when a player leaves) will run automatically if it can. It will still work when it never sees a player or object leaving.
RBXConnectionManager is useful for cases where an NPC system has many duties and can benefit from seperating different groups of connections.
An example snippet of how I use it in my NPC Manager class for playing voicelines:
self.__connection_manager:Connect("OnVoiceLineEnded", random_voiceline.Ended, function()
if self._character then
self.__connection_manager:Disconnect("OnVoiceLineEnded")
local delay_time = math.random(voicelines_interval_min, voicelines_interval_max)
task.delay(delay_time, function()
self:_InitVoiceLines()
end)
end
end)
This helps because you don’t need to manually store a large amount of RBXScriptConnections, but this process is handled more controlled and managed.
ooh, a new connections module!! I’m very big on preventing memory leaks, so I’ll definitely try using this in one my recent projects, I’ll let u know how it goes.
Amazing! Thanks for trying out. Preventing memory leaks is absolutely where we aim for!
I will also be releasing an update that slightly improves memory footprint of the module itself (that can still very slightly increase when you use a lot of RBXConnectionManager instances → but not anymore with the new small update).
Edit: I just released it on GitHub and Wally (v0.1.3).
Also feel free to share your ideas for future additions.
Personally, I’m thinking about a feature that allows you to connect an RBXScriptSignal, when it’s fired to automatically disconnect all events in the group. I already added this feature to the GitHub Development Branch
Just use my module man; this is an overcomplicated module for literally nothing.
Here’s mine:
--15.10.2024 | 1Xayd1
local ConnectionManager = {}
ConnectionManager.__index = ConnectionManager
function ConnectionManager.new()
local self = setmetatable({}, ConnectionManager)
self.connections = {}
self.playerConnections = {}
return self
end
function ConnectionManager:addConnection(event, callback)
local connection = event:Connect(callback)
table.insert(self.connections, connection)
end
function ConnectionManager:addPlayerConnection(player, connection)
self.playerConnections[player] = connection
end
function ConnectionManager:cleanupPlayerConnections(player)
local connection = self.playerConnections[player]
if connection then
connection:Disconnect()
self.playerConnections[player] = nil
end
end
function ConnectionManager:disconnectAll()
for _, connection in ipairs(self.connections) do
connection:Disconnect()
end
self.connections = {}
for player in pairs(self.playerConnections) do
self:cleanupPlayerConnections(player)
end
end
return ConnectionManager
Hey there!
Thanks for sharing your module too! I can see where you’re coming from with the simplicity, and it’s great for quick setups. However, my RBXConnectionManager aims to handle more complex use cases, especially for larger games and systems where you need more structure and monitoring.
I implemented additional features (designed for large-scale projects) like monitoring/debugging, automatic disconnection signals and self-destruction, resulting in the lowest memory footprint.
Additional features like Automatic Disconnection can be found at the development branch.
There are already tons of modules that does exactly this. Maid, Trove, Janitor, you name it. What exactly does this offer that other modules doesn’t have?
For a clicker game, can it handle approx 200 remote firings every second?
theyre all the same, some have better effiencey and some are more regularly updated, and some are more easier to understand and use,
Can you make your own thread instead of advertising this? I don’t understand why people feel the need to insert their own modules into other peoples posts.
whats the point of this you can replicate this in like 3 lines of code
You can quickly clear all connections with just one line of code instead of having to copy and paste whenever you want to clear a connection
how does this differ from maid/janitor?
Yes, I’m sure it would be able to when you use the optimization that my module provides. Like providing Player UserID in the name to make automatic disconnection possible or upcoming custom auto-disconnect in the development branch.
You can group RBXScriptConnections, allowing you to clean up an entire group at once. Additionally, you can set up automatic disconnection for players when they leave the game (since active RBXScriptConnections that are specifically created for the player are no longer needed at that point), or trigger automatic disconnection when another specific event occurs.
Another key point is logging; you can monitor the activity of these connections. If you’d like to learn more about these features, please refer to the current documentation on GitHub. I’ll be improving the documentation soon, but for now, you should be able to set up these special features. If not, I’m happy to help!
You can group RBXScriptConnections, allowing you to clean up an entire group at once. Additionally, you can set up automatic disconnection for players when they leave the game (since active RBXScriptConnections that are specifically created for the player are no longer needed at that point), or trigger automatic disconnection when another specific event occurs.
Another key point is logging; you can monitor the activity of these connections. If you’d like to learn more about these features, please refer to the current documentation on GitHub. I’ll be improving the documentation soon, but for now, you should be able to set up these special features. If not, I’m happy to help!