Hey creators!
Release Notes for 653 are now live! 
can we have intellisense types for Players.BanAsync
11 Likes
Release 653, the one with the miscellaneous Luau and EditableMesh/Image fixes.
4 Likes
and all open cloud ones
maybe actually maybe Roblox has Luau type definitions for that somewhere 
the open cloud modules have it I think
3 Likes
{ [string]: any } is too powerful
6 Likes
I am fully against this one rolling out.
I use this trick for exploit detection purposes while creators are still unable to read what the property changed to anyway if it is restricted. I see no point of this change.
[EDIT 12.01.2025]
There are many more use cases on which a lot of my and not only my code is relied on.
One of multiple examples I can point out is looking for the âNetworkIsSleepingâ property to change and depending on various aspects either forcefully wake up or anchor a part. Currently there are no other alternatives while this property is non-scriptable. In my opinion roblox should allow creators to use non-scriptable properties with :GetPropertyChangedSignal() as well, because .Changed as we all know is less efficient. For safety reasons CoreGui and related services could be excluded but overall we would still not be able and in most cases not even need to read what the particular property has changed to.
I see this change which is listed under âImprovementsâ has still not been rolled out, please keep it like that!
Thanks you.
10 Likes
Yes, thatâs the idea behind the BanConfigType definition that already exists for it. The last bit of wiring to hook up the necessary parts of the reflection system just isnât there yet.
13 Likes
Thatâs one of my worst pet peeves with the Roblox API types. They donât even try to properly annotate any configuration parameters. Like you should already know the fields anyway?
Any âexploit detection methodâ is extraordinarily stupid to use. Not only do they misuse engine quirks but also could start false-flagging innocent players after some random behavior change.
9 Likes
This isnât a good idea, some NonScriptable properties change while the game is running in normal operation, such as for humanoid descriptionâs AccessoryBlob.
Iâm sure an exploit could change a NonScriptable property if they tried to but its also unlikely that an exploit would need to in the first place unless theyâre trying to mess with properties that are locked behind this setting.
7 Likes
Does this mean if Iâm on a local team test and lets say I change a property in the explorer this will not send a signal?
And will this affect :GetPropertyChangedSignal() ?
1 Like
Though the lack of documentation directly in studio is annoying, the proper documentation is already there.
1 Like
Trust me exploiters do even more than my methods to attempt to limit their abilities. I am not even trying to completely prevent them.
If I looked at everything like this, no stuff which could potentially affect players should be scripted as the desired behaviour could potentially randomly change.
4 Likes
This take doesnât make much sense. There is a difference between relying on stuff that is documented and ânormalâ as in likely to have backwards compatibility even if it was deprecated versus relying on hacky methods that depend on some internal behavior always being consistent.
This is similar to how people got upset when the behavior of os.clock() changed in a way where they couldnât fingerprint players anymore.
1 Like
Well in this case I would either remove or redo the affected detection and if needed unban false flagged players. I would rather detect 95% of exploiters who are unable to bypass my methods and eventually handle a few appeals every day than detect 0 exploiters as âthey can bypass almost everything anywayâ. They can. But that doesnât mean they WILL.
I never expected them to be so. I wouldnât also call these âhackyâ methods. I and others who use them are fully aware that they may stop working as originally intended. However regarding this thread I still believe that this is pointless to change the .Changed property behaviour, it is really good as how it is now. Eventually Roblox could allow these methods to be directly checked with :GetPropertyChangedSignal() if they think that certain users may not expect or want some non existing properties to fire along with the desired ones. In both cases they still cannot be read by creators.
2 Likes
Older executors used to send you a notification saying theyâre using a specific API in Roblox, that used the Roblox notification system which couldâve been flagged by ItemChanged if you eliminated other potential sources (screenshots, videos and graphics quality changes).
1 Like
No, as these are accesible properties. A signal will not fire if the property is inaccesible or non-Scriptable.
2 Likes