Customizable Reset Button Logic

Thank you for following up! =)

I am getting the following error on Android when I call SetCore(“ResetButtonCallback”, bindableEvent):

SetCore: ResetButtonCallback has not been registered by the CoreScripts

Do I need to yield before I call this method? Seems hacky.


We can fix this by registering the SetCore method earlier. I made a pull request to the CoreScripts GitHub.


Great addition - thank you.


I’m now getting SetCore: ResetButtonCallback has not been registered by the CoreScripts when I try to use this. was it disabled?

There’s an issue with Set/GetCore where they’re not registered by the CoreScripts until after some of your own LocalScripts are running (probably in StarterPlayerScripts, but maybe in others as well). You’ll need to wait until they are registered to use them. You can continually run your code in a pcall until it succeeds to accomplish this.


Can you confirm whether or not this is intermittent? It’d be really helpful for debugging this.

I’m getting it consistently in play solo, but seemingly not at all in local servers or online. I can’t tell if that’s just me getting lucky or if there’s actually some reason to it.

I have a little block of code that runs shortly after the player joins:

game.StarterGui:SetCoreGuiEnabled(“Health”, false)
game.StarterGui:SetCoreGuiEnabled(“Backpack”, false)
game:GetService(“StarterGui”):SetCore(“ResetButtonCallback”, Reset_Bindable)

with Reset_Bindable firing a server event that reloads the player’s character appearance.

EDIT: Now that I’m looking at this code again, is there even a difference between game.StarterGui and game:GetService("StarterGui")? Which one is better to use?

game:GetService'Service' finds the service by its ClassName, and creates it if it doesn’t exist.
game.Service finds the service by its Name, and errors if it doesn’t exist.
game:FindService'Service' finds the service by its ClassName, and returns nil if it doesn’t exist.

Always use GetService unless you have a specific reason for using FindService (e.g. NetworkServer). Never use game.Service.


I’ve always used game.Players instead of game:GetService(“Players”) tbh.
There has never EVER been a case for me where race conditions prevent accessing the service by index.
The service creates itself before scripts even run as far as I know. It’s a part of the DataModel’s construction protocol.

1 Like

You’re assuming that the Players service is named Players, which isn’t a safe guarantee. Better to access them by classname


Why can services have their names changed in the first place?
Shouldn’t that not be allowed?


Agreed. It’s really dumb that they can have their name changed, but for backwards-compatibility purposes we’d still need to account for it.


On top of that, they need to make it so services don’t have names that differ from their classname.
(I’m looking at you RunService, with your cheeky “Run Service” name.)


if any game is committing atrocities like this, they don’t deserve future compatibility :U
*cough* @PlaceRebuilder *cough*

sorry I think I’m sick right now or something.


Never use indexing to get a child, period. The only exception is when the objects haven’t been exposed to the game tree or other scripts. Another exception could be pcalling it, but then you might as well be using FindFirstChild.


Made a feature request to phase it out:


Might aswell rename it: SystemServerScriptService while we’re at it.

Also for those who don’t get it, I rename ServerScriptService to SService and ReplicatedStorage to RService for simplicity sake. Great practice, highly controversial, very recommended!

Yeah, no. Renaming instances because you don’t feel like creating a variable you can name whatever you want is not good practice.


its even worse than my practices, and I’m the one using modulescript getfenv manipulation to inject variables into my scripts so I don’t have to rewrite them over and over.