Splitting up code - events and listeners inquiry (limitations)

Help and Feedback Scripting Support
,
#1

At present, coupled with my recent request for feedback on my codebase style, I’m rescripting the core components of my game (I don’t have much, so I’m in luck). Some unease has poked at me, so I’d like to ask these questions first before I go on with my work. The Wiki has done no justice to answer my questions, neither has searching the DevForum (inadequate search queries or lack of posts, not sure).

So in regards to RBXScriptSignals, I have three questions.

  1. Is there a maximum number of times you can hook a listener up to an event?
  2. Will I encounter any issues if I listen on an event several times? To make for an example, let’s say I’m connecting on PlayerAdded at least 7 times, not including any script inserted by the backend at run time (i.e. Lua Chat System).
  3. Is it bad if I’m connecting several times? I’m going to be splitting my code up “properly” this time and several components may be reliant on an event such as PlayerAdded. I want to know if that’d interfere with anything or if I’m fine.

Naturally also assume that I’m disconnecting events or destroying instances that I no longer will require and are safe to be disposed of once used.

#2

Assuming you are disconnecting events as you stated, I see no issue with having listeners in multiple areas to handle category-specific things. I see no reason to have a dedicated script with one specific event then calls other custom events. You’d end up needing more BindableEvents in your game, or more commonly required modules.

Without digging deeply into back-end efficiency, the pros outweigh the cons.

1 Like
#3
  1. I haven’t run into a limit, but I’d assume there is one. Your heap will overflow if it is internally using a linked list, overflow an int or double, or something to make it stop. Try different numbers in this loop, and then touch the part and see what the highest number printed is:
local i = 0
local function foo()
    i = i + 1
    print(i)
end

local p = Instance.new 'Part'
p.Anchored = true
p.Parent = workspace

for j = 1, 10000 do
    p.Touched:Connect(foo)
end

  1. The only issue you will run into listening in on the event multiple times is that things may be called in a different order than you are expecting. If the operations don’t interact with each other or can be performed in different orders, then you are fine.

  2. I’d say neither one connecting once or multiple time is worse than the other. If it creates more modular code and maintainable code, then it is good.

One alternative approach would be to have one connection to each event, and maintain your own connection list. If you do this then you can implement other features later like connection priority, connections preventing the later connections from firing, and easily enable/disable all events.

3 Likes
#4
  1. I’m not going to be listening on events several hundreds of times, only say… less than 30, approximately, over the entire lifetime of a single server. This, without a doubt, could fetch for a lower value. So long as I’m able to listen to an event several times a minimal amount without issue, I’ll be fine.
  2. Order of calling does not necessarily matter in the use cases that I’m applying them for. If it does matter, I would like to hope that I can use a method of waiting for a connection to finish before the other one runs, such as checking for an applied tag or something that exists.
  3. Gotcha.

Thanks for the input. I’ll be marking the first response as a solution, but this is just as much a solver to my problem. Can only have one solution. :slightly_smiling_face: