Serious FDE bug in FS2004?

[Guest Ron Freimuth]

I expect adjusting TBL 404 if necessary, CL vs wing AoA, will restore the pitch and induced drag to what it was before. If REC 1101 "Body AoA for Min Induced Drag" was correct before, the adjustment of TBL 404 will leave it the same. I see many of my AC already have 'twist' set to -1/2 'incidence'. So, their effects cancel out (unless the twist changes drag slightly). In some commercial AC I have "incidence +1/2 twist" comes to +/-0.5 degree. So, the flight pitch would change by 0.5 degrees. Not neglible, but hard to notice. However, without changing the REC 1101 parameter, Induced drag will change about 20% at total wing AoA=5% (Cruise pitch might be 2 deg). That's becaues Incidence + 1/2 Twist no longer affects CL and a 5% change in AoA changes Cdi by 1.05^2 ~ 1.1 (10.3%). At 'best climb'Max L/D, Cdi is half of Cdo, and the effect on total drag is greater. Some AC have "Incidence - Twist/2" greater than 0.5 degrees. Where the problem becomes greater. If one calculates "Incidence - Twist/2" to get the effective wing incidence, he can shift TBL 404 sideways to get the same CL at AoAwing=0. For example, the 737 wing has CL about 0.208 at AoAw=0. Incidently, if "Incidence - Twist/2" = 0 (as FS9 sets it), then the REC 1101 parameter will be just the AoAwing in TBL 404 that goes through zero CL. This is almost always a negative angle (in radians). Typically amounting to -2.5 degrees. Other than having to have CL at AoAw correct in TBL 404, the fact that the point CL=0 is the same as the TBL 1101 parameter makes the later easier to set. Clearly, Incidence and Twist/2 don't come in when they can't be set. ;) Note one doesn't have to shift all of TBL 404, just the x values from the negative stall angle to perhaps + 30 degrees. Convert the "Incidence - Twist/2" remainder to radians and add that number to the x values in TBL 404. If Incidence were 0.5 degrees and Twist 0.0 degrees, then add 0.5/53.7 = 0.0087 to the important x values in TBL 404. This can be done in Aired by hitting 'x' when the table window is open and editing the x value that comes up. Start at the right and move left so you don't get confused.----------------------------------- I looked at the FS9 Extra 300 and didn't see any tables that would contribute to spin. However, in the Jenny I saw that TBL's 1537 and 1538 had been set, and rather differently than in the past. I'll check to see if my semi-spinnable AC still perform the same. I'd hate to think some tables have been deactivated after all the trouble I took to learn how to set them. I think real P-Factor and probably 'torque' have been restored. That xould help some AC spin. I installed my Concorde in FS9. I got a message that the mdl might not be compatable. However, everthing appears to work on it. I noted I also had set Twist to just cancel Incidence in my FD for the Concorde, though pitch seemed high in cruies. However, I can't say the performance was different. Harder to check without AFSD. AC are much more stable now with ALT hold, even without adjusting the new autopilot parameters. Ron

[Gridley 257]

I too am thankful to all of you who have contributed so much to this hobby by your efforts and dedication. I have learned a lot from this thread, not so much because I understand it but rather I now appreciate how much you know, and what goes into producing an addon that replicates an aircraft with such high fidelity.I must also say that I am putoff by the sabre-rattling and claims that MS is out to get the developers - I think its just too soon to tell. Careful examination of relevant components of the new FS2k4 flight models has already produced some interesting results, from what I gather here. More time may reveal, as I (perhaps ignorantly) suspect, that 2k4 has the potential to represent flight as well as 2k2 did. I'm not willing to flatly condemn FS2k4 until an SDK is out for FDEs, and until all the designers sign in with their opinions and experimental results which show that planes designed for 2k2 cannot perform similarly, with modification, to 2k4."Amoung all virtues, patience is, by definition, the first to be cast aside." -me

[Guest]

I completely agree. Nice to see that there are some level heads out there. ;-)

[Guest]

Firstly may I remind everyone reading this thread that there never has been, and most probably never will be, a Microsoft Flight Dynamics SDK. They never release this information, which is precisely why we have to go through this tortuous process of decompiling and testing what they have released, and then working out from first principles how it works and what has changed. We simply don't have the option of waiting for an SDK. There isn't going to be one. If FDE authors are lucky the findings and conclusions of this thread and others may be collated and posted on an unofficial website when and if we find a workable fix for the degraded flight model.Ron - Thank you for adding flesh to the proposed AoA rotation fix. Having taken the time to study it carefully I understand the detail of your proposal now. For reasons which I am about to explain I don't think it works as proposed, but I think that an alternative manipulation provides a partial solution for new build aircraft. You have addressed my suggestion that an AoA rotation would necessarily make the induced drag error worse and I now agree that is not necessary. A key problem remains. In your latest post you say;< If REC 1101 "Body AoA for Min Induced Drag" was correct before, the adjustment of TBL 404 will leave it the same. >It cannot be left the same. We have just proved that variable is not processed by FS2004 and defaults to zero. and for instance;I deduce that you have not taken on board that the REC1101 parameter in question which I identify as REC1101-50h is not being processed in FS2004. The point of this thread has been to highlight that FS2004 cannot process that variable (and two other key variables relating to incidence).In the circumstance you discuss in the quote above the value processed will not be, 'the AoAwing in TBL 404 that goes through zero CL'. It will be zero in every case because FS2004 forces it to zero. That difference is the source of the flight model degradation error to be corrected. The more the correct value for the aircraft in question deviates from zero in FS2002 the larger the flight dynamics degradation in FS2004. Realistic flight dynamics for older aircraft tend to be degraded most.The key problem in producing FS2002 to FS2004 FDE updates is to overcome the difference between the (correct) value assigned to REC1101-50h in FS2002 and the (incorrect) zero value imposed by FS2004. The pitch rotation could if necessary be an MDL rotation, but the MDL author cannot correct the drag equation. In your proposal you also say;<.......a 5% change in AoA changes Cdi by 1.05^2 ~ 1.1 (10.3%).>It is a 5% change of CL which has this effect not a 5% change of AoA. In order for a 5% change of AoA to have this effect the drag curve would have to be a straight line with no curvature. A CL shift may be calculated as above but not an AoA shift. Unfortunately an AoA shift is what is required to correct the false displayed pitch. The drag consequence of an AoA shift is therefore not as you propose.Now to the 'partial solution' for new build aircraft based on Ron's proposal. REC404 can easily be used to correct either pitch or drag when it does not have to control the other. If new build aircraft are prepared with rotated MDLs so that REC404 does not have to perform the pitch correction it can perform the drag correction in real time. It follows that new build aircraft with rotated MDLs will not need to have compromised FDE. A newly prepared pre rotated MDL can be provided with FDE containing a REC404 which provides realistic flight dynamics in FS2004. Those FDE would be prepared more or less as Ron proposed in his last post but would be shifted for CL/AoA to provide only the correct induced drag which should be fairly simple to write, even if tedious to test.It may also be worth exploring whether there is a more complex manipulation of the REC404 data alone using both an X shift and a Y shift, which can not only rotate the aircraft back to the correct displayed pitch, but also correct the missing REC1101-50h drag for an unrotated MDL. This would however be a more complex manipulation than Ron proposed. I fear it takes us into territory which many FDE authors would struggle to implement in their updates even if we could publish 'the rules' in this thread, but unless we find an FDE solution which corrects pitch and drag together then the MDL makers are going to have to resolve the pitch error leaving the FDE authors to resolve the drag error. I know that MDL makers, animators and painters will not welcome that.As I said last time, I expect that most FS2004 aircraft will be released with the pitch display error uncorrected, but this is not an option for older aircraft with large net angles of incidence, and they after all are supposed to be the focus of FSCOF. --FSAviator

[Guest]

>...but unless we find an FDE solution>which corrects pitch and drag together then the MDL makers are>going to have to resolve the pitch error leaving the FDE>authors to resolve the drag error. I know that MDL makers,>animators and painters will not welcome that.A propely texture mapped model will not have a problem with textures, simply because the UVW coordinates (the pixels on the bitmap) are "locked" to the xyz coordinates (the individual vertices) on the model.I can rotate the axis of a model and make it stand on it's tail without affecting the texture mapping one iota! :)This particular part of the apparent problem is really a noot point - a "tempest in a teapot," as it were.If you need a model to have its axis rotated for any reason, it's a trivial matter to accomplish.BillAVSIM OmbudsmanFounder and Director,Creative Recycling of Aircraft Partshttp://catholic-hymns.com/frbill/FS2002/images/fartslogo.jpg

[Guest]

It would seem that you have two conflicting arguments. You stated that MS has botched SDK compatible aircraft, then went on to state that there is no FDE SDK. MS can therefore do what they please as relates to the flight dynamics. I don't agree with this policy, but it is how it is.No doubt wing twist and incidence have predictable effects on induced drag and aircraft pitch. If someone has or can direct me to the appropriate equations I would be more than happy to attempt to find a transformation for REC404 data that would allow for the proper aircraft pitch as well as induced drag.Substituting a MDL rotation for real aircraft pitch has a number of issues as well, not the least of which is that trim values will be incorrect. Also, I'm not sure if the actual view from the cockpit would be affected in any way. Therefore I don't believe that this is the correct approach in this situation.It would appear that MS has almost moved completely away from using proper aerodynamic derivatives and more towards interpolating existing data.

[Guest fturner]

If, in order to correct your pitch you have to adjust tables in the air file as per Ron's suggestion, then IF drag is incorrect, then that can be adjusted in table 1507 which basically sets the drag factor of the engines.Now this will work for Jet aircraft, with the slight effect of changing fuel flow. Of course the other engine tables can be adjusted to fix that issue as well.My belief, if there's a will there's a way. Sure MS once again changed how FDE's are defined, but I don't think they have the intention of forcing the developers to build a/c that only conforms to what they think it should do. If that was MS's will, then the aircraft.cfg and the air file would pretty much be hard coded into the sim and not allow anyone to change anything.Afterall, the main reason MSFS sells is because of the ability to develop addons for it. MS is very arrogant as we all know, as it seems they have the "Borg" attitude. But for something that makes money for them, I can't see them destroying that.Sure its a pain in the butt to have to figure out how the FDE system works for each new release, but there would be alot of bord folks out there, as once a B707 flies right, it'll never have to be changed again for the next 10 versions of FS.......;-)Just my thoughts anyway.....because I enjoy the challenges of a new release.Fraser

[Johan_Dees 84]

From MS site:Why don't you release the details of the .AIR files that define the flight characteristics for the aircraft in Flight Simulator?The .AIR files contain proprietary data that aircraft manufacturers have provided to us. To help protect that information, we don't release the internal details of the .AIR file. Flight Simulator 2002 Professional Edition includes an improved the FSEdit tool that helps virtual pilots and add-on developers work with the aircraft flight models without having to understand the .AIR file format. We continue to work on better ways to help the add-on community and enthusiasts who want to modify existing aircraft or create new aircraft. As we have more news to pass along, you'll find it here. Johan[A HREF=http://www.phoenix-simulation.co.uk]Phoenix Simulation Software[/A]-----http://www.people.zeelandnet.nl/johdUnofficial PSS Website

[Guest]

>From MS site:>>Why don't you release the details of the .AIR files that>define the flight characteristics for the aircraft in Flight>Simulator?>>The .AIR files contain proprietary data that aircraft>manufacturers have provided to us. To help protect that>information, we don't release the internal details of the .AIR>file. >Flight Simulator 2002 Professional Edition includes an>improved the FSEdit tool that helps virtual pilots and add-on>developers work with the aircraft flight models without having>to understand the .AIR file format. Man, what a load of bull durham! "Propietary data" my Aunt's Fanny...That POS FSEdit never did anything except throughly trash good .air files...Edited: ...well, that and caused a lot of computer lockups...BillAVSIM OmbudsmanFounder and Director,Creative Recycling of Aircraft Partshttp://catholic-hymns.com/frbill/FS2002/images/fartslogo.jpg

[Johan_Dees 84]

Indeed, but thats what they say.There is something more behind this, and Ron probably told this before. Its about the company who sold it to MS; BAO..Anyhow, NO SDK to expect!Johan[A HREF=http://www.phoenix-simulation.co.uk]Phoenix Simulation Software[/A]-----http://www.people.zeelandnet.nl/johdUnofficial PSS Website

[Guest JeanLuc_]

Hi,it is a very interesting thread and I admire all the knowledge put into this. However there are two things I wonder and hope someone could coment to shed some light:1) from the broad spectrum of people having been chosen to participate in the beta tests, as seen from the number of "FS2004 beta tester" messages for the last 3 weeks at avsim and elsewhere, does this mean that only a few, if not none, FDE recognized names participated in the beta tests and have had the opportunity to report this "problem" before the program went gold?2) considering it is a new version, how could you already consider we are doomed, without knowing yet if this new version provides others / additional means to achieve what you used to do with values in tables, but simply in another way, not documented yet, in FS2004?I certainly share the concern, but I'm quite puzzled at the same time about the "panic" mode this actual problem sounds like, even more if this is not a problem at all (waiting for the new SDK to know more about it)?!?

[Guest]

Now that I can properly log in, I'll try to remember what I wrote the other night...Regarding the Whitley, which has an AoI of 6.5 degrees, I was able to successfully offset table 404 and get identical performance to the CFS2 version, which of course uses the angle of incidence parameter. The pitch during cruise was precisely the same as in CFS2. I offset table 404 by 0.1134 radians (6.5 degrees) and the results were excellent.As mentioned in an earlier post, there are other ways to get around drag issues, and while it's not as handy as having AoI and twist (I lament their departure), all in all I doubt anyone is really going to be able to notice the difference between a well-done flight model for FS9 and one for CFS2 (I don't mention FS2002 since it doesn't model torque effects and it doesn't support what I'd consider a truly excellent piston engine FM).I agree that there are likely other very good ways around this issue, such as rotating the model or offsetting table 404 and adjusting drag using the other tables and parameters available.All in all, FS9 feel more "real" to me, much as CFS2 does. I think we'll find it's a step forward in time, once the potential is discovered.On a final note, yes, FSEditor yields horrible FMs in and of itself, but if you know where to look, it gets you in the ballpark and does save a lot of time initially setting up the flight model.

[Guest Ron Freimuth]

>Firstly may I remind everyone reading this thread that there>never has been, and most probably never will be, a Microsoft>Flight Dynamics SDK. They never release this information,>which is precisely why we have to go through this tortuous>process of decompiling and testing what they have released,>and then working out from first principles how it works and>what has changed. We simply don't have the option of waiting>for an SDK. There isn't going to be one. I heard from one of this forum's contributors that he will be working with MS on SDK's. However, I don't know how much MS will allow to be revealed.>Ron - Thank you for adding flesh to the proposed AoA rotation>fix. Having taken the time to study it carefully I understand>the detail of your proposal now. For reasons which I am about>to explain I don't think it works as proposed, but I think>that an alternative manipulation provides a partial solution>for new build aircraft. You have addressed my suggestion that>an AoA rotation would necessarily make the induced drag error>worse and I now agree that is not necessary. You appear to be ahead of me on finding these problems. I installed several FS2K2 AC and them appeared to be more or less the same in FS9. However, I haven't made exacting tests for drag, etc.>A key problem remains. In your latest post you say;>>< If REC 1101 "Body AoA for Min Induced Drag" was correct>before, the adjustment of TBL 404 will leave it the same. >>>It cannot be left the same. We have just proved that variable>is not processed by FS2004 and defaults to zero. Based on that comment I tried changing that REC 1101 parameter in the C208 I was flying when I read it. You apppear to be correct, I changed the 1101 'AoA for Cdi min' in the AIR file, making it higher and lower. Then reloaded the AC. ALT was held with ALT hold and the torque eventually stablized at its previous value. Making that 1101 parameter more negative would move the parabolic drag parabola to the left, thus induced drag should have increased and IAS decreased. IT DIDN'T! Nor did IAS increase when I moved the minimum to the right. I reduced IAS to 92 kts to be sure there was signfificant induced drag in the C208. Next, I thought that perhaps that parameter is now set automatically to the wing AoA that results in CL=0 in TBL 404. I moved that point left and right and didn't see any differences. I then moved the point at AoA=0 to the right and to the left. And, also moved the earlier point. I tried various combinations. I think this made some difference in IAS (same throttle/torque setting). Howver, the results were inconclusive. We know earlier versionws of FS set the induced drag parabola based on the slope of TBL 404: dCL/dAoA. However, odd lift shapes didn't give tractable results. I did NOT move all the important range of TBL 404 lower or higher. I did not have a test gauge in the C208 panel, so I don't know just how much pitch changed. JWB.gau works in FS9, but my XML Jet Test gauge is a blank box. That should be easy to fix when I know how. "Jet Test" displays current specific range, so is very accurate in showing the effect of drag. >then the REC 1101 parameter will be just the AoAwing in TBL>404 that goes through zero CL. This is almost always a>negative angle (in radians). Typically amounting to -2.5>degrees. >>>I deduce that you have not taken on board that the REC1101>parameter in question which I identify as REC1101-50h is not>being processed in FS2004. The point of this thread has been>to highlight that FS2004 cannot process that variable (and two>other key variables relating to incidence). I just verified that. However, I don't know if it is being set automatically at this time. One could try an AIR file with the FSEdit records. FSEdit always set the equivalent of the REC 1101 parameter correctly, though it usually generated lousy lift and pitching moment curves. FSEdit also did not set the zero AoA pitching moment correctly, so a lot of trim was required. In FS2K2, one could delete the new CL and Cm tables and the old ones would be used. Further, I could edit the new, float8 parameters to be equivalent to the old ones in REC 1101 and the end result was virtually the same as if REC 1101 was active. There were still few parameters in REC 1101 being used: such as G limits and Stall AoA.>In the circumstance you discuss in the quote above the value>processed will not be, 'the AoAwing in TBL 404 that goes>through zero CL'. It will be zero in every case because>FS2004 forces it to zero. I don't see why FS9 would change TBL 404, other than if that 'lift scalar' were set to other than 1.0 in aircraft.cfg. >>In your proposal you also say;>><.......a 5% change in AoA changes Cdi by 1.05^2 ~ 1.1>(10.3%).>>>It is a 5% change of CL which has this effect not a 5% change>of AoA. In fact, previous versions of FS and CFS based the drag parabola on AoA, not CL! There is a formula and information for REC 1101:50 in Aired.ini that explains this. Further, I made a drawing of how FS2K calculated total drag from Incidence, Twist, TBL 404, and 1101:50 so Herve' Sors could program an earlier version of AFSD (FSTP) to make the same calculations FS2K did. That is calculate and disply Cdi directly from the parameters and tables. That test app also calculated Cdi from thrust and Cdo and the results agreed within 1% when tests were carefully done. This took some time, but the end results verified the 'theory'. >In order for a 5% change of AoA to have this effect>the drag curve would have to be a straight line with no>curvature. A CL shift may be calculated as above but not an>AoA shift. Unfortunately an AoA shift is what is required to>correct the false displayed pitch. The drag consequence of an>AoA shift is therefore not as you propose. Here is the formula given in Aired Info for REC 1101:50: "Cd=Cdo+((AoA+AoAmd)*d/Cl/dAoA)Cl=0)^2 * Induced_Drag_Constant" "dCl/dAoA is 'average Cl vs AoA slope' in TBL 404" Note: AoAmd is wing AoA for minimum induced drag. Which is what 1101:50 should be set for. Figuring the 'average slope' isn't easy. The formula above suggests it is the slope at Cl=0, however it is more based on the average slope. An approximation to this slope involves a trapazoidial integratation from AoAcl=0 to AoAcl=max. If CL max is near 0.27 radians than the calculation done in 'FSTP' for the effective lift slope (used to calculate Cdi) is very close. Otherwise, the user could put his own value in the test app for the slope that resulted in Cdi=IDK at CL=1.0. Note the Induced Drag Constant set in Rec 1201 is not used in FS2K2, rather SIM1.DLL calculates the IDK from the wing's aspect ratio. One sets the Oswald Efficiency in aircraft.cfg to account for it. Currently, AFSD estimates Cdi as the "drag remaining after the easy to get components are accounted for". The GE and Lift Slope vs Mach tables wouldn't have the effect they do on Cdi unless it were linked to AoA rather than CL. Again, the Cdi parabola is indirectly linked to CL vs AoAw (TBL 404). Sometimes I would make a simple calculation during flight tests that accounted for a new induced drag. When done correctly my calculations always agreed with what I observed after a change. >Now to the 'partial solution' for new build aircraft based on>Ron's proposal. REC404 can easily be used to correct either>pitch or drag when it does not have to control the other. While that would correct pitch, it appears it may not result in the correct induced drag. Some individuals have reported that it appears to get an AC flying in FS9 back to the same drag it had in FS2K2. I hope so. Howver, your comments and my tests a couple of hours ago now make this questionable. More detailed and exacting tests need to be made. That is, if the center region of TBL 404 is shifted sideways so pitch is exactly what it was in FS2K2 is drag exactly the same? Drag can be measured by checking fuel flow when the autopilot is set for the same altitude and speed in both simulators. Of course, weight, temperature, etc. also have to be identical. >>It may also be worth exploring whether there is a more complex>manipulation of the REC404 data alone using both an X shift>and a Y shift, which can not only rotate the aircraft back to>the correct displayed pitch, but also correct the missing>REC1101-50h drag for an unrotated MDL. If more than just shifting TBL 404 sideways is required, I doubt I'll fool with FD development much more. At least not for FS9. There is a limit to what I can tolerate of MS screwups! People spent years working these things out and more time to learn how to implement them. I have no desire to regress to less accurate flight models after all the effort I've put into learning how to make farily accurate ones from pervious versions of MSFS. Incidently, this isn't the first time induced drag was messed up. CFS1 wasn't right either, and Jerry Beckwith doesn't support it in his '1% SS'. >As I said last time, I expect that most FS2004 aircraft will>be released with the pitch display error uncorrected, but this>is not an option for older aircraft with large net angles of>incidence, and they after all are supposed to be the focus of>FSCOF. >-->FSAviator I see 'Bear' just released a list of older AC 'that work well in FS2K4'. These reviewers only look at general peformance and have no idea of how to make critical tests. The fact that FS9 reviews had nothing quantitive to say about FS9 AC shows the degree of ignorance involved in these matters. People say they want accurate 'flight models', but don't really know what 'accurate' is. Ron

[Bob Scott 7,721]

Folks;Let me offer one theory on why a table 404 (AoA vs Cl) shift could be a fairly complete solution to the ignored AoI, wing twist, and Body AoA at min drag parameters in FS2004.First, consider total drag as computed in FS2002: Cdc=Cdo+((AoA+AoAmd)*(dCl/dAoA)@Cl=0)^2 * Induced_Drag_Constant Where Cdc = coeffecient of drag (total, clean config) Cdo = Coeffecient of drag at zero lift AoAmd = body AoA at min drag = AoAwing@Cl=0 - (AoI + (0.5 * twist)) dCl/dAoA@Cl=0 = mean Cl vs AoA slopeThe problem is that airfile AoI, twist, and AoAmd values are unused byFS9.But--in the special case where AoI and twist are constrained to 0,AoAmd = AoAwing@Cl=0 (the zero-intercept in table 404)and the AoA element in the equation becomesAoA + AoAwing@cl=0 (note AoAmd is not needed in this case, and AoAwing@cl=0 is determined from table 404)The proposed fix for the missing parameters is to shift the table 404 AoA vs Cl curve left by AoI+twist/2 degrees (assuming positive net value). But others have suggested that only corrects pitch, but leaves drag unaddressed. Perhaps not...After the left-shift, for any given Cl, we use a new (lower) value of AoA resulting from the shift (AOA'). AoA' = AoA - (AoI + (0.5 * twist))Substituting in AoA', the AoA element in the drag equation then becomesAoA'+AoAwing@cl=0 = AoA + AoAwing@cl=0 - (AoI + (0.5 * twist) = AoA + AoAmd...which is what it would have been had AoI, twist, and AoAmd been used in the first place!So...theoretically, if the familiar FS2002 approximation is being used minus the AoAmd factor (a logical shortcut given that we've observed AoI and twist values seem to be zeroed out), a shift in the AoA vs Cl curve should not only correct the pitch, but it should also correct the drag owing to the heretofore missing incidence and twist.At first blush, this seems to work in practice when using a couple models converted from FS2002 with table 404 shifted. I'll be flight testing some profiles to more comprehensively test the theory over the weekend. Any more datapoints out there?RegardsBob ScottATP IMEL GUlfstream II-III-IV-V

[Guest Ron Freimuth]

>Folks;>>Let me offer one theory on why a table 404 (AoA vs Cl) shift>could be a fairly complete solution to the ignored AoI, wing>twist, and Body AoA at min drag parameters in FS2004.>>First, consider total drag as computed in FS2002:>> Cdc=Cdo+((AoA+AoAmd)*(dCl/dAoA)@Cl=0)^2 * Induced_Drag_Constant>...............>The problem is that airfile AoI, twist, and AoAmd values are>unused by>FS9.>But--in the special case where AoI and twist are constrained>to 0,>>AoAmd = AoAwing@Cl=0 (the zero-intercept in table 404) Yes, and that is what REC 1101:50 would be set to if there were not wing incidence and twist. Or, if "Incidence + (Twist/2 [neg]) = 0.0".>and the AoA element in the equation becomes>AoA + AoAwing@cl=0 (note AoAmd is not needed in this case,>and AoAwing@cl=0 is determined from table 404) Everything else, AoA tables, etc. are based on the Body AoA. That is, AoA relative to pitch = 0 in level flight. >The proposed fix for the missing parameters is to shift the>table 404 AoA vs Cl curve left by AoI+twist/2 degrees>(assuming positive net value). But others have suggested that>only corrects pitch, but leaves drag unaddressed. Perhaps>not... My AC appeared to have about the same total drag. However, recent tests on the C208 (mentioned above) were inconclusive. Will a simple shift in TBL 404 result in exactly the induced drag the AC had in previous versions of MSFS?>So...theoretically, if the familiar FS2002 approximation is>being used minus the AoAmd factor (a logical shortcut given>that we've observed AoI and twist values seem to be zeroed>out), a shift in the AoA vs Cl curve should not only correct>the pitch, but it should also correct the drag owing to the>heretofore missing incidence and twist.>At first blush, this seems to work in practice when using a>couple models converted from FS2002 with table 404 shifted. >I'll be flight testing some profiles to more comprehensively>test the theory over the weekend. Any more datapoints out>there?>Bob Scott People should check the results of this change. Use a test gauge (JWB.gau works in FS9) and measure the exact pitch and thrust (or gph) at a specific condition. Preferably a relatively low IAS where Cdi is significant. Use the autopilot to hold altitude and also IAS if possible. Then, test the same AC in FS9. Next, shift TBL 404 as you calculated or shift it to restore the same flight pitch. Finally, check how close thrust (prop AC), or pph (most all jet panels display pph) is between the FS2K2 and the FS9 versions. One might try this at 1.3 Vstall and some high cruise speed. If tests are done carefully, and this approach works, then pitch should be within 0.1 degree (resolution of JWB.gau) and pph should be within, say 1%. Ideally, the values should be identical. One could also make the adjustement in the FS2K2 FD files, setting incidence + twist/2 = 0 and moving TBL 404 as necessary. Then, copy the FD files to FS9 and see if the pitch and drag are identical to those in FS2K2. I suspect they may not be. Leaving no way I can think of to fix this.---------------------------------- I expect MS just screwed up again. They always seem to mess something up in the flight model code from the previous version. The FS2K2 'autopilot' was simply a BAD IDEA, the loss of prop effect on elevator was likely an error. So was using GS for TAS in the SPD hold. An error still in FS9. If the incidence/twist proplem turns out to be significant, then we need to #### more about this and make it clear to MS (who read the forums) that FS9 has a critical flight dynamics error and it had better be fixed! The sooner the better. I don't think I'd waste my time designing FD for a sim with such a signficant bug. Note this bug affects most commercial AC; while it's not the only thing that has to be resolved in FS9 updates, it may be more intractable than the other differences.Ron