Serious FDE bug in FS2004?

[Guest]

This makes perfect sense to me, and in fact mirrors what Mike Dornheim had speculated. I'm fine with it, particularly as it seems that drag is modeled correctly when the lift table is properly offset.It's just very hard to accept that a group of intelligent people committed to a good product plain screwed up. I believe in giving people the benefit of the doubt here, and this answer is good enough for me, especially since -- at least conceptually -- it was backed up independently by someone closely connected with flight simulation development and aeronautical engineering.Thank you very much for posting this.

[Guest]

>Bill said;>><...I can rotate the axis of a model and make it stand on it's>tail without affecting the texture mapping one iota! ....If>you need a model to have its axis rotated for any reason, it's>a trivial matter to accomplish.>>>That is great news Bill and suggests that we are close to>having a complete fix for both new build aircraft and upgrades>even if the FDE only fix does not work as simply as may be>hoped.>>Does your comment apply to both GMAX and FSDS 2.x ? >>Will already distributed texture only repaints of the 'old'>MDL work on the 'new' MDL or will repaints have to be 'redone'>with a new 'repainting package'?I'll answer that by way of analogy:Think of the texture mapping as you would paint on a car. The molecules of paint are bonded to the molecules of the car's body. If you roll the car over a cliff, the paint will remain attached... mostly! :)It's truly a non-issue for any model created by either program...Had this ever been a problem, the textures would have fallen off the model as soon as you took off...BillAVSIM OmbudsmanFounder and Director,Creative Recycling of Aircraft Partshttp://catholic-hymns.com/frbill/FS2002/images/fartslogo.jpg

[Guest Ron Freimuth]

>Hi Guys,> You may wait for the Aircraft SDK before any>conclusion, you will have the anwser about this :-) but the>key is the time to wait for the released public SDK :-( >>Chris Willis In the past the FS SDK's have been full of errors, incorrect, and lacking in meaningful descriptions of things such as lines in aircraft.cfg.Ron

[Guest]

I had to curtail my trip this weekend for reasons which have nothing to do with this thread.Having belatedly taken on board that the loss of the three variables can be replicated by setting them to zero in FS2002 I can now test the consequences and potential fixes without access to FS2004. I confirm what Ron Freimuth, Bob Scott and Curious George have posted. It will not be necessary to rotate MDLs to resolve the issue. The consequences of the missing variables can be patched by FDE authors making an appropriate alpha shift of the REC404 lift curve.My original test results were correct. The variables have been removed and the mathematical consequences are as I stated in my post at the top of this thread. I can only assume that all this was disclosed to the beta testers. The motive which I attributed to Microsoft was incorrect. I apologise to Microsoft for that. One consequence of this thread has been to flush out a rare public statement from a ' Microsoft developer' which begins;'The changes to the parameters in question were intentionally made. The reason is essentially that they simply represents offsets from alpha when entering the lift table.'I accept that is true in every respect and the disclosure is most helpful.. The statement as posted has been paraphrased and edited. I will therefore not bother to rebut it in detail. The important issue is the disparity between the first sentence above and the general impression given that FS2004 was compatible with compliant aircraft correctly prepared for use in FS2002. This has absolutely nothing to do with what some third party producers may, or may not, have included in their FDE, nor how well they understood FSEdit. This thread is explicitly about whether compliant FS2002 aircraft have their display characteristics, drag, and performance degraded by the flight model changes. This is determined by testing aircraft prepared by Microsoft in accordance with their own internal documentation and generally known as default aircraft. If for instance you import the default FS2002 F4U into FS2004, and you understand how to conduct the tests explained in this thread, you will see that it is degraded by the margins explained. As this thread has disclosed the problem is not caused by errors in FS2002 FDE, whoever prepared them. Discussion of flight dynamics code and FSEdit is a red herring. The problem is caused by the removal of variables from the internal FS2004 flight model equations.'A Microsoft spokesperson' has now disclosed that they made these changes knowing the that they would cause the problems described in this thread. What a shame that Microsoft did not explain this prior to release of FS2004, instead of waiting to be flushed out after the changes had been discovered and publicly evaluated. The comments above should make it abundantly clear that I am under no duress whatsoever from Microsoft or anyone else over this issue and what follows should be read in that knowledge.I regard it as very helpful that 'Microsoft' have admitted the problem now. It's existence and consequences no longer need to be disputed by anyone, and we can now start patching all the aircraft which need to be patched. I have always made it clear that I thought the average user of FS2004 would not notice the degradation suffered by imported FS2002 aircraft discussed in this thread, and it is clear from posts in other forums that they do not. I have been testing FS2004 very carefully, prior to making a purchase decision. Although some of the changes to the flight model have adverse effects on FS2002 aircraft, we now know how to exploit it to the full again. I am satisfied that FS2004 offers significant improvements in other areas. I shall therefore purchase FS2004.Understanding the explanation which 'Microsoft' have now given, I no longer call on Microsoft to patch the product to resolve FS2002 aircraft incompatibility. I merely call on them to be more open, and timely, in making disclosures to their customers concerning changes in the internal flight model in future. I think it is clear that everyone in the loop would benefit.--FSAviator.

[Guest Tom Goodrick]

I have been reading this thread with great interest. Having worked as an aeronautical engineer for over 30 years, I have some appreciation for what is being discussed. FSAviator, your contribution has helped shed light on this important issue. I would take issue with Microsoft more directly for some elements of their statement (if accurately depicted). In particular the staement that they are not interested in the angle of attack just of the wing but of the entire aircraft. Gee whiz golly! I always thought the wing was THE most important in the generation of lift for which the angle of attack must be computed accurately. Secondly, of course the horizontal tail surface but its angle of attack is normally computed separately taking into consideration downwash and temporary pitch rate effects. Indeed, I would urge Microsoft to do an independent angle of attack calculation on each half of the wing taking into consideration roll rate and yaw rate effects. Maybe then we could get a true snap roll.To quantify the effect of this "crisis in dynamics", I made test flights in both FS2002 and in FS9 of my Bonanza A36, on which I did the final FD adjustments for good performance and handling in FS2002. It was imported into FS9 with no changes in the FD files except to put the quotes into the weight and balance section so the new Fuel and Weight menu could be used. The test was level flight at 4000 ft with a full load first at 2500 RPM and 25 inches MP and then at 2100 RPM and 21 inches MP, all under autopilot control for best trim. Plenty of time was allowed to reach steady state. The high power portion resulted in 163 KIAS in FS9 and 173 KIAS in FS2002. The low power portion resulted in 118 KIAS in FS9 and 127 KIAS in FS2002. I calculated the lift coefficients (given accurate weight data in flight) at 0.2196 in FS9 and 0.1949 in FS2002 in the high power portion which is representative of cruise for this aircraft. This is an increase of 12.7% in lift which gives an increase of 27.0% in induced drag, thus accounting for the speed difference.For a complete discussion of the test including special gauges used please go to:http://www.billvons.com/cgi-bin/yabb/YaBB....218071;start=15So we are left with a performance difference of some significance. Will this really be fixed by adjusting the entry value into that lift table? Or will we have to artificially adjust power?

[John_Cillis 2,406]

Tom...I am not an engineer, but I used to scratch build RC gliders. We had nice ridge lift dynamics where I used to live in the Bay Area, and most of my projects I could keep in the air for hours.Ignorance of the AOI and twist in the wing, and the thought that designers are wrong for adjusting it, doesn't jive with what I learned. I used to use wooden strips to adjust the wing's AOI. Indeed, you could have a fuse flying fairly "straight" through the .air with the wing one or two degrees off in the angle of attack. The fuse would provide minimal drag, but that would be offset by the wing's AOA presenting a higher total frontal area for drag to work against.But, if they are simply offsets to the table mentioned, then it is quite likely that they never really modelled what I just described above. Honestly, I think we sometimes attribute dynamics to the MSFS flight modelling that are really software fudges of one type or another. Microsoft may have given them labels in the aircraft.cfg, but I don't think such labels are always 100 pct. in terms of what the parameters try to emulate.Being a third party in the communication process puts me ill at ease. I was wrong in my assumption--I assumed the AOI/Twist issue was a bug. And having to edit out some portions of what I was told causes others to make assumptions...and I won't fault them for that, nor will I comment on whether I know them to be right or wrong.But I agree that a whole crisis of confidence could have been avoided had Microsoft dealt with the public group in some way. And that still begs the question--we were told in FS2002 that .air file info is now verboten, and the response I posted here discusses an .air file parameter. I don't know if this triggers the question in others' minds, but it does mine--if we weren't supposed to know how to tweak the table, then how could we have been accused of being in the "wrong" in our manipulation of the AOI and Twist values?I hope the "right" people see and understand the significance of this question. And I hope the next SDK helps open up the untapped potential of the .air files, as I know some of the miracles Ron. Steve, Dave and the others have performed have been through such tweaking. Even my simple projects involved tweaking the .air file...

[Guest]

You must have flown those gliders near the Dumbarton Bridge. Dave www.daviator.com

[John_Cillis 2,406]

Actually, no...A great hill for ridge lift is just off of hwy 29, just north of the Solano/Napa county line. As you drive north, it sits there all by itself on thw west side of the freeway, and it is high enough and formed well enough that the afternoon bay breezes flow at a constant speed, and cause little turbulence. I could hand launch into the wind, then I'd turn and fly back and forth.... The ridge lift extended quite a ways over the hill on a good day, and my record flight lasted several hours--and I only gave up on it due to dusk... Even an average day offered 1-2 hours of good flying.It's been years since I've been up there--living in AZ doesn't offer me many chances to visit.....-John

[Guest Tom Goodrick]

It seems that MS has gotten caught in their own folly. I just tested the Baron 58 for cruise and found that it could only reach 191 KTAS level at 5,000 ft with max throttle (24.34 inches mp) and 2500 rpm. I was looking for 203 KTAS. I did lean to max power and saw 17.2 gph/e though I was looking for 17.5 gph/e - OK, close enough on that.But I checked the Raytheon web site for the latest specs and saw 202 KTAS at 6000 ft with full throttle and 2500 rpm, presumably leaned for max power.Their own Baron 58 is 12 knots slow, just like my A36 Bonanza.

[Bob Scott 7,721]

Folks;After a frustrating morning pondering the implications of Tom's finding on Cl variations between the two versions of MSFS, I think I've made another somewhat interesting discovery key to the problem. I was seeing a 7 KIAS difference (155 vs 162 in FS02) in top speed in level flight on the FS2002 Cessna 208B flown in FS2004 (with table 404 shifted left 1.67 degrees per earlier discussion for FS2004). Airspeeds across the flight range were indicating an excess amount of drag compared to the same model run in FS2002. Prop thrust figures were checked and found within 25 lbs between the two models.I have since found another orphaned parameter in the airfile--this one is the Induced Drag Constant in table 1204 (Main Wing). Instead, FS2004 appears to be calculating the constant:Kdi = 1/(Pi * e * AR)where AR is ratio of span to mean chord and e is Oswald Eff. factorUnfortunately, MS have advertised the config file chord parameter as wing_root_chord (not wing_mean_chord), but appear to be using the config file root chord parameter in determination of aspect ratio.I noted that the FS2002 C208B aircraft.cfg file had a wing area of 279.0, span of 52.3, and "root" chord of 6.4 I changed root_chord to 5.3 (279/52.3) to correct the aspect ratio, and the FS2004 drag figures now line up to within noise level of FS2002.This, I believe, could also find some use as a quick-tweak for drag profiles--minor corrections can be made with tweaks of either the span or chord figures.Additionally, in my testing, I tracked trim at level flight across the range of speeds from Vso to max level flight and conclude that both trim settings and pitch are preserved when shifting table 404 to assimilate AoI and twist into the flight dynamics model.I believe that with x-axis manipulation of table 404 and manipulation of AR with span or chord settings, we now have a degree of pitch angle and drag profile control equivalent to what we had available to us in FS2002. RegardsBob ScottATP IMEL Gulfstream II-III-IV-V L-300Washington, D.C.

[Guest N73GX]

It seems that MS has gotten caught in their own folly. I just tested the Baron 58 for cruise and found that it could only reach 191 KTAS level at 5,000 ft with max throttle (24.34 inches mp) and 2500 rpm. I was looking for 203 KTAS. I did lean to max power and saw 17.2 gph/e though I was looking for 17.5 gph/e - OK, close enough on that.But I checked the Raytheon web site for the latest specs and saw 202 KTAS at 6000 ft with full throttle and 2500 rpm, presumably leaned for max power.Their own Baron 58 is 12 knots slow, just like my A36 Bonanza. Was this test in FS8 or FS9? If it was fs9 check your payload and try it again and see what you get. the weight may have something to do with your test. If it was FS8 then you have to ask yourself a question. if the payload in fs9 is defualt to X amount of pounds then what is the defualt that is not seen in fs8?Thanks

[Guest Ron Freimuth]

>I have been reading this thread with great interest. Having>worked as an aeronautical engineer for over 30 years, I have>some appreciation for what is being discussed. >..............>Gee whiz golly! I always thought the wing was THE most>important in the generation of lift for which the angle of>attack must be computed accurately. Secondly, of course the>horizontal tail surface but its angle of attack is normally>computed separately taking into consideration downwash and>temporary pitch rate effects. Indeed, I would urge Microsoft>to do an independent angle of attack calculation on each half>of the wing taking into consideration roll rate and yaw rate>effects. Maybe then we could get a true snap roll. The 'wing' in MSFS isn't even a rectangle. The flight model generates a vector at only one point; a vector that incorporates one force magnitiude with the direction set by many other things. The main reason wing S, c_bar, and b are set is to provide the references for most of the rest of the aerodynamic flight model. This is standard for the kind of flight model used. Most 'engineering simulators' use this kind of flight model: one with look-up tables to model non-linearites. X-Plane's author explains that the aerodynamics are calculated in real time. One can display lift, etc for different parts of the X-Plane wing. However, this is only approximate. It would take a supercomputer hours to calculate transonic aerodynamics with a vortex-matrix or other approach. Clearly the 'direct' approach is limited to speeds where simply compressability relationships hold. Near as important is that modeling things like a prop isn't so easy, X-Plane keeps changing in how the prop, etc. are modeled and I feel the results are only approximate. Why try to model prop airfoils when mfg's data is presented in curves of Cp, Ct, etc? Similar to what the prop matrices in FS AIR files are set. ........... Getting back to the problem at hand: MSFS does not consider wing downwash. Thus, when wing Incidence has an effect (FS2K2), it should not be set the the physical wing incidence. Same goes for the H_Stab incidence: the effective incidence depends on H_stab camber and wing downwash. In fact, the effects of unbalanced lift, roll-yaw couplings, etc. are set in the 'standard' Stability Derivatives in REC 1101. Delays in airflow over the wing and tail are pretty well accounted for by stability derivatives such as 'Cm_adot'. Cm_adot generally increases pitch damping, but unlike Cm_q, this damping is proportional to U. About 20 'Mach Tables' model SD changes wrt Mach Number. Though, resolution is too coarse for good transonic modeling. Further, many non-linear effects modify the linear 'derivatives'. These are set in various tables in the AIR file. The most obviouis non-linear table is 404: CL vs AoA. One doesn't need such a table if only linear variations are considered. Cl at AoA=0 and dCl/dAoA are the only two numbers required for the linear model. Such a model will not stall since lift increases without limit. ;) However, there is no Tensor relationship in the FS non-linearities. That is, Cm (Pitch) non-linearities are not coupled to Cn (yaw) non-linearities in a general relationship. In contrast, JSBSim allows one to vary Cn non-linearites as a function of AoA. This is needed to get a good start modeling on Spin Dynamics. While some FS AC will spin, the available flight model is not sufficient to model spins very well. IOW, they are somewhat faked. An AIR file set up for strong spins well will be damanged in other, more normal flight. Sorry, another regression, again, back to the problem at hand: >To quantify the effect of this "crisis in dynamics", I made>test flights in both FS2002 and in FS9 of my Bonanza A36, on>which I did the final FD adjustments for good performance and>handling in FS2002. I used a new XML prop test gauge I wrote to test my DF C310 in FS2K2. This gauge shows specific range to very high resolution. If L/D is different when something is changed my gauge will show it! The gauge also displays 'body AoA', IAS, TAS, q, and other variables to about five digit resolution. Fortunately, I had designed the C310 with wing_incidence = 1.5 degrees and twist = -3.0 degrees. IOW, they (should) exactly cancel. So, performance in FS9 should not change as far as flight pitch goes. To see if Twist had an effect on Cdo (it should have a small effect) I changed aircraft.cfg so incidence was 5.0 degrees and twist - 10.0 degrees. Since only half of twist affects effective AoA, the pitch will come out the same. I used Ctl-Shft-R to reload the AC after a change in aircraft.cfg. I know this worked since I'd accidently set incidence to 50 degrees and could barely keep the AC flying. ;) I used the autopilot to set altitude and also have my C310 aircraft.cfg file set with SPD hold. After reloading, Altitude and IAS would eventually return to their previouus values. I also ran at X4 rate for a while so the AC would stabilize faster. Giving it perhaps four minutes of 'real time' to get to virtually the same IAS and TAS as before a change. My test gauge showed TAS was the same within 0.1 ft/s. IAS was around 150 kts, I forgot exactly what. Lower than cruise IAS, so Cdi would be higher than in high speed cruise. What I was interested in was specific range. A change in drag will change range. It was running about 1001 nm per 1000 lb/fuel (1.00 nm/lb; 6.00 nm/gallon). Now the result: Specific Range at Incidence = 5.0 deg, Twist = -10.0 degrees was **within 0.025% of Specific Range** at Incidence = 1.5 deg, Twist = -3.0 degrees. Body AoA was within about 0.005 degrees. Thus, I consider it verified that Twist has no effect on drag other than to offset Incidence. At least in FS2002. Further, the small variation in Specific Range could be attributed to the decrease in weight as fuel was burned. At this speed the consumption was lower than typical. This DOES NOT demonstrate that performance is identical in FS9! But, since FS9 has eliminated wing incidence and twist one would expect an FS2002 AC with Incidence + Twist/2 =0.0 will have the same flight pitch in FS2004. Hopefully, also the same drags. My XML test gauge is blank in FS9. I suspect some simple problem. Regardless, I have other ways to check performance in fS9, though not to the resolution I have in FS2K. ;) >It was imported into FS9 with no changes>in the FD files except to put the quotes into the weight and>balance section so the new Fuel and Weight menu could be used. I saw those quotes in FS2K4 aircraft.cfg files. However, FS2K2 AC I imported into FS2K4 appear to show the payload stations correctly without the quotes. Something to check....>.............>So we are left with a performance difference of some>significance. Will this really be fixed by adjusting the entry>value into that lift table? Or will we have to artificially>adjust power? I noted the Lear 45 incidence set in the FS9 aircraft.cfg was set differently than in FS8. Why make any change if there is no effect? Yes, I suspect MS itself messed up some of the FS9 AC, perhaps by not adjusting TBL 404 to account for the lack of functional incidence and twist parameters. Howver, I did see that the C208's have TBL 404 changed in the FS9 AIR files. At least the appropraite direction. In fact, I moved my FS9 208's into FS9, but also added the modified TBL 404 to my two AIR files. I have yet to check the exact details, but the 208B certainly would fly in FS9. Ron

[Guest Ron Freimuth]

>Folks;>>After a frustrating morning pondering the implications of>Tom's finding on Cl variations between the two versions of>MSFS, I think I've made another somewhat interesting discovery>key to the problem. ................>........>I have since found another orphaned parameter in the>airfile--this one is the Induced Drag Constant in table 1204>(Main Wing). Instead, FS2004 appears to be calculating the>constant:>>Kdi = 1/(Pi * e * AR)>>where AR is ratio of span to mean chord and e is Oswald Eff.>factor This is NOTHING NEW. I verified that FS2K2 set the Induced Drag Constant (Cdi at CL=1.0) as 1/Pi*AR soon after it was out. However, it often set an inappropriate "Oswald Efficiency" value in aircraft.cfg. Now I had set the IDK in REC 1404 of the AIR file and included the 'e' in your formula directly. I found that if I set the same Oswald Efficiency in aircraft.cfg when the FS2K AC was imported into FS2K2, then induced drag was the same as in FS2K. Note AR is S/b^2. The wing area, S, and span, b, are important settings in aircraft.cfg. The CFS3 SDK on aircraft.cfg was about the same as the FS2K2 info. But, suggested the 'wing_root_chord' was not used. Rather the MAC was calculated and used by the simulator. I always set MAC for 'root_chord' in aircraft.cfg. Then, I would know that the 'LE Apex' should be MAC/4 ahead of the CG (or near that). The MAC distance is the basic reference for all Pitch Stability Derivatives in the AIR file. To make real values work, MAC has to be correct. If FS/CFS sets it behind our backs I hope it gets set to AR/b. Regardless, the Wing Apex, sweep, etc. set in aircraft.cfg are not what is used in real aeronautical engineering. The wing is always reduced to a rectangle with a specific S, b, and c. The effects of sweep and taper are accounted for in various Stability Derivatives (parameters mostly in REC 1101 of the MS AIR file). Sweep affects 'Mach Drag' and t/c of a wing also has some effect. The physical form of the wing affects the shape of CL vs AoA, TBL 404. And, other details. Note a wing with signficant twist makes the drop in CL in TBL 404 less abrubt. That is where one would put the main effect of twist in the AIR file, it does nothing but shift TBL 404 in MSFS versions before FS9. Half as much as the now dead Wing_Incidence. I always set 'sweep' to zero. I think setting sweep moves the center of lift aft. I don't want the sim to be doing things behind my back. ;) Further, I suspect the Dihederal Setting changes the effective vertical offset of the wing (waterline). I eyeball the mdl view (often in Aircraft Container Manager) and set the vertical offset of the wing myself). I now set Dihederal to zero. The 'Dihederal Effect' setting in the AIR file accounts for much of the Dihderal effect, but the vertial offset of the wing also has an effect. Regardless, I always set the 'root_chord' to the MAC. Note MAC = S/b.>Unfortunately, MS have advertised the config file chord>parameter as wing_root_chord (not wing_mean_chord), but appear>to be using the config file root chord parameter in>determination of aspect ratio. As I mentioned, the CFS3 'SDK' suggested CFS calculated MAC and didn't use that 'root_chord' in aircraft.cfg. I'm not sure, but setting 'root_chord' to MAC always worked for me.>I noted that the FS2002 C208B aircraft.cfg file had a wing>area of 279.0, span of 52.3, and "root" chord of 6.4 I>changed root_chord to 5.3 (279/52.3) to correct the aspect>ratio, and the FS2004 drag figures now line up to within noise>level of FS2002. That would imply FS9 is not calculating MAC, and might be useing 'root_chord' incorrectly. Note the FS9 208 AIR files have a new TBL 404. It is moved to the left; also it drops less rapidly after CL max. I inserted that table in my C208 AIR files I copied to FS9 (with Aired). Note one can leave the old REC 404 in the AIR file if he sets Aired to 'unsorted' and inserts the new TBL above the old one. FS uses the first version of a table it finds. >This, I believe, could also find some use as a quick-tweak for>drag profiles--minor corrections can be made with tweaks of>either the span or chord figures. I always suggest setting real wing area, and span. With 'wing root chord' set to Area/span. And, the 'wing apex' MAC/4 ahead of the CG (or, where you want the CoLift to be). Then, set the Oswald Efficiency appropriately. Low wing AC are less efficient (more induced drag) and e may be as low as 0.6. Howver, I use these values for a start: High wing: 0.80 Low wing: 0.70 Jet Transport: 0.80 (I read the DC-9 has an e of 0.80) This is the parameter to adjust if induced drag needs to be modified. For a prop AC, best range occurs at L/D maximum, which is where Cdi = Cdo. Best Climb for a variable pitch prop powerplant is also close to L/D maximum. Cdo is set in the AIR file (one could scale it in aircraft.cfg). I adjust Cdo to get appropriate fuel consumption at high speeds or to set maximum speed. This assumes the engine and prop are appropriate. When one knows Cdo, and best climb IAS he can calculte the induced drag at that IAS (it varies with weight) and work back to the Oswald Efficiency to calculate it. However, I just make small changes in what I originally set if I feel more or less induced drag is appropriate. The Concorde Delta Wing is pecular, I think I set e=0.93, though 1.0 might even be appropriate. The low AR (1.8) for this wing means even a high e results in high induced drag. Incidently, Delta wings are worked out differently. They DO use the Apex for the reference, and CG is near 50% of the MAC in supersonic cruise. The FS2K Concorde aircraft.cfg file appears to have set the wing appropriately. CoL for a 60 delta is 2/3 of the way back from the LE. The Concord's wing is actually an Oglive form, only near a 60 deg delta wing. >Additionally, in my testing, I tracked trim at level flight>across the range of speeds from Vso to max level flight and>conclude that both trim settings and pitch are preserved when>shifting table 404 to assimilate AoI and twist into the flight>dynamics model. Normally, little pitch trim should be required when the CoL is set correctly. >I believe that with x-axis manipulation of table 404 and>manipulation of AR with span or chord settings, we now have a>degree of pitch angle and drag profile control equivalent to>what we had available to us in FS2002. >Bob Scott I hope so. I still need to make exacting tests in both FS9 and FS8 to verify AC set up appropriately (so they have the same pitch in FS8 and FS9) also have exactly the same drags. The C208's I imported might be good for testing this. I'd long ago fixed the FS8 flight models to get speeds, etc. to the stated specs. Ron

[Guest Tom Goodrick]

That Baron 58 test was done in FS9. The weight was a little over 5000 lbs (default weight). That diffeence in weight below max gross should not make that much difference in speed. I had tuned most of my FS02 aircraft to spec when that sim came out.

[Guest Tom Goodrick]

You touch on a lot of areas here. I'll keep my reply brief. In my work where I did flight simulations for several vehicals, I came to distrust the simplified linearizations that are implied by the use of stability derivatives. in many cases - peculiar craft and special flight problems - they are insufficient. I think they were developed mainly to make cohesive presentations in classrooms. When I deveoloed a 6DOF sim of gliding parachutes for the Army in the 1970's, I had to compute the local airspeed vector and angle of attack at 8 points on the quarter chord line of a curved wing. From that I computed three body components of force at those points. This process enabled me to model not only the longitudinal flight motions but steep turn effects and even spins where the gliding parachute really gets wrapped around an oscillating axis between the jumper and the canopy centers of mass. That sim gave results that were verified by flight tests with onboard data systems in highly dynamic conditions.I am simply suggesting that FS would do better if they computed velocity and angle of attack at the median points at the quarter chord on each half of the wing. Otherwise they must play numerical games with linearized approximations of highly non-linear phenomena.You speak of incidence and twist as "cancelling". The Bonanza 36 has a root chord incidence of 4 degrees and a tip chord incidence of 1 degree according to Jane's. I suppose that is a twist of -3 degrees but what do you call the "incidence"? Would it be 4? I would use the median incidence on each wing as 2.5 degrees and compute angle of attack without considering twist. The effect of twist is mainly in the lateral stall progression. This can play a part in the stability derivatives at high angles of attack. The problem identified in this thread is very basic. It is how much lift should be generated at a given angle of attack in the linear range of angle of attack for a given aircraft attitude and central velocity vector. Let us continue to address this central issue.What is the simplest solution to make FS9 aircraft fly like the corrected counterparts in FS2002?