Hello @b1e1n7e and @exil35,
I looked into this issue more carefully, and there are a few important points to clarify.
__________
First, regarding ROTATION VELOCITY BODY:
I cannot reproduce the persistent replacement behavior that Benedict described above. A single write changes only the current angular velocity, effectively resetting the rotational state, but from the very next physics tick onward the rotation continues evolving under the native rotational dynamics. This is true both when the new empty_inertia_tensor parameter is used, enabling the corrected rotational model, and when the previous rotational model is used.
My earlier mention of angular velocity was only intended as a hint that you could derive the actual angular acceleration from consecutive angular velocity values, not as a recommendation to use angular velocity as a control input. I understand that this is not entirely straightforward and leaves room for errors, particularly when dealing with body-axis conventions, signs, and units.
Could you please provide a minimal example showing the persistent takeover you are observing, including the exact write sequence and update frequency?
__________
Regarding ROTATION ACCELERATION BODY,
the legacy behavior was not a direct override either. On the physics tick following a write, the applied acceleration was:
(native acceleration + written acceleration) / 2
After that tick, the written value had no further effect unless another write was performed.
This is likely why you observed a mixture of the native rotational dynamics and your corrective input.
So we first need to clarify which behavior is actually required:
- Option 1: the previous one-tick legacy acceleration blending;
- Option 2: an exact replacement of the total angular acceleration for one physics tick;
- Option 3: an additional rotational effect applied on top of the native dynamics through an additive torque, either for a single tick or continuously until reset.
Please note that restoring the legacy processing rule would not reproduce the same aircraft response, because the corrected full-tensor model uses different native rotational dynamics from the legacy model. You can find more details about these changes in the SDK documentation here:
[Tensor effects].
Also, please note that Options 1 and 2 would affect only the next physics tick. With the physics engine running at approximately 100 Hz, a single acceleration input produces only a very small change in angular velocity, as I observed when testing the previous model. Therefore, infrequent writes would require fairly large input values, especially with Option 1, where the written value is averaged with the native acceleration. Smaller corrections would need to be applied more frequently.
More importantly, directly modifying the acceleration calculated by the engine would, on the affected physics tick, break the consistency between the applied torque and the evolution of angular momentum, which is one of the key benefits of using the corrected rotational dynamics. It would also bypass or distort the inertial-coupling effects represented by the full inertia tensor, largely defeating the purpose of using it.
Option 3 avoids these issues. Applying an additional torque preserves the correct influence of the inertia tensor and keeps the angular-momentum evolution consistent with the total applied torque. It also provides a more flexible and physically meaningful way to correct or extend the rotational dynamics and aerodynamics than directly prescribing angular acceleration. However, it would require some work on your side to adapt your existing implementation to this approach.
The solution I am currently considering is:
- a) keep the current behavior unchanged by default for existing aircraft already using the full tensor, to preserve backward compatibility;
- b) add an explicit configuration flag to optionally re-enable the existing acceleration SimVars with the legacy one-tick blending semantics;
- c) internally convert the resulting acceleration correction b) into an equivalent additional body-axis moment, so the full-tensor dynamics remain effective and the angular-momentum evolution remains consistent with the total applied torque;
- d) expose writable additional body-axis moment SimVars as the recommended interface for new implementations.
I understand that your current implementation may have been fine-tuned around the legacy one-tick blending behavior, so moving to a torque-based input would require some adaptation and re-tuning (although, as mentioned above, some re-tuning may already be necessary because the corrected and legacy rotational models behave differently).
However, omitting points b) and c) and implementing only point d) would substantially reduce the implementation complexity and the time required to provide a solution.
Could you let us know whether adapting your implementation to the torque-based approach described in Option 3 would be feasible for you, or whether preserving the legacy blending behavior is essential for your existing products?
Best regards,
Andrey / Asobo
