When using GetPropertyChangedSignal("CurrentAngle") for HingeConstraint, it doesn’t fire. I tried doing it with the .Changed event as well, and that didn’t work either.
Hmmm, CurrentAngle is a read-only property that only updates itself whenever you ask for it. It is basically a UI property only. It doesn’t know when its changed. If CurrentAngle changed actually fired, there would be cases where it would fire 240 times a second.
I’ll ask internally if we’ve ever intended it to be used the way you’re trying to use it, but at first glance I do not thing so.
For properties of objects that are constantly changing, you may as well poll them on a Stepped/Heartbeat loop, since you expect that they will update every frame anyway. (unless the parts are sleeping?)
Those properties only fire the Changed event when they are written to. Like CurrentAngle, they don’t fire Changed when updated by physics. Since CurrentAngle is readonly, and will only be updated by physics, it will never fire the Changed event.
Khan is saying that currentangle doesn’t actually update on the physics step and instead updates only when you read it. My suggestion is to make it update on the physics step, but not fire generic Changed, like Position currently does.
It theoretically could but all other properties driven by simulation fire neither Changed nor specific per-property Changed, right? (including Position, Rotation & CFrame)
I believe these properties do indeed fire Changed and their corresponding property changed signals. Alternatively it might make sense to update on physics step if somebody is listening to the changed event depending on how costly the calculation is?
When simulation runs, CurrentAngle will always change, unless the parts are asleep. It is therefore pointless to fire that signal. Also CurrentAngle is a derived property - meaning it can be computed from other properties: CFrames of the parts and attachments and properties of the constraint.