Strange error with BindToRenderStepped

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)
1 Like

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)

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

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

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.

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.

And

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

would be the way.

2 Likes

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)

1 Like

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.

1 Like

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

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)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.