This is EXACTLY what I wanted. Thank you!
If I want to restore the default functionality, how would I do it?
game:GetService(“StarterGui”):SetCore(“ResetButtonCallback”, nil) ???
You would have to write your own version of the default functionality, it’s not very complicated so this isn’t much of a downside.
Can’t use nil unfortunately because you would get the error “Argument 2 missing or nil”.
This is the default reset function by the way, pretty easy to set the reset behavior back to this.
function defaultResetFunction()
local player = PlayersService.LocalPlayer
if player then
local character = player.Character
if character then
local humanoid = character:FindFirstChild('Humanoid')
if humanoid then
humanoid.Health = 0
end
end
end
end
1 Like
You are the real MVP
I think it’d be better implemented as:
GetCore("PlayerResetEvent")
Which returns a BindableEvent. Useful for following API.
and SetCore("ResetButtonCallback", function)
The current proposed implementation does not allow for overriding existing behavior. By using a callback function, I can return true or false from that function, and that will allow me to extend/override default reset behavior. GetCore(“PlayerResetEvent”) may not be necessary because I can just manually create and trigger a custom BindableEvent within the callback I set, but providing a core BindableEvent removes the need for boilerplate code which re-implements the same thing over and over across multiple games.
A BindableFunction may be preferable instead of passing a function if you want to connect/disconnect events. Otherwise SetCore would have to return a connection object or something, or there would have to be a different method to delete signals entirely. (seems uglier than passing a bindablefunction)
For the current implementation, all the corescripts are doing is event:Fire() with the event you gave it. You have direct access to it, so if you wanted to disconnect your BindableEvent you’d just do event:disconnect().
For the implementation I suggested, you could disconnect your event on your own.
local event; event = GetCore("PlayerResetEvent"):connect(function()
print("PlayerReset")
event:disconnect()
end)
I initially suggested a potential BindableFunction to be consistent with the corescript’s internal usage of a BindableEvent (the other thing I suggested), but now that I think about it, it’d be pretty dumb – it’s just extra overhead, and we shouldn’t design public API based on private idiosyncrasies if possible. It should just be a function – I’ll edit my earlier post.
To be clear this would override existing behavior, only the last BindableEvent registered is ever fired.
Having both the event and Callback implementations seems a bit complicated, does the Callback version override the event or would the event always fire?
We also can’t use a function because currently the variant type doesn’t support functions, maybe a BindableFunction but I don’t like the fact that a developer could cause the CoreScript thread that called it to infinitely yield (not sure if we really need to worry about this though).
GetCore(“PlayerResetEvent”) cannot be overridden. It can’t even be set. The CoreScript just returns a BindableEvent (or metatable so the Instance can’t be messed with) that any (one or multiple) can hook into. The corescript is the only one that can fire that event.
SetCore(“ResetButtonCallback”, function) overrides the current callback. It never overrides the event because they’re completely separate things. PlayerResetEvent is what fires when the player resets. ResetButtonCallback is what determines whether or not the player resets when they click the reset button.
As for doing naughty stuff to the BindableFunction and causing issues with the corescripts, that shouldn’t be an issue so long as it’s done in its own thread and is wrapped in a pcall. Yeah you can cause an infinite yield, but there really aren’t any negative side effects to that.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.