GetPropertyChangedSignal does not work for StudioService ShowConstraintDetails or DrawConstraintsOnTop

[PeZsmistic]

Issue Type: Other
Impact: Moderate
Frequency: Constantly

Reproduction Steps:
Run this in the command bar and toggle the corresponding options in the ribbonbar.

StudioService = game:GetService("StudioService")
StudioService:GetPropertyChangedSignal("ShowConstraintDetails"):Connect(function() print("Hi") end)
StudioService:GetPropertyChangedSignal("DrawConstraintsOnTop"):Connect(function() print("Hi") end)

Expected Behavior:
The events should fire when I toggle the settings in the ribbonbar, and “Hi” should be printed.

Actual Behavior:
The events do not fire and “Hi” is not printed.

I am trying to make additional visualizers for constraints in my Studio Tweaks plugin turn on or off, or change occlusion mode when you use these settings.

Workaround:
The only workaround is to poll these values and manually fire your own event, which is disgusting.

I want my plugin to be seamless with Studio and this issue makes that impossible without doing something disgusting and inefficient.

---

Related: API to get ConstraintScale and ShowWelds via StudioService
Every turn I take working on this plugin I find something broken, not documented, or nonsensical, and I am getting outrageously frustrated.

[Halalaluyafail3 (FindFirstChild)]

The StudioService properties DraggerSolveConstraints, GridSize, RotateIncrement, and UseLocalSpace also have the same of not firing GetPropertyChangedSignal signals. Plugin.GridSize and Plugin.CollisionEnabled also have the same problem of not firing GetPropertyChanged signals.

[tnavarts]

@PeZsmistic

The only workaround is to poll these values and manually fire your own event, which is disgusting.

It’s also what the core studio draggers do.

But yes, it’s not great that these don’t have a changed event. Thanks to the way things are structured internally, it’s actually extremely challenging to introduce a changed event for them, which is why we haven’t already. We still do want to do it eventually but unfortunately this won’t be fixed any time soon.

[PeZsmistic]

That’s disheartening, but thanks for the information. I’ll just have to write an abstraction so I never have to think about this ever again.

Is this an issue specifically with the way GetPropertyChangedSignal is implemented or needs to be implemented? There have been issues before elsewhere with properties not working with this that really should, or the event not firing all the time.
E.g. StudioService does not fire PropertyChangedSignal for ActiveScript when switching back to viewport

[tnavarts]

If you’re curious, basically what it boils down to is that a bunch of public Lua APIs are affected by some of those properties, and thus the source of truth for the property value exists in the core engine code, not in the Roblox Studio code.

However, the StudioService gets the values for these that the Studio interface is currently seeing. That means that if we just naively piped the changed events between Studio and the core engine, the Changed event would end up slightly “out of sync” with the change in the actual property value. Bringing everything back into sync without potentially breaking existing code is a bigger task than we think is worth prioritizing when a reasonable workaround exists.

[PeZsmistic]

Yeah, I was just curious, thanks for explaining. I think I understand; that’s really quite annoying.