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.
5 Likes
We can fix this by registering the SetCore method earlier. I made a pull request to the CoreScripts GitHub.
3 Likes
Great addition - thank you.
4 Likes
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.
3 Likes
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.
3 Likes
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
2 Likes
Why can services have their names changed in the first place?
Shouldn’t that not be allowed?
4 Likes
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.
2 Likes
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.)
10 Likes
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.
7 Likes
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.
5 Likes
Made a feature request to phase it out:
3 Likes
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.
8 Likes
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.
4 Likes