Dr400 pilot here. The plane in the game behaves just like you may expect it (maybe a bit slow on the roll speed, but I’m not even sure). I love the way you can keep its nose up during the flare, and this feeling that the plane will never touch the ground until you let him.
It was a contract requirement from Microsoft on Asobo. Asobo would not have included it given their druthers. After I pointed out their discussions and comparisons with X-Plane in the Flight Model Description in the SDK, they scrubbed a lot of interesting information out, which is what my comments are based on, but, basically, Microsoft required them by contract to include a mode which allowed FSX aircraft to act the same in MSFS as in FSX. Of course, we’ve all seen that this didn’t work out so well.
So, the answer is yes, I believe the intention was to support port-overs. Unfortunately, there’s more to an aircraft than its flight model, and the conversion of cockpit gauges etc has never worked well and was basically abandoned.
They should just remove the Legacy flight model option. It’s silly. Or move it to the developer mode if it’s really helpful. I have no idea why they continue to keep it facing regular users.
Regarding BET, MSFS’s flight model is light years ahead of X-Plane’s, and is in fact quite similar in basis, but allows many, many more surfaces to be involved in the calculations of lift and drag than X-plane does (I forget off the top of my head, over 1,000 vs 10, something like that). Unfortunately, the X-plane comparisons have been removed, but if you can find an old copy of the SDK and the description of the Flight Model, you can see what I mean.
And, yes, Asobo is not done yet with the flight model. There’s a huge amount of extensibility built into it and there is a long list of features they have yet to implement. And to those who claim Asobo isn’t interested in Aviation, have you watched any of the developer Q&A’s? They’re all pilots and at least Jorg (and Seb?) I believe owns a plane.
Voted on that one already🙂
Thinking about it, removing this option might create another problem.
During the latest install a few of my aircraft did handle very strange.
To fix this issue I had to switch to Legacy and back to modern.
There seems to be a tendency amongst some XPlane users to present blade element theory as some sort of recent development in aerodynamics, offering prospects for accuracy in simulation that cannot be achieved through other means. This is however far from the case. Blade element theory dates back to the late nineteenth century, and has long been surpassed by more advanced techniques for modelling in fluid dynamics. Accordingly, while I think there is much to be said for the way XPlane uses this methodology in its flight modelling, the fact that another simulator uses other techniques need not indicate any deficiency at all. I have seen good flight modelling, and abysmal, in both XPlane and MSFS, and nothing I’ve seen so far suggests that one is inherently better suited to doing the job than the other. We should judge them both by the results, for individual aircraft, and not on the basis of marketing hype over specific technology. And perhaps it might be better to do so with an eye to the potential for future developments, since MSFS flight modelling is clearly still in a state of flux. XPlane took a long time to get to where it is today, and I see no reason to think that MSFS can’t also show the same potential for improvement.
This has needed to be said. X-Plane did not invent blade element theory. In fact, their application of BET is nothing but a glorified strip theory method. There’s nothing wrong with that, but that is what it is.
I think it’s funny when people say that this blade element method is inherently superior to the MSFS aerodynamics model. If you take away all of the kludges, it’s not that sophisticated. Literally, X-Plane takes 10-20 slice cuts of wing and stabilizer surfaces and calculates the forces on each slice. Each slice is a 2D airfoil. Sounds great, especially for long slender wings with large aspect ratio. I don’t know how they are handling crossflow effects, because each 2D slice is totally independent of it’s neighbors, but there’s probably some kludge there.
MSFS, on the other hand, is actually discretizing a surface representation of the airframe into almost 1000 elements, and solves for the aerodynamic force on each element. This is what’s called panel or boundary element methods. Less sophisticated than full-on Navier-Stokes calculations, but far more precise than a strip theory method. Wonder how the big aerospace manufacturers designed airliners back in the day without the CFD we have today? Panel codes. Of course, back then, solving for the forces on 1000 elements probably took them days. Now, we can do it in mere seconds.
Great Post! Demystifying the glamour behind the BeT that people has been mentioning for years as the recipe for perfect aerodynamics…
What MSFS is doing is very advanced, I can see a LOT of potential. It’s just a matter of needed maturing process, correcting for the deviations from expected results that still exists, and it can be a really good end result!
This BET is complicated stuff… I don’t actually know if it connects properly to scientific BET work, but below are the inputs for the current propellor model in MSFS… I did some tweaking with the beta_range variables yesterday, I found beta_range_min and beta_range_max guard the angle of the propellor blades. These were the inputs I tested and what I can say now: they are active, flight changes when you put other values in.
minimum beta_range 11 maximum 43 is default
put the minimum on a negative value, throttle won’t work at all (no forward speed)
put the minimum lower than 8 you won’t be able to take off
put the minimum on 8 or 9 makes the aircraft slower
put the minimum above 20 you loose the drag when taking back throttle
With the minimum set on 11, there some drag while lowering throttle. You’ll notice when you put the min beta range on higher values, you loose that break. Steep descent toward landing will give much more airspeed.
I used in the Modern flight model… i used SDK DA-62
The sim just needs some prop drag modelled, feathering to work, turboprop engine simulation still needs work and helicopter/VTOL (or rotatable thrust vectors) and we’ll be fairly close on the dynamics of this sim. There is still quite a bit of fine tuning to be done, especially on the default aircraft, and moreso on the premium aircraft. Mods have helped this quite a bit though.
Did you just read the post above? Prop drag IS modeled and works. Perhaps not to your satisfaction, but it IS there. @ArcanePython931 just proved it, and the developers have talked about it a couple of times now (that it was always there). Granted, not everything about controlling it was previously exposed to developers, at least not in an understandable way, and they said they are addressing that, and much work was done in that area for SU4 (but not all that is needed).
The developers have said that all that is in the plan over the next three Sim Update releases. So, we’re looking at 4 to 6 months to get a lot of stuff in. But it is there, and they ARE aware of what people are saying and dilligently working to make it all work better, both everything related to beta mode on props and proper turboprop engine modeling (much of which was fixed in SU4, but there is still more to do and planned).
All these people keep coming in here and saying “ahhhh, there’s no prop drag”… based on what? Until @Arcane did the work, I haven’t seen one post proving scientifically that the floaty issue so many complain about is due to a lack of prop drag.
I’m not smart enough to know how to prove it, but, please, if you’re going to state something, prove it.
And, quite frankly, Asobo is going to read these things and say, well, we modeled prop drag, we can prove it’s there, and they’re likely going to ignore the rest of any discussion because there are other things to worry about.
@Flyingscool I only provided proof that the beta_range is active part of the MSFS propellor model. I have not proved yet it can be used for tuning propellor drag (the interesting question in the other topic) or that MSFS complies to BET or correctly implements BET, which dictates a negative beta_minimal would provide reverse thrust. When I put beta_minimal on a negative value, the aircraft would not take off so I think they apply beta_minimal on takeoff (throttle+). But I think MSFS does have a working propellor model !
Haven’t tested the feathering angle. It belongs to the propellor model. The Beta feather parameter in above list is an angle of 80 degrees, which puts the blades in their own wind, stopping rotation more quickly when you take back throttle. Wiki sais it is needed for engine failure situations. It stops the windmill energy loss, the air can flow right through at 80 degrees, so I don’t think it would give extra break. On some aircraft there’s a switch to activate feathered propellors, so it could be used in flight.
There’s a LOT of work. Maybe the propellor model is already there… and it is just a matter of updating parameters to finetune it to each aircraft. DA-62 is no turboprop, but these beta_ parameters certainly have an effect on the simulated propellor… I leave the test to the experts, I’m not used to turboprops.
Helicopters are a different ball game. Hope they’ll keep them separate, don’t mix things up !
I mean the military uses XP to figure out how their models would work in the real world. Shouldn’t that be sufficient and a good clue on how well XP has BET modeled? The military uses the best of the best things for simulations. Yes the technology is old though. I’d love to see a video of XP vs MSFS in real world aerodynamics. I’m trying to learn and not be arrogant here and will switch over to MSFS if there is a valid argument on this point.
Couldn’t it just be the case that xplane was the most realistic at the time.
The SDK used to have a comparison of a lot of the differences between X-plane and MSFS’s flight model in the flight model discussion. They took it out when they redid the SDK a couple of versions ago.
I’m only responding to the “There’s no propeller drag”. I just want to see proof of the “none”. Mostly, I hate it when people claim things without proof (“See, in the wind tunnel model in the developer mode, when I change the angle of the blade, there’s no effect on the total drag on the airplane” That would be proof, something measurable). Asobo has claimed multiple times there IS drag associated with the propeller. It seems like you’ve proven there is some drag. The claim is “See how the C208 floats down the runway, that’s OBviously because there’s no propeller drag”… Really? Couldn’t it be other factors?
Making claims without proof is useless.
There are definitely issues with the propeller model, and with using Beta range. But Asobo has discussed this, and they’ve charted out when they’ll be fixing it. How well they fix it is anybody’s guess. But I trust they will make an effort, and will eventually get to something useful.
Yes, they do. You’re right. I work in the industry as a modeler. I’ve seen researchers use X-Plane for a variety of topics, including flight test verification. This strip theory model holds up just fine. No one is arguing that it isn’t. For posterity, here are a few articles which show X-Plane’s application for such a thing:
But to say that jamming their model into MSFS would be a be-all, end-all fix to the flight model issues MSFS is having is not really a good or necessary solution in my opinion. I say so because we’re really just talking about the choice of method for calculating the baseline aerodynamic force and moment calculation here. Both methods do the same thing - they chunk up a sub-model of the flight vehicle and come up with forces on the elements based on the current environment. My argument is just that MSFS starts this process with a much finer discretization of the flight vehicle than X-Plane, which probably buys us a lot of fidelity in certain situations. It means that MSFS is doing a better job at capturing the local variations in aerodynamic force over the flight vehicle surface, which can make a difference in terms of fine grained perturbations in the air mass model. I am hoping MSFS will improve their SDK to help us gain a better understanding of what exactly they’re doing under the hood, but the framework seems very sound from what they have shown us so far.
All in all, the issues we’ve all been complaining about as a community really have less to do with the baseline aerodynamic force calculation, and more with the corrections needed to make the flight dynamics model feel more realistic. These corrections are not BET. They’re just such things that the baseline aerodynamic calculation doesn’t do a great job with, like supersonic drag corrections and all those additional handwavey kludges Austin put in their sim in version 11.40. Laminar Research has had to go through these over the years, and so will Asobo.
Have you ever been in the military??? After 22 years of service I find the comment that the military uses the best of the best to be hilarious … sorry, but that isn’t a point I would use to support any argument.
I’ve seldom seen such a ridiculous claim on a flight sim forum. The military (or at least, the military of any nation capable of building a modern combat aircraft) has access to professional computational fluid dynamics software, and the hardware to run it on, and doesn’t need to resort to consumer-grade entertainment simulators to figure anything out. At least, not once they have got past the drawing-sketches-on-the-back-of-an-envelope stage.
I’ve seldom seen such a ridiculous claim on a flight sim forum. The military (or at least, the military of any nation capable of building a modern combat aircraft) has access to professional computational fluid dynamics software, and the hardware to run it on, and doesn’t need to resort to consumer-grade entertainment simulators to figure anything out.
Except, they often still do. It’s good practice to make use of any reasonable analysis tools to get the answer you’re looking for. Doesn’t matter if they also have CFD. You can’t efficiently run a CFD model and a 6-DoF state model, but we obviously have an abundance of evidence that you can run a lower-order aerodynamics model in place of that CFD and get a real-time answer. If you’ve got multiple tools at your disposal, use them all and compare them against one another.
That’s the back-of-the-envelope stage. You don’t use that to “figure out how their models would work in the real world”. You use it as a sanity check before you build a detailed model.