Was asked to report it:
https://twitter.com/ByDefaultGames/status/816322772372783104
1 Like
This is how all XValue objects work, Changed only fires when it’s Value property is changed, and it returns the new value (unlike every other object returning a string for the property that was changed). At this point I’ve seen it as expected behavior, and they can’t change it (backwards compatibility).
This isn’t technically a bug in the traditional sense but rather a design oversight – still, I think a bug is the most appropriate category to file it under. Changed for Value objects is different from Instance.Changed: it only fires when Value changes, and supplies the new value as a parameter, where as Instance.Changed fires when any property changes, and supplies the name of the property changed as a parameter. This is especially problematic with constrained values, but even so with other types when you want to check if their name changes.
Darkmist is right that changing this behavior would cause problems with backwards compatibility though. IMO, this large assortment of value objects should be deprecated, and a generic ValueObject should be created to replace them. It should use the traditional Instance.Changed, and not have a unique event. The ValueObject should have a Type property which allows developers to select what kind of value it stores, and have a LimitsEnabled property, similar to constraints, that when enabled allows constraining of numeric-type values.
Unfortunately *Value objects override their Changed event so it fires only when the Value property is changed, not when any property is changed. We can’t change the behavior at this point because it would break many games.