Strange error with BindToRenderStepped

[weakroblox35]

Tried testing my game until it errored out of nowhere, it never errored before. Unable to cast token to int

local function Hide()
	FAKEGUI:SetCoreGuiEnabled(Enum.CoreGuiType.Backpack, false)
end
RunService:BindToRenderStep("Hide", Enum.RenderPriority.First, Hide)

[HeroGamerGabby (Iro)]

@weakroblox35

BindToRenderStep

Hi! The problem is about the Enum.RenderPriority.First.

BindToRenderStep gets (name: string, priority: number, function: function) on the second argument you are passing a Enum not a number.

To fix that just add .Value and that’s it.

local function Hide()
	FAKEGUI:SetCoreGuiEnabled(Enum.CoreGuiType.Backpack, false)
end
RunService:BindToRenderStep("Hide", Enum.RenderPriority.First.Value, Hide)

[weakroblox35]

@HeroGamerGabby

BindToRenderStep gets (name: string, priority: number, function: function) on the second argument you are passing a Enum not a number.

weird i always thought it would pass the number itself just like how tables work

local d = {["First"] = 1} print(d.First) -- prints 1

[waves5217 (waves)]

Hi!

While @HeroGamerGabby is right, this sort of looks like an XY problem.

A function bound to render step with a value of 0 (Enum.RenderPriority.First) is going to run moments after user input is detected and anything else happens, even before camera and character controls run and so on.

@weakroblox35

thought it would pass the number itself just like how tables work

Enum is not actually a table, it’s userdata, meaning object that provides access to code written in C.

print(Enum.RenderPriority.First.Name, Enum.RenderPriority.First.Value)
--> First, 0

We don’t have enough context to know what FAKEGUI is, but disabling the back pack every frame prior to screen drawing isn’t good. Setting every frame won’t stop exploiters either.

If you’re working with the core scripts, it’s enough to attempt to disable the backpack with a couple of retries. Fractality_alt’s method is still very relevant.

Customizable Reset Button Logic

Retry logic is also nice to have. local coreCall do local MAX_RETRIES = 8 local StarterGui = game:GetService('StarterGui') local RunService = game:GetService('RunService') function coreCall(method, ...) local result = {} for retries = 1, MAX_RETRIES do result = {pcall(StarterGui[method], StarterGui, ...)} if result[1] then break end RunService.Stepped:Wait() end return unpack(result) end end assert(coreCall('SetCore', 'ResetButtonCallback', false))

And

assert(CoreCall("SetCoreGuiEnabled", Enum.CoreGuiType.Backpack, false))

would be the way.

[weakroblox35]

@waves5217

We don’t have enough context to know what FAKEGUI is, but disabling the back pack every frame prior to screen drawing isn’t good. Setting every frame won’t stop exploiters either.

FAKEGUI is startergui and i’m disabling the backpack gui when player is “downed” and i’m disabling it every frame to make sure any other script doesnt interfere with it and cause problems. and exploiters cant do much anyway it would just look weird with them attacking while ragdolling (not to mention attacks dont register when downed)

[waves5217 (waves)]

I see, that makes sense. However, if I were you, I’d rather try to make sure no other script interferes. Calling core script functions every frame before render seems relatively expensive. Besides, a core call tends to fail from time to time, so wrapping in pcall() is recommended.

[weakroblox35]

@waves5217

pcall()

pcall seems to cancel or stop any other events after a thing errors idk why

[waves5217 (waves)]

That shouldn’t be happening. pcall should simply catch an error and let the thread continue. Here’s an example with heartbeat and a function that fails during runtime, just like core scripts may.

local function TroubleMaker(number)
	return number + "one"
end
game:GetService("RunService").Heartbeat:Connect(function(dt)
	local success, result = pcall(TroubleMaker, 1)
	print(success, result)
end)