Reset Disabler not Working

do something like

local StarterGui = game:GetService('StarterGui')
local suc = pcall(StarterGui.SetCore, StarterGui, 'ResetButtonCallback', false)
while not suc do
    suc = pcall(StarterGui.SetCore, StarterGui, 'ResetButtonCallback', false)
end

Just tried that, the output said
21:18:17.944 Script timeout: exhausted allowed execution time - Client - ResetDisabler:3
21:18:17.944 Stack Begin - Studio
21:18:17.944 Script ‘ReplicatedFirst.ResetDisabler’, Line 3 - Studio - ResetDisabler:3
21:18:17.944 Stack End - Studio

Place a wait in the while loop

It worked! Thanks to both of you for helping me. :woot:

You can try using a RunService event.

local StarterGui = game:GetService('StarterGui')
local RunService = game:GetService('RunService')

local connection

connection = RunService.Heartbeat:Connect(function()
    local success = pcall(StarterGui.SetCore, StarterGui, 'ResetButtonCallback', false)

    if success then
        connection:Disconnect()
    end
end)

This is a quote from a previous answer for this question, it is more performant than just putting it in a while true loop.

Its not any way faster, its just got better security to prevent infinite loops.

Infinite loops takes up performance…

Only if it becomes an infinite loop

There are rare chances that this will… only times it may is if the call is removed/if the ResetButtonCallback string of SetCore is removed.

Though yes i do instruct you to sacrifice slight performance for security.
The statement that its faster is invalid unless the loop become infinite, and the chances of that are essentially rare…

I never said faster, I said performant. Different words, different meaning.

Sometimes SetCore is never registered, making the loop infinite.

Performant is a different word, sure, but different meaning, not so sure.
Faster in this context is very similar to performant by definition.
Performant implies lower resource usage, which is only true in certain situations.
Faster in this context means exactly the same definition.

SetCore when not registered is a bad situation either-way, if the dev intends to have the reset button disabled.
So an infinite loop is the least of their worries

The definition of fast is

performing or able to perform a particular action quickly.

but do you know of the context?
Definitions change between context.
Faster is my term of Performant when i dont want to ache my fingers typing out a longer word.

The context here is in execution speed, both performant implies faster execution speed. not that the code underneath is inherently going to be faster, but that it is bound to use less resources meaning more clock calls on the cpu, which inherently makes the code faster.

Also when is SetCore never registered, would this not be a bug?

Faster means getting something done at high speed.

Performant means to use less resources to do a task.

While performant can sometimes mean fast, fast doesn’t mean performant since I may make an installer that takes 1 second to complete (fast) however uses 16 GB of RAM (not performant)

I really don’t know however it was mentioned somewhere in this topic that this can sometimes happen.

That does not mean never… it means they are not registered at any given time

There was also a few rare cases in where it never register.