You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we all know [FieldChangeCallback] is to instruct the U# compiler use specified property setter to handle a field value assigned from external source such as other udons or remote sync. But there's still a scenario that is not allowed, which is U# compiler don't like I directly assigns the value form other U# behaviors. Although we can use public exposed properties as workaround, but what if others want to use udon graphs to assign the value? This workaround makes the entry point not consistent. I even haven't said using properties require a few more udon instructions at least to get/set a value yet (under the hood).
That's why I want to propose extending the [FieldChangeCallback] functionality to let it specify a method. Instead of (rolling back the original value under the hood before hand) setting the value ourselves, this provides the raw input of the callback. We can use it to hook some event listener etc.
[FieldChangeCallback(nameof(OnValueChanged))]publicintsomeValue;void OnValueChanged(intoldValue){Debug.Log($"The value has been changed from {oldValue} to {someValue}!");}
The text was updated successfully, but these errors were encountered:
As we all know
[FieldChangeCallback]
is to instruct the U# compiler use specified property setter to handle a field value assigned from external source such as other udons or remote sync. But there's still a scenario that is not allowed, which is U# compiler don't like I directly assigns the value form other U# behaviors. Although we can use public exposed properties as workaround, but what if others want to use udon graphs to assign the value? This workaround makes the entry point not consistent. I even haven't said using properties require a few more udon instructions at least to get/set a value yet (under the hood).That's why I want to propose extending the
[FieldChangeCallback]
functionality to let it specify a method. Instead of (rolling back the original value under the hood before hand) setting the value ourselves, this provides the raw input of the callback. We can use it to hook some event listener etc.The text was updated successfully, but these errors were encountered: