EDIT: It’s not perfect but it gets the job done.
And I’m more than happy to hear about how they bypass it.
EDIT: It’s not perfect but it gets the job done.
And I’m more than happy to hear about how they bypass it.
I have been having this for months on my games and I just deleted the Status in Humanoid since nothing on my game was using it.
That’s a smart idea. LoadLibrary doesn’t exist anymore, so the Status object (for the RbxStatus library) is effectively useless. A useless object that can crash your server is not something to keep around.
I don’t think “Should” is a solution… It is still happening
I can confirm this works, thank you. Hopefully Roblox creates a update so not everyone has to put a script into their place to secure the stability of their game.
We have a fix ready to be deployed, but would like to test it on places impacted by this exploit first before turning it on for everyone. If you are actively being impacted by this exploit, please send me a direct message of the ID of your place you’d like the fix to be enabled for.
cc @Nimblz @Sudden_Demise @anon66957764 @MetatableIndex @reet15 @NachtHemd @zaytuls @t1dtony @HonokaSakurai
I’ve put a patch script in for the game, do you want me tor remove it and send you my place ID?
Yes, please. I’d like to verify this fix works for real games before turning it on for the entire platform.
Alright, I’ll remove the patch script then give you the ID.
I forgot that I already removed the patch script, here is my game link: [SOON!] 🥪 Work at a Restaurant - Roblox
https://www.roblox.com/games/3487742603/Work-at-a-Restaurant-Chicken-Shack-V1
I’ve added a patch script for multiple different FE crashers. Haven’t seen the servers being crashed since I added them.
I’ve enabled the fix for the following places. Let me know if you see anything weird.
4837595186
4586741827
3487742603
2747834912
4388574342
@ThePhantomG @zaytuls @Sudden_Demise @Nimblz @MetatableIndex
The fix for this has now been enabled for the whole platform.
I assume this fix is why I can’t drop tools anymore? Tool gets stuck to arm, then can’t re-equip. Any way
to make the fix less draconian?
This is a major problem for me. I can’t even parent tools to workspace from a LocalScript anymore. I hope they fix this bug. It’s been a major issue for me.
I submitted a bug report. I hope they do something about this.
Thanks for responding. I’ve already implemented big workarounds, but what worked previously
on the client was:
tool.CanBeDropped = true
tool.Parent = workspace
With the new setup, not only does this not work anymore to drop, but now Unequipped
also does not
get fired on the server. (If you parent it to nil
on the server, then it will fire on the server.)
It seems that once you try to parent to the tool to workspace
, FU bits seem to get set in the tool,
forcing a reconstruction of the tool to allow proper use in the world.
Sorry, this is intentional!
If you’d still like to have tool.Parent = workspace
work from the client side, you should set tool.CanBeDropped = true
on the server side.
Previously, in games where tool.CanBeDropped
was false
, exploiters could reparent their tools to Workspace (or anywhere else for that matter…). We now check tool.CanBeDropped
before allowing the parent change to replicate.
Thanks for the explanation! I hope it’s been put in the documentation update queue.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.