I don’t know if this is a bug or not, but when you require a modulescript that has events connected inside, and your character dies, the events remain connected even after you respawn. I tested this because it was leading to annoying bugs in my game, and I found that after connecting a UserInputService.InputBegan event to make it where pressing a button would print “hi”, after each respawn, the amount of times “hi” was printed would increase by 1. Is there a way around this? Does this have something to do with modulescripts’ ability to run in nil?
Where’s the script requiring this module located? Placing it within StarterCharacterScripts should solve your problem.
2 Likes
Make sure that your code resembles something related to this;
humanoid = character.Humanoid
local otherEvent -- variable for an event
local humDied -- died variable
humDied = humanoid.Died:Connect(function()
otherEvent:disconnect() -- disconnecting the event
humDied:disconnect() -- same thing
end)
looks a tad sloppy, but if you read it closely you’ll get the picture of what to do.
3 Likes
That depends on where you placed your ModuleScript. ModuleScripts aren’t supposed to reset when your character dies. Upon first require, every subsequent require returns the same instance of that module.
Knowing your object hierarchy and/or the code in your ModuleScript would be helpful towards your situation. You should always try and include as much information as you can so we can assist you with your problem.
2 Likes
the module is inside a localscript in a player’s playergui
When your character dies, the module isn’t being destroyed or disconnected. It should probably be a fix for an upcoming patch, but throw your Connections into a table, and when your character dies loop through and disconnect them(I use it for my game scripts).
local Connects = {}
Connects[#Connects+1] = game:GetService('UserInputService'):Connect(function(input,gpe)
if not gpe then
print('hello there')
end
end)
blah.Humanoid.Died:Connect(function()
for i,v in next, Connects do
v:disconnect()
end
end)
1 Like
Thanks for this, this is what I ended up doing in the end. I was just curious to know if this problem I was having was a bug or an intended feature
1 Like
Anything put in PlayerGui will be deleted when the player respawns unless it’s a ScreenGui with it’s ResetOnSpawn property = true
Not sure why it’s the way it is but it’s annoying.
StarterGui/ResetPlayerGuiOnSpawn is also hidden idk if it’s accessible with a script tho.
Instead of using multiple scripts you can use just one for the entire session that would fix your problem as well.
Np! Do me a favor and set a solution so any others experiencing this problem can find a fix for it.
It’s not annoying, it’s better this way. StarterGui is a container that contains Guis to be given to Players when their character starts. ResetOnSpawn gives you explicit control to void this behaviour. It’d be much more of a pain to manually remove things when a refresh is required. Any starter container denotes starter items.
PlayerScripts superseded keeping client-side code within the StarterGui, or within LayerCollectors that have ResetOnSpawn set to false. You should be using PlayerScripts if you want client-side code that shouldn’t reset per spawn.
It is. ResetOnSpawn in LayerCollectors superseded ResetPlayerGuiOnSpawn however. Roblox opted to give developers more control over which LayerCollectors explicitly should reset per spawn or not. ResetPlayerGuiOnSpawn affects all LayerCollectors; ResetOnSpawn only affects the specific LayerCollector its associated with.
1 Like