The .Changed signal isn’t fired for ValueBase objects. This is written at the end of the introduction text:
For “-Value” objects, this event behaves differently: it only fires when the Value property changes. See individual pages for IntValue , StringValue , etc for more information. To detect other changes in these objects, you must use GetPropertyChangedSignal instead.
But could there be a yellow warning label at the top along with DetectingPropertyChanges to highlight that this signal will not work for ValueBase objects?
I keep forgetting it.
#platform-feedback:documentation-requests
6 Likes
Moved this over from #platform-feedback:website-features to #platform-feedback:developer-hub as this is about documentation.
This is a very interesting implementation detail that I never knew existed. While I can see why it existed, since the Value is all you really care about, special casing Changed like this seems odd. Changing this behavior may be worth an engine feature request as I would hope nobody relied on this. Regardless, this is worth highlighting on the page.
2 Likes
The way they’re handling this on the DevHub is extremely hacky and weird too. It’s a side effect of how I handled API automation while I worked on the DevHub back in 2018.
They pretended to add a new tag to the Changed event, and it persists because Changed is enshrined in its current state and will likely never change.
Since the system only updates the automated details of a member when it’s computed hash changes, this banner and [DetectingPropertyChanges] tag persist.
Focusing on the point though, this is one of the few cases where Roblox has overloaded one of their API members. It has been this way ever since value objects were introduced. This isn’t the only case where it happens either. The Workspace class overloads Model:BreakJoints with its own version too: