yes, ideally. I'm no expert on the coding but maybe simconnect can do it by modifying the drag coefficient directly.
-
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.
P3D v4 Drag in relation to weight
- Thread starter Chrismot
- Start date
yes, ideally. I'm no expert on the coding but maybe simconnect can do it by modifying the drag coefficient directly.
- Messages
- 108
That's definitely not the case. It's one of the areas where FSX/P3D are way off. Just at baggage/fuel etc. at their 'correct' locations and you will notice that their effect is greatly exaggerated.
It's most likely related to the faulty FSX/P3D inertia calculation/simulation.
Last edited:
Roy Holmes
Resource contributor
- Messages
- 1,803
- Country
-
There seems to be some misunderstandings here.
The original question was about how to simulate added weights.
The solution which tacpack and all the developers I know employ successfully is to use simconnect or similar to add the station weights listed in the aircraft.cfg as appropriate so that the AUW is correct, then remove them as the stores are are dropped. The performance should then be correct. As the stores are loaded and unloaded they become visible or invisible on the airplane model.
For each airplane each store has an estimated drag index. The indices are summed to give an airplane drag index. That in turn causes the spoiler to extend by an appropriate angle. Analysis and tests with some fine tuning then create a drag index which has the same effect on speed and fuel consumption as happens in the real airplane being simulated. There is a maximum amount of spoiler extension used for drag then a fixed amount added when speed brakes are extended.
So there are two things that need to be done to simulate the effects of external stores, add their weight and create the right amount of drag.
These techniques gave results within 3% across the board in the SimSkunkWorks Tornado, for which a performance manual was available. The real drag indices for each weapon was available as was the performance effects. 3% is within the range of individual airplanes performance due to engine wear and dirty surfaces.
For other airplanes like the IndiaFoxTecho Typhoon and F-35 there was no released performance data, just some vague values tossed about here and there. Prior to working on their FDE I modeled the Mirage F-1 for which data was available and I used that as a basis for the Typhoon and, recently, the F-35. And yes to answer an earlier comment, the stores in the F-35 weapon bay add weight but no drag. The doors when open add a small amount.
There is nothing magic about how to simulate external stores, it is well proven. The sim does have over-zealous reaction to asymmetrical loads especially laterally, but that can be overcome by not using the full distances when placing the weights. Normally, weapons stations are made/designed to be as close as possible fore and aft to the empty CG so CG shifts are minimised. Some airplanes like the AV-8B have asymmetrical lateral loading limits which would preclude landing but are OK between drops. My experience with the F-4 was that fuel had a larger fore-aft CG movement than weapons.
Roy
The original question was about how to simulate added weights.
The solution which tacpack and all the developers I know employ successfully is to use simconnect or similar to add the station weights listed in the aircraft.cfg as appropriate so that the AUW is correct, then remove them as the stores are are dropped. The performance should then be correct. As the stores are loaded and unloaded they become visible or invisible on the airplane model.
For each airplane each store has an estimated drag index. The indices are summed to give an airplane drag index. That in turn causes the spoiler to extend by an appropriate angle. Analysis and tests with some fine tuning then create a drag index which has the same effect on speed and fuel consumption as happens in the real airplane being simulated. There is a maximum amount of spoiler extension used for drag then a fixed amount added when speed brakes are extended.
So there are two things that need to be done to simulate the effects of external stores, add their weight and create the right amount of drag.
These techniques gave results within 3% across the board in the SimSkunkWorks Tornado, for which a performance manual was available. The real drag indices for each weapon was available as was the performance effects. 3% is within the range of individual airplanes performance due to engine wear and dirty surfaces.
For other airplanes like the IndiaFoxTecho Typhoon and F-35 there was no released performance data, just some vague values tossed about here and there. Prior to working on their FDE I modeled the Mirage F-1 for which data was available and I used that as a basis for the Typhoon and, recently, the F-35. And yes to answer an earlier comment, the stores in the F-35 weapon bay add weight but no drag. The doors when open add a small amount.
There is nothing magic about how to simulate external stores, it is well proven. The sim does have over-zealous reaction to asymmetrical loads especially laterally, but that can be overcome by not using the full distances when placing the weights. Normally, weapons stations are made/designed to be as close as possible fore and aft to the empty CG so CG shifts are minimised. Some airplanes like the AV-8B have asymmetrical lateral loading limits which would preclude landing but are OK between drops. My experience with the F-4 was that fuel had a larger fore-aft CG movement than weapons.
Roy
- Messages
- 2,077
- Country
-
I disagree with this statement. Correct weight/balance definitions with the fuel/pax/baggage defined based on actual aircraft weight/balance sheets works correctly.
no, it's garbage in garbage out. The air file MOI are wrong. FS uses the same equation that is used in real world FD.
Roy Holmes
Resource contributor
- Messages
- 1,803
- Country
-
This is what the VRS TacPack SDK says about the subject of store weights on wings
"While you technically can use actual stores weights for your token weights (e.g. ~500 lbs for a 500 lb bomb), this is most definitely not recommended. Putting real-world store weights on aircraft stations with real-world offsets (arms) would render the aircraft nearly impossible to control due to the flawed MOI modeling used by FSX FDs. " This is a bit of a exaggeration because if the stores are symmetrical there is no issue. It is only when there are more on one wing than the other that a small problem arises and that can be trimmed out.
Yves Guillaume has a lot to say about MOI in his excellent publication on MSFS aerodynamics. He concludes that the calculation is flawed. One example from the document
"Instead of summing up all station_load.n entries individually, MSFS uses the offset of the average location of all payload stations from the CG position.
This means that placing one payload of e.g. 1000 lbs 30 feet ahead of the CG and another one of 1000 lbs 30 feet behind CG results in zero MOI contribution in MSFS, because the average location is exactly at the CG. In reality both stations’ moments would sum up."
Roy
"While you technically can use actual stores weights for your token weights (e.g. ~500 lbs for a 500 lb bomb), this is most definitely not recommended. Putting real-world store weights on aircraft stations with real-world offsets (arms) would render the aircraft nearly impossible to control due to the flawed MOI modeling used by FSX FDs. " This is a bit of a exaggeration because if the stores are symmetrical there is no issue. It is only when there are more on one wing than the other that a small problem arises and that can be trimmed out.
Yves Guillaume has a lot to say about MOI in his excellent publication on MSFS aerodynamics. He concludes that the calculation is flawed. One example from the document
"Instead of summing up all station_load.n entries individually, MSFS uses the offset of the average location of all payload stations from the CG position.
This means that placing one payload of e.g. 1000 lbs 30 feet ahead of the CG and another one of 1000 lbs 30 feet behind CG results in zero MOI contribution in MSFS, because the average location is exactly at the CG. In reality both stations’ moments would sum up."
There are no coefficients for MOI in the air file.
Roy
- Messages
- 230
- Country
-
Hello,
I'm not going to get into the MOI debate....
But I just want to confirm that, in the case that made me open this thread (Drag in relation to weight), I completely revised my model by drawing heavily on @Roy Holmes 's valuable explanations on "FS Thrust vs Altitude calculations Version 2"...
And I can confirm that, the loaded weight is indeed taken into account in FSX and P3D as @jx_ told me in a previous message: now, my plane with the weight of these bombs or the weight of its additional tanks rises much slower than in its clean version...!
Moreover, since my charges are symmetricals, the problem of the MOI does not exist...!
Thank you all for your suggestions and participation...
I'm not going to get into the MOI debate....
But I just want to confirm that, in the case that made me open this thread (Drag in relation to weight), I completely revised my model by drawing heavily on @Roy Holmes 's valuable explanations on "FS Thrust vs Altitude calculations Version 2"...
And I can confirm that, the loaded weight is indeed taken into account in FSX and P3D as @jx_ told me in a previous message: now, my plane with the weight of these bombs or the weight of its additional tanks rises much slower than in its clean version...!
Moreover, since my charges are symmetricals, the problem of the MOI does not exist...!
Thank you all for your suggestions and participation...
Never said that...for the weight stations to give accurate MOI the body MOI needs to be set correctly. Otherwise one or the other overpowers. This will also affect performance causing questions such as "why are my control surfaces too sensitive when I use the real coefficients?"
I already explained it. Garbage in Garbage out. The sim uses the correct math for everything I have checked. ACES screwed up on inter-dependencies and static coefficients such as not adding the lift from Lift v Mach to the induced drag equation; and ground friction. The fuel Flow is calculated from Net Thrust instead of Gross Thrust. It is possible that , as Roy/Yves pointed out, MOI is calculated after each axis instead of before (haven't specifically checked that). But the calculations are correct.
The apparent exaggeration comes from misinterpreting the Cm vs AoA table. It is for the whole airplane, not just the wing. 99% of all flight models for this platform suffer from this. You can absolutely use real weight and balance. My procedure goes like this,
Everything in the weight/balance and geometry sections is set accurately using real world numbers. The Cm0 is set to give the correct trim speed in the empty configuration ( minimal fuel and no payload, set fuel flow scalar to 0 ). Then, the airplane is loaded with a payload and fuel, the CG determined. The wing/tail combination is analyzed using CFD software to determine the new trim speed. The slope of Cm vs AoA is adjusted ( usually doubled or trippled ) to give the correct result. In turn, you may have to go back and redo the Cm0 value and repeat. But, after a few iterations, you can nail it down. Elevator and trim effectiveness usually have to be increased as well. Voila, there is no exaggeration. The Cm value near Clmax should be somewhere around 0.4 or higher. That corresponds to a tail efficiency of about 40-60%.
You also need to know things like the lift slope of the 3d wing ( from airfoil properties, zero-lift angle, aspect ratio, sweep angle, incidence, twist, etc ) and the lift slope of the horizontal tail, affected by downwash from the wing and tail aspect ratio, incidence, etc.... As I said, I use separate software to determine those things, which I suppose not everyone has access to or can afford. Such is the system we have to work with on this platform. I guess you could do something similar in a spreadsheet, using appropriate lift slope formulae, calculating moments based on CG position.
Basically, the lift slope of a 2d wing is 2*pi per radian, or 0.1 per degree. For a straight 3d wing, you could modify for aspect ratio as 2 * pi / ( 1 + 2/Aspect Ratio )
You could modify further for sweep by cos(sweep angle).
Then, downwash angle ( rad ) is 2 * Cl / ( pi * Aspect Ratio ).
This will get you in the ballpark, if you don't have CFD software that can analyze a wing/tail combination in 3d flow. I'm using Multisurface Aerodynamics by Hanley Innovations.
Roy Holmes
Resource contributor
- Messages
- 1,803
- Country
-
Tailplane lift in the sim does not vary with downwash, it varies with the tailplane incidence. While downwash has a considerable effect in real life it has no effect in the sim because it does not exist.
However the issue in this thread was about drag in relation to weight and not pitch coefficients. It was also about the incorrect method by which MOI is calculated. The method used works for balance but not for inertia.
Roy
However the issue in this thread was about drag in relation to weight and not pitch coefficients. It was also about the incorrect method by which MOI is calculated. The method used works for balance but not for inertia.
Roy
Last edited: