local StarterGui = game:GetService("StarterGui")
StarterGui:SetCore("AvatarContextMenuEnabled", true)
Hello, why its says me this “SetCore: AvatarContextMenuEnabled has not been registered by the CoreScripts” (This is a LocalScript placed in StarterPlayerScripts) ? script by roblox here.
If I remember correctly, ocasionally corescripts can take a while to register different core actions, so whenever you have a script that runs immediately, it can try to set core before it is ready to be set to (before its registered)
the solution is just to set a pcall() and have a method to retry until it is successful
Can a repeat task.wait() until game:IsLoaded() fix the problem ?
Oh I think I know why, try adding a pcall maybe. Sometimes it doesn’t load in time.
NO. use a pcall, don’t do that why does everyone do that repeat thingy its so weird.
Also maybe if you parent the local script to startercharacterscripts it has more of a chance of being loaded. Edit: yep just tried it in startercharacterscripts, same script as yours and it worked. Even without a pcall, but add a pcall just in case.
I don’t think so, here’s a simple code example for retrying until success
startergui = game:GetService("StarterGui")
success = false
while not success do
success = pcall(function()
startergui:SetCore("AvatarContextMenuEnabled", true)
end)
task.wait(1/30)
end
Just adding a pcall is all you need, especially if you parent the script to startercharacterscripts it always works almost 100% of the time without pcalls.
local success, errormessage = pcall(function()
startergui:SetCore("AvatarContextMenuEnabled", true)
end)
if errormessage then
startergui:SetCore("AvatarContextMenuEnabled", true)
warn(errormessage)
end
I know this means it’ll only retry one more time if it fails but really you only need to retry once just in case.
Edit: I’ve just tested a pcall with a local script in starterplayerscripts and it actually will still error if the core scripts haven’t been registered. So really just put a local script in startercharacterscripts I’d say, and maybe a pcall.
Hi, “working almost 100%” and “just in case” isn’t reliable behavior, also ignoring that parenting it to StarterCharacterScripts adds unnecessary overhead.
the “not registered by corescripts” error can ocurr more than once (which you would be aware of if you’ve ever had any experience with trying to disable the reset button)
I’m sorry. Please forgive me. I’m really sorry. You are a better programmer than me, I will never be on your level. So sorry.
Oh yeah I did do that for one of my games, just used a pcall in startercharacterscripts and it worked like a charm (even if it retries again after dying so what? It would be loaded by then). Also, you can just check if it’s been enabled and if it has then don’t do it. You know what i mean.
if the intention is to disable the reset button, maybe they aren’t supposed to be allowed to die? so the button would never get disabled? 
regardless heres proof, having it placed in starterplayerscripts that it doesn’t consistently work:
startergui = game:GetService("StarterGui")
disabled = false
attempts = 1
while not disabled do
local s, rr = pcall(function()
startergui:SetCore("ResetButtonCallback", false)
end)
if not s then
warn("Callback not registered, retrying... " .. attempts)
attempts = attempts + 1
task.wait()
else
disabled = true
warn("Callback Sucessful. Attempts: " .. attempts)
end
end
I’m not arguing, I support your approach, but @Amritss said in CharacterScripts:
And you did the test on PlayerScripts:
CharacterScripts take longer to load, cause it depends when the Character Model loaded, thats why it could have more chances that works more consistently on the first try as @Amritss experienced.
But, as you said:
Which is important, could you elaborate?
But I thought if the reset button is disabled it wouldn’t even retry again so like why not just put it in startercharacterscripts you know… I don’t see the need for putting it in starterplayerscripts.
No I want you to do it in startercharacterscripts, test it on startercharacterscripts. Why don’t we just combine the two methods. You use your script, just parented to startercharacterscripts. Then we all happy.
placing a localscript on startercharacterscripts means a new separate instance that has to be cloned, parented to the model, executed and garbage collected, that then runs useless code on every respawn after the core has been sucessfully set,
rather than a single thread being ran once on starterplayer
But if you’re disabling the reset button it’ll only run once like in starterplayerscripts. So why not just use startercharacter.
Agree, I just wanted to get more clarification. Indeed everytime the Character Model is destroyed and spawned again, all of its scripts will take place again. and PlayerScripts is an instance that is constant thru all game session, thank you
That’s true, but in this case if the reset button is disabled none of that happens. So why not just do it in startercharacter?
Its not like a “capital sin” if you want to do it on CharacterScripts. But, think about it. The first time the player spawned its CharacterModel, your script runs, it disables the button, then if the player dies again (cause in this game you still have death available but you just wanted to disable the reset button). Then when the player’s CharacterModel, again, your script will be cloned and parented to the Character again, it will run again, kinda pointless if the button is already disabled, why you want to have that script constantly spawning inside the Character if it already accomplish its task since the beginning. And that will happen lot of times, everytime a new CharacterModel is created for your player, kinda useless code in there