It’s mainly in the case of plugins I run into this issue. But I’m not suggesting we get rid of it.
Plugins use RobloxLocked? Why would they need to lock something from the developer that’s using them?
Alright, instead of removing RobloxLovked, make it a property of CoreGUIs only. Solves that issue, as then they can only just it on GUIs (dont know how that can bypass a ban)
As for detecting if an object is RobloxLocked, I’ll provide my API for such things when I get in my pc.
1 Like
No, but plugins occasionally will access a RobloxLocked instance through events such as game.ItemChanged. So it should be as simple as.
function test(instance)
if not instance.RobloxLocked then
-- Do something
end
end
As opposed to
function test(instance)
if pcall(function () return instance.ClassName end) then
-- Do something again
end
end
The latter method feels ambiguous since you’re basically testing for the first.
If you’re using a plugin then you have permissions to read and write RobloxLocked anyway. RobloxLocked is PluginSecurity.
@woot3 Sharksie is mostly right: Plugins can access RobloxLocked fine.
RobloxLocked only has a restricting function on code running with identity 2 (and maaaaybe 3?).
This means anything, except normal (local)scripts can use RobloxLocked objects just fine.
(Plugins can even set it, although I’m pretty sure RobloxLocked only “saves” to the current identity)
If it only ‘saves’ to the current identity, then how come Seven or similar software run at ‘level 7’ and when they create a RobloxLocked instance, it affects the other identities?
I was pretty sure RobloxLocked was “global” accross identities, until I tested it out when I made that post.
I had a script, I did this code:
printidentity()
print(script.ClassName)
script.RobloxLocked = true
I ran it first as a normal script, then as a plugin, then again script and again plugin.
(Yes, ‘script’ pointed to the exact same object all four times)
Printing classname always worked for both identities.
RobloxLocked only errored for identity 2, completely as expected.
I added print(script.RobloxLocked) afterwards: plugin printed it as true (id2 errored)
So either ClassName is readable during RobloxLocked (it wasn’t before for sure), or it’s divided.
(Tested this in studio, so I’m not sure if that matters)
(maybe identity 7 and identity 2 do share the same RobloxLocked, separately from corescripts etc)
If you use filteringenabled your game will be less prone to exploits like this. Exploits do get fixed but you can avoid being driven c r a z y all together by writing your game using filtering.
3 Likes
Ooh a FE war thread.
The truth is either FE or your suggested patch would take equal amounts of work, plus you should consider the fact that such updates, especially unpopular ones may take months to appear on Roblox. You might as well drop it, don’t try helping other developers with this and just do the next best option either it being FE or some improved RobloxLocked detection since pcall does exist for a reason.
And hopefully devs will shut up about FE and let other devs swim in their own problems they’ve caused when not using it. It’s not really beneficial for games that are not on the front page.
1 Like