/*public*/ virtual void PostEditChangeProperty( struct FPropertyChangedEvent& e );
to both FAnimNode_Custom and UAnimGraphNode_Custom and neither of them get called whenever I modify the NumAdditiveAnimsUsed variable in the editor, what else do I need to do so I can get the callback ?
Also, is there a way to prevent engine rebuild in case I accidentally modify a .h or .cpp from the engine source code ? I did that recently and had to wait for like 40 minutes to rebuild it all. I think the build tool doesn’t accurately detect what file was changed in order to just recompile that one .cpp and just relink everything.
Since FAnimNodes are UStructs, they won’t have the features of UObjects, namely PostEditChangeProperty callbacks. On the other hand, the UAnimGraphNode editor wrapper is a UObject, but the property you’re trying to monitor is inside the FAnimNode struct which is the actual property being raised. You might be getting PostEditChangeProperty, only to find that the modified property is not NumAdditiveAnimsUsed but its Node parent?
In any event, there’s a different callback you can use to watch inner properties like struct or array contents: PostEditChangeChainProperty. It’s a bit more complicated to use than PostEditChangeProperty, but it lets you know which inner property is being modified as well as its outer.
The build tool is working just fine, it’s just that most engine includes are at some point included in a large precompiled header file. For instance, touching anything that is included in EnginePrivate.h will essentially trigger a full rebuild. I have wondered in the past how engine programmers at Epic manage compilation, but my guess is it’s a combination of selectively editing these precompiled headers along with IncrediBuild handling the first large recompilation that ensues.
edit: If you’re frequently modifying some engine headers, you can probably do a solution search to trace them back to their module’s precompiled header and exclude it from there. This in turn might lead to missing include errors, but it is my understanding that Epic has been making passes to reduce include dependencies.
I used PostEditChangeChainProperty too however, should I get a callback whenever I modify things in the blueprint editor or just in-game because I did only test with the editor running.
The property change callbacks are strictly for modifying a property in the editor. In fact, the callbacks are wrapped in a WITH_EDITOR define and your game module will fail to compile if you don’t do the same and have the override keyword set (you should). If the engine automatically issued events for every single modified uproperty at runtime, the overhead would be insane. (Though I’ll admit it would be nice to have a keyword that implicitly adds such callback logic, much like the replication keywords do.)
If you want to be notified of value changes at runtime, then you should hide your property, wrap it in a setter + getter pair and have the setter also call a function or delegate.