Let's convince Asobo to provide proper motion data

Hey there

I'm trying to convince Asobo to provide proper motion data for export through their SimConnect interface and I was hoping to get some of you guys who are intersted in FS2020 to support (aka "upvote") my issue report that I have provided here:
https://forums.flightsimulator.com/t/simconnect-semibody-loadfactor-x-and-z-not-supported/273198

In short: Acceleration onset cueing needs the proper accelerations and vehicle referenced angular rates to be exported. The angular rates are all available , however the proper accelerations are not. At least not on all axises.

The proper vertical acceleration is available as "SEMIBODY LOADFACTOR Y", but the X and Z axises are not (yet) supported. Even data that would allow me to derive the necessary data (world positions) is not available.

Would be great if people supported this

Cheers, Dirty

---------------------------------------------------------------------
Edit July 2022:
The sim variables in the export interface got fixed and the necessary data can now be calculated. I'd say that pretty much fiixed the issue for me. Thanks everyone for supporting!
----------------------------------------------------------------------

You got my vote, @Dirty.

The problem is that Semibody_Acceleration_X and _Z are not available for export. At least they weren't last time I checked, a few weeks ago.
Yes, you can export some data out of MSFS2020 and get some motion out of it. And if some motion is what you want, then MSFS certainly delivers some. But unless proper acceleration data is available, this motion will not reflect the accelerations a person on the vehicle would experience.

However, the angular rates are available, so at least rotations should work fine with the data available.

I have a vague idea how it might be possible to derive the proper accelerations from geographical coordinates, but that is a pretty far shot.

I don't understand why ACCELERATION BODY (Acceleration relative to aircraf) x/y/z is not enough. on my end they are working as I expect.

Hey @Wagnard

There are two reasons why ACCELERATION BODY X/Y/Z in FS2020 is unusable:

1. First of all, they try (and at that even fail) to be "coordinate accelerations". Coordinate aceleration is acceleration relative to a fixed frame of reference (a coordinate system). In this case the fixed frame of refenence is the aircrafts own local coordinate system: X = left, Y = up, Z = forward.
   Think of it like this: The aircraft has a velocity vector in space. Now, there was SOME acceleration acting on the aircraft that brought it to its current velocity vector from the previous frames velocity vector. This acceleration was ACCELERATION WORLD X/Y/Z. Now take this vector and project it onto the aircrafts 3 local coordinate axises. The lengths of these components are the three numbers that you get when you export ACCELERATION BODY X/Y/Z.
   This data describes what you would feel (or measure) if you were on a vehicle that followed this exact trajectory in zero gravity. Coordinate acceleration is not usable for motion cueing directly, because it does not contain any information about gravity.
   Coordinate acceleration is great for game developers however, because it allows to describe and calculate trajectories in euclidean space (xyz-space). That's the space a game developer and your GPU "thinks" in.
   Motion cueing on the other hand requires proper accelerations. Those are accelerations relative to an inertial frame of refernce. You could easily convert coordinate acc. to proper acc. if it weren't for the fact that.....
2. The SimVar ACCELERATION BODY X/Y/Z is bugged. And it has been for at least the past 20 years. I suspect it has never been correct, but I can only trace it back to FS2K.
   You can reproduce it easily by putting an aircraft on the runway, set the parking brake, advance the thrust levers and read ACCELERATION BODY Z. You will see longitudinal acceleration increase even though the vehicle is fully constrained and remains stationary. On top of that the values simply cut out to zero below a certain threshold. I assume that is an artefact of a poorly implemented verlet integration (or similar integrator), but that is pointless speculation.

...and then there are a few dozen other issues I have with FS2020, but that's a few dozen different stories

I was hoping FS2020 would be an actual fightsim, but it is a game . Made by game developers, for gamers. There is not a single aeronautical engineer on the team. AFAIK, no instance of the MSFS line of products has ever been certified for flight training by an aviation authority anywhere on the planet.

That being said, I heard rumours that Asobo are at least aware of the bug in ACCELERATION BODY X/Y/Z.

Btw, proper acceleration can still be derived from VELOCITY WORLD X/Y/Z. It is not as precise as getting it natively from right out of the physics engine (it jitters a little and has to be filtered), but it sure beats using wrong data or having no data at all.

Cheers

You got my vote.

Hey
Long time no update here. I'd like to mention that those rumours have turned out to be true, and the bug was fixed about a year ago in May 2021 with Sim Update 4.
So at least the data that is provided is now correct and usable. No more accelerations showing while aircraft constrained on ground

This means the proper accelerations can be calculated easily, just add the gravity component. I see them available in Mover, and as far as I can tell, they are correct. I also use them in my own software and they work great.

No need to upvote anymore.

Cheers,... Dirty