Customizable Reset Button Logic

Wouldn’t ResetButtonEvent be more intuitive, since it’s an event and not a callback?

To me that ResetButtonEvent suggests that the API will add a new event to fire when the player resets but not override the previous behavior. Callback suggests that there can only be one. I don’t think there is a huge difference either way though.

7 Likes

A possible alternative could be to use a BindableFunction, but execute it in a new thread using spawn.

1 Like

Yes! This is great.

1 Like

Why not just use a function?

2 Likes

Are we expected to yield before using this? Or is play solo just bugged?

1 Like

I love you @TheGamer101. You are the younger zeuxcg.

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.

4 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