Release Notes for 653

[TooManyOveralls]

Hey creators!

Release Notes for 653 are now live!

[Sayersooth (Kyle)]

can we have intellisense types for Players.BanAsync

[Dekkonot]

Release 653, the one with the miscellaneous Luau and EditableMesh/Image fixes.

[foamycoolkid5]

What does this one mean?

[HealthyKarl]

and all open cloud ones

maybe actually maybe Roblox has Luau type definitions for that somewhere

the open cloud modules have it I think

[Sayersooth (Kyle)]

{ [string]: any } is too powerful

[vfx_1]

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.

[tnavarts]

@Sayersooth

can we have intellisense types for Players.BanAsync

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.

[index_self]

@Sayersooth

{ [string]: any } is too powerful

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?

@vfx_1

I use this trick for exploit detection purpose

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.

[metatablecatmaid (metatablecat)]

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.

[edvaardss]

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() ?

[TaxFraudBruh]

Though the lack of documentation directly in studio is annoying, the proper documentation is already there.

[vfx_1]

@index_self

Not only do they misuse engine quirks

Trust me exploiters do even more than my methods to attempt to limit their abilities. I am not even trying to completely prevent them.

@index_self

but also could start false-flagging innocent players after some random behavior change.

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.

[jonbyte (Jon)]

@vfx_1

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.

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.

[vfx_1]

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.

@jonbyte

relying on hacky methods that depend on some internal behavior always being consistent

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.

[Place_Reboot (Place)]

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).

[TimeFrenzied (Broken Spawn)]

@edvaardss

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?

No, as these are accesible properties. A signal will not fire if the property is inaccesible or non-Scriptable.