The "standard"/obvious usecase is broken.

[VladimirMarko]

This is more of a question than an issue with the code.

If use the plugin to add a SetRotationExecuting event to Transform and then add a handler to a transform, the following happens:

1. transform.rotation = Random.rotation; causes the handler to be called.
2. transform.Rotate(Random.insideUnitSphere); does not cause the handler to be called.

Does this mean that I need to monitor the whole chain of localRotations and parents instead of just the one rotation I am interested in?

This would require a bit of quite gnarly code and I am not sure that I am not missing something else I would also need to monitor.

Did you solve this problem in your Unity.TransformChangesDebugger.API?

[handzlikchris]

It's down to how the tool works, it's very simple it just adds events - there's no smart monitoring at all.

It changes actual property in UnityEngine.dll, and injects events for setters, eg set_Rotation(rot). Which you call via transform.rotation = .

From what I can see Rotate method will call as you've already noticed localRotation. You wound need to work from there to support your usecase.

It may be working better in Unity.TransformChangesDebugger.API but not 100% sure if that's exectly what you're after.

That other tool works slightly different as it rewrites (in-memory) your code that's calling either setters or methods manipulating transforms directly (full list here https://github.com/handzlikchris/Unity.TransformChangesDebugger.API/blob/master/Runtime/Patches/TranspiledMethodDefinitions.cs)

And then it'll acually build a changes-history for you. You'd need to check if changing parent rotation will trigger any changes on children - I've got a feeling you'll just get a 'mismatch node' on global rotation when that happens.

Still with that history entries it'll be much simpler for you to work out child-rotation changes that were acutally caused by root-parent rotation change.