It’s difficult to know where to start. Clearly the SDK Documentation needs to address specifics on how to utilize the many parameters available. Without explanations, creating an accurate flight model and accurate engines is next to impossible. First tier developers have to go outside the SDK and custom code to get results they want. That is not how it should work!
Asking the community of developers to describe where the SDK is lacking is not appropriate. The developer’s role is to create aircraft with the tools created by and described by Asobo. Asobo should certainly have an aerodynamics expert on staff as well as someone with flight dynamics experience developing aircraft using Asobos tools. These individuals should be side by side, working together to determine the problems Asobo is asking the community to discover and creating solutions. They should have a coder and an SDK writer at their disposal. Let’s call them the Flight Model Development Team (FMDT). They need to be making determinations such as, "this is inaccurate, this is redundant, this is unnecessary, This needs good explanation, etc., etc. The list could go on.
A Flight Model Development Team could go a long way toward solving the frustration of Aircraft developers.
You beat me to it
Whilst I agree with you about the developer’s role (and from both our discussions and chats with others behind the scenes the complete lack of communication about the flight model is hurting a lot of people from many dev houses), I will paste below my post from the original thread that was ‘sidetracked’, in order that it is here and can hopefully be a starting point to getting this awful situation addressed:
You asked for specifics as to where the SDK was lacking, because you had heard that mentioned but never been given such specifics. I touched on it in my earlier post, but with the DA62 project open in front of me here are some pointers as to why people may be suggesting that the SDK is lacking in detail. Or actually, just lacking . . .
Obj ea1 surface:
Position ok
Direction ok
Span, sweep, incidence, dihedral, twist ok
Can dihedral take a negative? The tailplane couldn’t in 2020, but there are plenty of aircraft out there with such a thing so it would be nice to know anhedral is accounted for.
Stall alpha - okay
Stall alpha ff - Fuel flow? Free flight? We need to know what your abbreviations mean.
Element weight - ok
Element spacing - means absolutely nothing to me. I am defining one object. How does a single object have spacing?
Element width - ok
Element number - how is a coordinate relevant to this?
Size - ok
Relative position of the surface - ok, but could do with confirrmation that this is relative to the model centre position.
Surface Cx - ok
Surface Cx normal - well surely that is just Surface Cx, already defined?
Surface Cx efficiency - no idea at all.
Surface Cx nscalar - no idea at all
Surface Cx npower - no idea at all
It may interest you to know that a google of the three Surface Cx directly above gives nothing relevant to aerodynamics but the last one does lead me to an energy supplier for my electricity . . .
Compliance - no idea.
Damping - does not make sense to have a single damping effect without specifying in which directional plane it applies that effect.
Hard depth - absolutely no idea.
Front scalar, back scalar, front scalar ratio, back scalar ratio all mean absolutely nothing without explanation. The first two are already a scalar on something, and then a ratio on a scalar???
Dim Scale I mentioned previously - needs clarity or at least a note about how it functions.
Linked behaviour index - absolutely no idea.
Surface angle (deg) - no issue at all.
Modifier - modifier of what?
Modifier angle scalar - so that’s a scalar to the angle of the thing I don’t know?
Modifier position scalar - as above, but to the position of the thing I don’t know?
Modifier surface relative position scalar - do I really need to . . . ?
Group - presumably binary, but there appears to be no description anywhere of what each index is?
That is just ONE file out of several, which we are expected to use to build objects within the flight model. I would say that at leat 3/4 of it is not documented, not standard aerodynamic theory and not straightforward to understand.
This is where you get the comments along the lines of the quote in my previous post about flight dynamics currently being a “hostile environment”, combined with the fact that many flight dynamics questions in the later stages of 2020 (the last 18-24 months) were seemingly met with a wall of silence.
There is a strong feeling amongst developers that the SDK is inadequate. There is an even stronger feeling amongst those of us that work solely in flight dynamics that the SDK is pretty much non-existent where it matters. It’s very pretty, with descriptions and pictures of boxes around points. It is very comprehensive in the theory behind how it works. But it gives us NOTHING to tell us how to put Asobo’s ideas into practice.
To go a stage further and talk about the implimentation of defining the shape - how on earth are we at a stage where the simple shape of an aircraft requires the complex nature of all the confusion above? Why can we not just load the wireframe model in an editor and drag the points to surround the shape precisely? Then have a modifier file for aerodynamic behaviours?
I think “hostile environment” is an understatement.
There are plenty of posts with questions about the FS2020 flight model SDK that have never been answered.
Be that as it may, Eric asked for this thread.
I am working on a jet transport which I had previously done Flight Dynamics for in FSX and P3D. Of course the wireframe idea is an attractive one but very small detail effects on real aircraft have enormous effect. Example is the development of the P-38 was stalled with a severe tail buffeting caused by the interference between the “car” and the inner wing. Careful filleting was necessary, to small to wire frame! The small stall strip on the F4U 1A changed stall a lot!
Yes the definitions and lack of explanation make most of the “tools” useless. I am lucky to have good data and the experience of thousands of hours as a real Captain on the plane I am modeling. So lots of test flying and adjustment to meet the documented parameters (I have a good stack of my manuals).
That bindings and auto flight functions are a moving target on shifting sands does not help.
Thank you for your post - whilst I think you misunderstand my comment about the wireframe you make some very valuable points.
To address the wireframe, it is important to understand that Asobo stated in the 2020 SDK that accurate definition of shape is key to making an aircraft fly correctly in their game. The ‘slightly better’ ability to define shape in 2024 is what I was referring to with my comments about dragging points around a wireframe - the fact that we cannot and instead have to spend many hours defining individual points is just another example of an unnecessarily unwieldy and convoluted flight model when actually it should be a very simple process.
I do not believe that the creation of a precise shape will give us accurate behaviours. Your example is a perfect one, I will also give you the Avro Vulcan B2, which has a very specific mach tuck countered by a mach trimmer. The trimmer begins to function at 0.87M and above 0.95M there is little aft stick left to counter so the aircraft (if still accelerating) would pitch down. This is a repeatable process which in real life can be precisely defined and is identical in terms of pitch effect v mach every single time it occurs. Yet Asobo’s core flight model is not capable of reproducing this with any accuracy, if at all. The table which was used to define this effect in FSX and prior no longer functions. Realistic, accurate flight modelling is therefore no longer possible in many areas - this is just one example, there are many more!
I think the only real use of the ‘accurate’ shape is to interact with the weather. We still need the ability to define all aerodynamic behaviours over the top of that, using known and understood aerodynamic theory as seen in FSX and aerodynamic papers such as Roskam’s “Airplane Flight Dynamics and Automatic Flight Controls”. What we do not need is modifiers that aren’t clear what they modify, then scalars on those modifiers. Most of the elements we can now adjust in the flight model are made up by Asobo and have no explanation anywhere.
Such as “What do Asobo expect the flight modeller to do when the accurate dimensions input do not give the known, defined behaviours?” I think it must be over two years that I’ve been waiting for an answer to that one . . .