I know lol. I want to use the button to run code that resets my custom system.
(What he’s trying to say is that resetting doesn’t work without player.Character set)
@BuildIntoGames
Right? I know that, he just has to fire code to reset his system using this method. Not sure if I’m explaining badly or I’m an idiot
1 Like
I looked at the corescripts and it appears that what you suggested will no longer work even with a character:
GitHub CoreScript ResetCharacter
local PlayersService = game:GetService("Players")
local resetCharFunc = function()
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
There’s no way for it to error anymore.
local PlayersService = game:GetService("Players")
local resetCharFunc = function()
local player = PlayersService.LocalPlayer
if player then
local character = player.Character
if character then
error("kthx")
end
end
end
…you’re not actually able to edit the corescripts are you? or is this from StarterPlayer?
CoreScripts cannot be edited. The source code I posted was retrieved from ROBLOX’s GitHub which I provided a link to atop the code.
1 Like
Yeah, this would be a great addition!
WELP
That sucks
For now, a temporary fix could be to let user type “/reset” I just went to test your game but it was empty and I couldn’t test out the other weapons since the reset doesn’t work (or it does, and I just dont know how to find it because it’s not written anywhere)
1 Like
Update: I have the filed the pull request for this against the CoreScripts GitHub so it is coming soon. Just need to wait until it actually ships and then enable it.
It will work like this:
local resetBindable = Instance.new("BindableEvent")
resetBindable.Event:connect(function()
-- Implement custom reset logic here
end)
-- This will remove the current behavior for when the reset button
-- is pressed and just fire resetBindable instead.
game:GetService("StarterGui"):SetCore("ResetButtonCallback", resetBindable)
-- Setting ResetButtonCallback to false will grey out the reset button
-- in the menu and players won't be able to reset in your game.
game:GetService("StarterGui"):SetCore("ResetButtonCallback", false)
I hope this covers all use cases, let me know if it doesn’t.
14 Likes
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.