I’ve only got one, half-complete plugin by me that doesn’t interfere with this kind of thing at all. I tried disabling it but the issue still persists. It sounds like other people have had the issue before, as well.
I took another look at the post @FederalTactical linked and compared it to mine, and I think I have the same issue… The scripts will run once under StarterCharacterScripts, and once in the workspace itself, under the player character. It only happens on places that have a lot of assets to be loaded when the player joins - I can’t reproduce it on a blank baseplate or smaller published place. This makes it inconsistent, which is very annoying.
I also can’t find a workaround :>
So I decided to report it because I couldn’t find someone who had already reported it
Can you run this code and screenshot what the studio output looks like in your problematic place. Curious to see what can be causing this.
--!strict
local prefix: string = `[{script.ClassName} {script:GetFullName()}]`
print(prefix, "Started running")
script.AncestryChanged:Connect(function(): ()
-- this shouldn't run since spawning gets destroyed,
-- but added just to see any unusual behavior
warn(prefix, "Ancestry changed")
end)
workspace:GetAttributeChangedSignal("foo"):Connect(function(): ()
-- this should only run once in a normal environment
print(prefix, "foo changed")
end)
workspace:SetAttribute("foo", true)
I also tried the printing run message again, and I got 2 responses. I thought one might be from a cloned character in a viewport frame that I made clone, but when I opened both messages and clicked “Show in Explorer”, they both pointed to the script under my character. So it’s not that one is run under StarterCharacterScripts and one is run under the character…
Here’s a few images (couldn’t take video):
so I select “Show in Explorer” on both messages and they both point to the same script.
The idea is the scripts run on the client, so the RunContext set to Legacy or Server is useless, and it happens for both Scripts with Client RunContext and LocalScripts.
But thanks, because that uncovered another important detail - this issue only happens on the client.
This isn’t a bug, but rather part of how RunContext works. RunContext is supposed to allow scripts to run anywhere, and not allowing it to run in StarterCharacterScripts brings back the legacy behavior where the script’s parent affects how it runs.
The last few posts have run off of the actual bug. As I’ve already said, this happens for LocalScripts and Scripts with a RunContext of Client. This shouldn’t happen. Setting it to Legacy or Server causes it to run on the server where it doesn’t happen.
LocalScript
Runs twice when placed in StarterCharacterScripts. Not expected behaviour.
Script with RunContext set to Enum.RunContext.Client
Same behaviour as LocalScript; runs twice when parented to StarterCharacterScripts. Expected behaviour for that script type.
Script with RunContext set to Enum.RunContext.Legacy or Enum.RunContext.Server
Script runs once, but on the server. Expected behaviour.
In short - no matter the script setup, client scripts run twice when parented to StarterCharacterScripts (though they run under the character). It does not happen when they are moved to the character after a set interval from another location, which provides a workaround, but this is still incredibly annoying.
I seem to be unable to replicate this bug. You sure this isn’t a confusion between LocalScript and Script with RunContext set on Client? Their icons look similar, check their properties again.
That still doesn’t explain why I cannot replicate this bug. I tried putting a simple LocalScript and it only executed once. Maybe there’s more than meets the eye to your implementations?
Yeah, it’s inconsistent across places. I don’t know why. Other posts like this onei know that topic talks about gui and it’s not the exact same issue, but it also shows inconsistency and this bug report was linked to it.
and a few others also talk about inconsistency between places (i couldnt find them but i read about it).
The only pattern I can really think of/guess at is places with assets that are replicated at girst, like a loading screen in ReplicatedFirst, which could be causing the script to be run, delayed and not registered, and then run again, for some reason…
edit: that might also explain the slight delay between the first and second running of the script
Back when I was learning Lua and Roblox Studio I remember this happen to me. It’s not an engine bug and you can fix it yourself.
Have you tried adding some code to ensure the script or object is in the right parent of the game before running? In this case if it’s in StarterCharacterScripts then don’t run as that is just it’s starting location before it is reparented to the player character
Well, it is a bug, and what you’ve just suggested is a workaround. While a check like that would wait until it’s correctly parented, the script itself isn’t running parented to StarterCharacterScripts. I came up with a couple of other workarounds which I am using for now, but I’d like this to get fixed…
in this image, both of the messages have the output from the same script ancestry - workspace.12345koip.Movement. If one was running when it was parented to StarterCharacterScripts, it would show that - I checked this by hovering over the messages to show the ancestry.
Thats might be showing that it’s under the same script name. What is best to do as a quick debug is to have it print where the script it’s located/parented to in the game. From there I may be able to tell you a work around
Okay. It’s an odd issue since it’s technically working as it should but just not as intended and I can’t think of any other way I fixed it other then checking where it is. As long as you’ve found a work around then thats good
Scripts in StarterCharacterScripts fires every time when character is reset. Are you sure you not respawning character another time after running the game?
Nope, it’s whenever I join the game. I don’t have anything that loads the character, and it happens for both LocalScripts and Scripts with RunContext of Client. I only use the LocalScripts, though.
so I select “Show in Explorer” on both messages and they both point to the same script.
