2 Likes
Are we expected to yield before using this? Or is play solo just bugged?
1 Like
Oh my god I didn’t think that this would be made so quickly!
Bless you @TheGamer101, you are a saint!
######~now we just need neon intensity properties~#####
Who said that?
10 Likes
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