I was just wondering if having a RBXScriptSignal Set up like this bad?
I’m referring to the Died Connection
Server.PostPhysics:Connect(function() -- RunService.Heartbeat
for _,m in pairs(MobH.TaggingService:GetTagged("mob")) do -- Gets Mob from Tag
task.spawn(function() -- spawn function
local target = Mob:Get(m) -- Gets Target
if target then -- If Target
Mob:Follow(m, target.HumanoidRootPart.Position) -- Follows Player
--m.ZHumanoid.MoveToFinished:Wait() Slows Mob
end
m.ZHumanoid.Died:Connect(function() -- Is this Bad?
Mob.OnDeath(m) -- Fires when Killing Mob
end)
m.HumanoidRootPart:SetNetworkOwner(nil) -- Sets Network Owner
end)
end
end)
Yeah it will call Mob.OnDeath like 10000 times depending on how long it was alive.
I suggest connecting to an event related to tagging service adding a new mob to connect to the .Died function.
Also why do you set set the network owner to nil every frame?
TaggingService is just CollectionService, And I’m not sure where to put SetNetworkOwner and Died , I use the GetInstanceAdded or something along the line of that for this, Correct?
I dont really use CollectionService often so this is all a little bit new to me
It is generally not a good idea to connect events within a loop like this because it can create a large number of event connections and may lead to performance issues. It is better to create the event connection outside of the loop and use the event’s arguments to identify which object the event is being fired for.
For example, you could modify your code as follows.
function onDied(mob)
Mob.OnDeath(mob)
end
for _, m in pairs(MobH.TaggingService:GetTagged("mob")) do
m.ZHumanoid.Died:Connect(onDied)
end
This way, you will only have one event connection per mob object, rather than creating a new event connection for each iteration of the loop.
@esadams188
Yes, But ill need to fire this everytime because Im going to be adding and removing mobs to the Tag, this will only fire for the Current amount of mobs, which is 0 as there wouldn’t be any mobs to iterate through at the start of the game, so for this to work, its in a loop, so the code isnt very helpful as it its literally what I’m doing.
@hkep
Thanks, But thats what I’m doing, Im talking about when an Instance gets Added, so i think i could use GetInstanceAddedSignal for that, I wont be able to test it, not for a while.
local add = table.insert
local mobInfos = {}
function setupMob(mob)
assert(not mobInfos[mob])
local mobInfo = {mob = mob, toBeCleaned = {}}
mobInfos[mob] = mobInfo
mob.HumanoidRootPart:SetNetworkOwner(nil)
add(mobInfo.toBeCleaned, mob..ZHumanoid.Died:Connect(function()
onMobDied(mob)
end)
add(mobInfo.toBeCleaned, Server.PostPhysics:Connect(function()
-- ...
end)
end
function cleanupMob(mob)
assert(mobInfos[mob])
local mobInfo = mobInfos[mob]
mobInfos[mob] = nil
foreach(mobInfo.toBeCleaned, cleanItem)
mobInfo.toBeCleaned = nil --Alternatively let toBeCleaned have weak values
end
function cleanItem(item)
if item:IsA("RBXScriptConnection") then
item:Disconnect()
else
error()
end
end
function foreach(items, callback)
for _, item in pairs(items) do
callback(item)
end
end
foreach(TagS:GetTagged("mob"), setupMob)
TagS:GetInstanceAddedSignal("mob"):Connect(setupMob) --AddTag or added to game
TagS:GetInstanceRemovedSignal("mob"):Connect(cleanupMob) --RemoveTag or removed from game
The script that you provided appears to be setting up a connection to the Died signal of the ZHumanoid instance in each of the objects in the MobH.TaggingService:GetTagged("mob") list. The Died signal is fired when the ZHumanoid instance is destroyed, which can happen when the object that the ZHumanoid instance is attached to is removed from the game or when the ZHumanoid instance’s Health property is set to 0.
It’s generally considered good practice to clean up connections that you set up in your scripts when they are no longer needed. In this case, if you are adding and removing objects from the MobH.TaggingService:GetTagged("mob") list, you should make sure to disconnect the Died signal connection for objects that are removed from the list.
You mentioned that you might use the GetInstanceAddedSignal method to handle adding objects to the list. This method returns a signal that fires whenever a new instance of the specified class is added to the game. You could use this signal to set up the Died signal connection for new objects that are added to the list.
I hope this helps! Let me know if you have any further questions.
Hi, I’m not sure about this code since they will have the Same name, and with assert(), it will probably error for finding a mob under the same name, and for the add part, it may remove a random Connection because of that
This should not be inside of a loop, as it will cause it to fire many times.
I would handle the death from a separate script, or create an event when new mob is created and handle it through there.
local diedConnection
local function mobDied()
diedConnection:Disconnect()
-- do stuff
end
diedConnection = Humanoid.Died:connect(mobDied)
GetInstanceAddedSignal would be perfect for what you’re trying to do. I would use it to set up the .Died connection and to set the network owner to nil. Also you should yield for the Humanoid using :WaitForChild method since it might not be loaded in yet.
It might be worth noting that when an instance is deleted using :Destroy() the functions connected to any events are disconnected automatically.
I tested it to confirm. If the character dies then the connection stays connected regardless. However if you use :Destroy() on the character, it automatically disconnects the .Died functions.
It doesn’t work off the Name property of the “mobs”. Instances (e.g. models or parts) can be table keys just like numbers or strings. E.g.
local partA = Instance.new("Part")
local partB = partA:Clone() --Has same name, same properties
local dictionary = {}
dictionary[partA] = 1
dictionary[partB] = 2
for k, v in pairs(dictionary) do --This loop is completely unaffected by the Names, except for what gets printed
print(k, v) --Prints Part, 1 followed by Part, 2.
end
partA.Name = "Part A"
partB.Name = "Part B"
for k, v in pairs(dictionary) do --This loop is completely unaffected by the Names, except for what gets
print(k, v) --Prints Part A, 1 followed by Part B, 2.
end
Anyway the point is, as long as different objects are used the assert shouldn’t throw an error, which is why it’s been put in there. To make sure a mob doesn’t get set up twice accidentally.
