• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Body Accelerations

R

revelyn

Messages
6
Country
trinidad-tobago
I've been playing around with the FSX SDK for a few days with great results so far. It's also my first time posting on any type of forum :).

I don't quite understand the BODY ACCELERATION SimVars. I need to read the values of all three but the one I am most interested in is the body acceleration in the vertical or normal direction. That is, the vertical G's that the passenger feels while he is flying.

According to the SDK documentation it seems that the variable that I should be looking at is BODY ACCELERATION Y. I selected to use the "gforce" units instead of "feet per second squared". When the plane is sitting on the ground I expect to see an absolute value of 1G. Instead I see a value of -0.000118 that very gradually tends to zero with time and the plane still sitting on the ground.

Even during an aggressive flight I rarely see the value get close to 1G even though a 60 degree banked turn at constant altitude in a Cessna 172 should register as 2G's.

Is there some sort of offset of 1 included in BODY ACCELERATION Y?

Thanks!

rle
 
revelyn said:
I should be looking at is BODY ACCELERATION Y. I selected to use the "gforce" units instead of "feet per second squared". When the plane is sitting on the ground I expect to see an absolute value of 1G. Instead I see a value of -0.000118 that very gradually tends to zero with time and the plane still sitting on the ground.
Click to expand...

The actual SimVar name is ACCELERATION BODY Y.

The accelerations are NOT forces, but actual accelerations. That is why the ft/sec^2 is a better unit, and less confusing. It means exactly that -- the body is accelerating in that axis by so many feet/sec per second. That will directly affect the VELOCITY BODY Y value, which will be the resulting number of feet per second instant by instant.

You won't get a vertical acceleration of 1G unless the aircraft is in free fall in a vacuum, and even then only if the Y axis is vertical in relation to the WORLD axes -- if the aircraft is pitched or rolled it won't be exactly 1G even then, the Y axis consequently only being one component of the Earthward acceleration..

The ACCELERATION WORLD Y value will be vertical, always, no matter what attitude the aircraft has taken, so that will approximate 1G in free fall (I say approximate because there should be some resistance from the atmosphere of course).

Even during an aggressive flight I rarely see the value get close to 1G even though a 60 degree banked turn at constant altitude in a Cessna 172 should register as 2G's.
Click to expand...

You are confusing force and acceleration. In such a turn whilst the force acting on the folks in their seats may be 2G, there is an almost equal and opposite force from their seats back, as the aircraft actually performs the turn and remains in flight. The acceleration of the aircraft in the Y axis is actually "upwards" (towards the centre of the turning circle), and will obviously be much less than 1G.

It you don't understand this, take a look at the VELOCITY BODY Y and see how that changes. It is the acceleration in the axis which changes the velocity, naturally.

Regards
Pete
 
Thanks so much for your feedback Pete :). I am very enlightened now. I was definitely mixing up my forces and accelerations. I am going to use the "G Force" SimVar as Tim suggested.

rle
 
fitzgeba said:
1G = 32.2ft/sec^2
Click to expand...

Not really. 32ft/sec^2 is the acceleration of an object subject to the FORCE of gravity, which itself would probably be measured in Newtons.

However, I'm sure that this is exactly why the confusion arose. Best to think of the acceleration values provided by SimConnect as accelerations (which they are), without the gravity connotation (which they certainly don't possess) to avoid such confusion.

Pete
 
Last edited:
Guess I'm about 14 years late to the party,.... :)

I stumbled across that same issue in FS2020 and would like to share some thoughts, in case other developers run into the same thing in the future:

What @PeteDowson said above is generally correct for a simulated FSX/P3D/FS2020 aircraft in flight. However, up until late 2021 the SimVars "ACCELERATION BODY X/Y/Z" contained a bug that would disregard some external forces for their calculation, like braking forces from the landing gear, for example. That resulted in accelerations showing, even though the aircraft was still stationary (!!) on the ground with parking brake set. This bug was fixed in FS2020 in late 2021. I didn't check FSX/P3D though.
On top, the values "cut out" to zero below a certain threshold. Not a big thing for gamers, but can become a showstopper for some people who want to do more serious stuff with a sim, like driving a 6DOF motion platform, or deriving aircraft performance charts from flight data recordings. This bug is still present as of mid 2022.

Simply put: The values you get from "ACCELERATION BODY X/Y/Z" do not contain any component of gravity.
And for the pros: "ACCELERATION BODY X/Y/Z" (as far as they are correct) are coordinate accelerations against a fixed frame of reference. They are NOT proper accelerations against an inertial frame of reference, like a childishly naive aeronautical engineer would expect. The simvar "G_FORCE" IS a proper acceleration. But, the fact that it is not given in X/Y/Z components makes me suspect it represents the total acceleration, and not the vertical component ot that.

The solution is to add gravity. You can do this by first calculating the gravity component along the aircraft X/Y/Z axis:
GravLat = Sin(bank) * Cos(pitch) * 9.806 [m/s^2]
GravVert = Cos(pitch) * Cos(bank) * 9.806 [m/s^2]
GravLon = Sin(pitch) * 9.806 [m/s^2]

...and then add those to the coordinate accelerations:
AccProper_X = ACCELERATION_BODY_X + GravLat
AccProper_Y = ACCELERATION_BODY_Y + GravVert
AccProper_Z = ACCELERATION_BODY_Z + GravLon

Don't mess up the signs and/or units though :)

My personal interpretation:
MSFS started in the 80's as a game. Made by game developers - for gamers. And for game developers it makes perfect sense to interpret acceleration simply as the change of velocity over time. I guess that's how the simvars "ACCELERATION BODY X/Y/Z" were intended to be used. Now in 2022, Asobo are developing this game further. More into an actual sim rather than a game. I think it clearly shows in their communication that that is their goal. And from their CVs you can tell that they know what they're doing. However there's still tons of legacy code running in FS2020 and with it some game'ish design choices made over the past decades. I hope that at some point they will find time to update the SimConnect interface to reflect that progression from game to sim.

Take care....
 
Last edited:
JoeDirt said:
MSFS started in the 80's as a game. Made by game developers - for gamers.
Click to expand...

Might want to actually learn the history of Flight Simulator and it's origins, because this statement is actually totally inaccurate.
 
FYI, vehicular suspensions and for that matter, wind tunnel testing, are all performed from the basis of Euclidean space. That's right, when trying to understand how a motorcycle fork dampens, the motorcycle is interpreted to be "stationary in space" while an extremely bumpy world passes by underneath and suddenly, rebound and compression make sense. I think you can see that gravity, as a vector, would be a meaningless extension of decimal places and I would not be at all surprised to learn that an actual, real, airplane isn't released into "spacetime," until it is fully developed and prepared within the loving womb of Euclidean space.

As to observations of your observations, I'll endorse and offer my own. In many ways, I believe Asobo has reduced, or reversed development, by reducing fidelity on material UV constraints, for example and in other ways, Asobo's coarse approach to development has destroyed, or invalidated some of the intricate developments of BAO's original simulator, like AI traffic.
We see a strong emphasis on visuals, which is great for a biplane simulator and the rest to be made up with out of sim processes. People train for actual, real flight using P3D, I don't believe that is even possible with MSFS. Almost two years into this version of the sim, now and an incredibly detailed and intricate AI system is in shambles. It is, in a word, "deplorable."

Thank you though, for your calculations. You can help fill the gaps between the designer and current developer. I endorse you to Google "Bruce Artwick Organization .bgl" to learn more about the origins of the sim.
 
WarpD said:
Might want to actually learn the history of Flight Simulator and it's origins, because this statement is actually totally inaccurate.
Click to expand...
:) I think you're actually totally right with that assessment! :) But are the precise times/circumstances really all that relevant?

- MSFS is old
- Not designed to be an engineering tool
- Has some peculiar shortcomings that Asobo will hopefully adress at some point
- Can still be used for a lot of cool projects if user willing to work around some minor issues here and there

...is really all I'm sayin' here 🤷‍♂️

Take care 🙋‍♂️
 
Your assumption is that the current iteration utilizes the same code as the original iteration. It does not. The original was written on an Apple IIc which utilized a 6502 CPU (8-bit). The Commodore 64 version was on a 6510 CPU (8-bit). The IBM PC XT version was on a 8088 CPU (8-bit). That code was remarkable in that it showed simulated flight on "state-of-the-art" desktop computers. That's actually quite a feat engineering code wise, and I challenge anyone to accomplish something just as "cutting edge".

There were changes to the core sim (I believe around v5, could me mis-remembering... old age does that!) that changed the way aircraft were defined as well as how scenery was created and defined. So at that point it was no longer the same sim that was originally created by Bruce Artwick.

The Asobo version (the one currently called MSFS) has it's own flight dynamics engine, as well as the legacy flight dynamics engine from FSX. It also has it's own world generation engine that does not use anything from any prior versions of the sim that I'm aware of. It has lots of issues, primarily because Asobo did not use the original FSX sim code as it's foundation. They started from scratch. Now, it's my understanding they have access to the FSX code, but I do not believe they've used it other than to support the legacy flight dynamics engine (an option you have to enable).

So, MSFS is only old in name. It's code has changed through the years, and the current version is the largest change of all.

At no point is any version of Flight Simulator designed to be an engineering tool. If it was, none of us could afford to purchase it.
 
You must log in or register to reply here.
Back
Top