Hey creators!
Release Notes for 653 are now live! 
can we have intellisense types for Players.BanAsync
6 Likes
Release 653, the one with the miscellaneous Luau and EditableMesh/Image fixes.
1 Like
and all open cloud ones
maybe actually maybe Roblox has Luau type definitions for that somewhere 
the open cloud modules have it I think
2 Likes
{ [string]: any } is too powerful
4 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.
8 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.
12 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.
8 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.
6 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() ?
Though the lack of documentation directly in studio is annoying, the proper documentation is already there.
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.
3 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.
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.
1 Like
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).
No, as these are accesible properties. A signal will not fire if the property is inaccesible or non-Scriptable.
1 Like