Serious FDE bug in FS2004?

[Guest Ron Freimuth]

Just a few more comments for now. I assumed the "reload AC" would work. Why else have it? It does appear to reload something. Now I previously verified that changes in wing_incidence, also wing_area "took hold" after FS9 was restarted. However, I have not tried changing either aircraft.cfg or the AIR file to see if the 'reload' has the effect assumed. I did edit the Lear45 panel and installed JWB.gau. This test gauge works and displays pitch to 0.1 degree. However, I always set the "V" indicator, and that is also very sensitive. However, my "Jet Test" XML gauge was blank. ;) I assume some simple change in the BG color, bmp file, etc. will fix it. I know many of the AC, such as the Baron 58, have virtually the same XML gauges as in FS2K2. ------------------------------------- If he only thing that requires an FS9 restart are the wing incidence and twist I can live with that. In fact, I set one airfoil from engineering data and didn't have to change incidence or twist. Further, I know how incidence and twist change pitch. So I can just write down the change I need and edit the two files before the next FS9 load. Actually, one couldn't set wing_incidence, twist, and/or cruise_lift_scalar without messing up the induced drag. "Fuselage Angle at minimum Induced Drag' in rec 1101 of the AIR file also has to be adjusted. I verifited that a few months ago. 'Twist' doesn't have much effect on drag, the main effect is to change cruise pitch by 1/2 the change in Twist. One can change wing_incidence alone, though I've sometimes made twist more negative to get a pitch change when I thought that was appropriate. One can get the same effect as changing 'incidence' by shifting TBL 404 (Lift vs AoA) left or right. However, that involves a lot of editing. I installed the DF C310 in FS9 today. The Mixture effect may have changed, nothing else was obviously different. However, I didn't have any test gauges installed in the FS9 version, so can't be sure of details. I did fly two "IFR" flights, the last one from KORD to KDFW in the Lear 45. Everything seemed to work well, and I was able to request a FL change in route. No ALT hold instability, though the Lear45 and other FS9 AC appear to be have too much elevator authority. Further, the C172SP made runway handing of my DF C310 seem easy. ;) The FS9 AC that were in FS2K2 are about the same, the 747-400 has the same stupid notch in Mach Drag' at Mach 0.8 that the FS2K2 AIR file does. The C208 sticks in the water, and pitches up on TO. I have a better set of files for it I did for FS2K2. The torque increases way too much at 2000 RPM in the C172SP, and probably in other AC. However, I could get the Default C172SP past rated IAS in FS9. It was too slow in FS2K2: prop was wrong. Anyway, someone else will probably find what the deal is with 'incidence' and 'twist' when 'reload aircraft' is used. I'll probably test a few things on my next flight. Ron

[Guest Douglas K]

>Now I previously verified that changes in wing_incidence, also wing_area "took hold" after FS9 was restartedProbably very stupid, don't have 2004 and to much busy with 2002, but can those problems have something to do with the "Obligatory Disk 4" in the CD-drive??

[Bob Scott 7,721]

Gents;Confirmed here also...no evidence whatsoever that FS2004 is processing AoI in its flight model.I started by changing AoI to 10.0 deg in airfile table 1204, then commented out the wing_incidence= line in aircraft.cfg--upon loading the BE58 FS2004 re-wrote wing_incidence=9.9974 back into the aircraft_geometry section of the .cfg file, so it's clearly reading the correct value. But that produced no change in the pitch attitude in level flight. Renaming the aircraft.cfg file with the sim running and then attempting to reload the acft produced a fault in SIM1.dll, so it's clearly trying to read the file again when reloading. I tried the reload acft hotkey, switching to another acft then back to BE58, and restarting FS2004...none ever reflected the AoI in the flight characteristics. I also tried smaller values (+5, +3), and saw no change. Amazing, and quite regrettable.AoI can possibly be altered indirectly by shifting the AoA vs CL curve in table 404 right or left. Probably no way to get twist back, though.Anyone tried contacting Microsoft about this one?RegardsBob ScottATP IMEL Gulfstream II-III-IV-VWashington D.C., USA

[Guest Milton]

I am finishing tests now on my AC520 and can confirm the lack of effect changing the aircraft.cfg OR .air file parameters (1204, 1101)affecting AoA. I have documeneted these tests using Jerry Beckwith's test panel which works great here. I have tried all the reload/restart techniques without effect. I am starting the Baron 58 tests now to confirm this.I will document all with pics of results of the test panel. You will see identical numbers in all regards.I have also studied the 300, 400, and 500 tables and see no differences there.I will also look at the effects of changing the Weight and Balances section and deactivating the load stations. If this can be changed or "no-opted", maybe we can get it under control.Ron, We really need the AFSD test gauges to get more thorough results (aerodynamics outputs). If you could ask Herve to get this up for FS2004, greatly appreciated. :-)Lastly, I have a set of factory engineering drawings with full specs for the Aero Commander 520 and 560. Exact parameters and locations for MAC, CoL, CG, stations, measurements, areas, etc. If you are interested to use this to check out the "interesting" readings out of the FS9 "Load Handler", I will package this up and upload it. It really takes some of the guesswork out of the setup.More later.Milton

[Guest Milton]

I can now confirm FSAviator's statements on no effect from changing wing incidence or twist in the Baron. I used Jerry's test panel for all tests. No changes in the AoA, Pitch, speed, numbers whatsoever. I could see no effects of a drag change either. Everything showed identically. All tests were done with AP and no changes in throttle through all tests.I used all restart and reload techniques, and even closed the .cfg and .air files after the changes and before and after closing the sim. I did notice when "//"ing out the two wing parameters, the sim put them back in from the values in the .air file. (even though Editable=0 was set)The biggest difference I noted between the AC520 tests and the Baron tests was the CoG%. The AC520 read -1.2% and the Baron read 20.6%. No wonder I was "nose-heavy" lol(Not to divert but I spent a lot of time trying to get the CoG back and see that reflected in the Load Handler. I could not do it without tipping the aircraft backwards.)I also removed the entire station section from the Weights and Balances section. This change in weight/balance was reflected in trim settings.Though I can confirm FSAviator's statement, I can only assume that "appropriate" incidence and twist numbers are being calculated for Load Management reasons ("ignored"), without an effect on lift and drag. In other words, accommodate the needs of the aircraft.I'll do some more tests here to further the discussion. It would seem that if we could "no-opt" the Load Balance" routine, we may regain control over this.Milton

[Guest Milton]

Okay, After several more hours of testing ... I have a few discoveries.Some changes do not take effect unless you "Reload Aircraft" twice ... Yes, that's right, two times.In adjusting CG%, the first reload (using wsieffert's routine) did not take, ... did it again, and there she was. The same was true with suspension adjustments. I will do more testing on this.Though I have not yet found a solution to incidence and twist, hmmmm, I found that moving wing_pos_apex_lon forward 1.5 feet took me from -1.2% to 20.6% CG. A 2 took me to 30.6~%.With this simple change, my CoG was in the valid 18-38% range for the AC520 and felt really good. Had to adjust front suspension and she feels great (relatively speaking :-) on takeoff and landing. Rotated on the numbers and climbed out on the numbers.Still requires about +6 over cruise trim on short final, and that may be close.The test panel helped tremendously to sort this out, but would have loved the AFSD as well.More later.Milton

[Guest Ron Freimuth]

I went through more tests last night, but with the FS9 Lear 45. I installed JWB.gau and could read CoG, pitch, etc. I now see no effect from wing_incidence and twist, whether done in the AIR file or in aircraft.cfg. I saved a Lear Test flight in mid air, so conditions wouild be exactly the same when FS9 was restarted and the flight loaded. I even deleted the .tmp files in Temp that FS9 creates. I noted at least one of them was identical to what I'd previously deleted. Thus, it didn't contain AC settings. It must have been the change in Wing Area I made in the Baron 58 that made me thing Incidence had an effect. I also set Wing Area lower in the Lear 45 during flight and pitch increased after the 'Reload Aircraft'. I noted the Lear showed the same Pitch and 'AoA' in level flight in JWB.gau. The MS Airheads may have purposely killed 'wing incidence' since the FS model should NOT be set the the physical incidence anyway. FS doesn't include wing Downwash in it's modeling, but real AC do. Thus, they need more wing incidence than FS does. I checked my Incidence and Twist settings in the DF C310. I see I set Incidence to 1.50 degrees and Twist to -3.0. They exactly cancel! So, assuming FS9 ignores those entries it makes no difference. At least as far as flight pitch goes. -------------------------- I don't know who was in the FS9 beta test, but didn't they check any of this stuff? I suspect not. In fact, I'm not even aware of any 'FDE types' that were allowed in the Beta test. Further, it appears MS now requires beta testers to NEVER talk about what went on the the FS Beta tests. In contrast, the NDA on the product itself is lifted around commercial release time. I guess they didn't like hearing some of the negative comments made after beta tests on how poor MS is in working with developers.Ron

[Guest Douglas K]

>AoI can possibly be altered indirectly by shifting the AoA vs CL curve in table 404 right or left. Probably no way to get twist back, though.

[Guest]

Of course not. All they want is to whine and complain about things they hear somewhere vague that sound like it might be a problem yet mostly don't understand.

[Guest]

What other ill effects of this change can we be expected to see?In my experience, wing twist and incidence were only useful for setting correct pitches in cruise and climb, etc. If AoI can be altered otherwise, then perhaps MS is just shifting even more towards interpolating tables vs. calculating proper values using real aerodynamic equations.In any case, this does seem frustrating.

[rcbarend 37]

>Of course not. All they want is to whine and complain about>things they hear somewhere vague that sound like it might be a>problem yet mostly don't understand.Jeroen,I have hesitated a long time before replying to your contribution in this thread (and many others replies in various forums).Maybe you are open to a friendly suggestion.The fact that you consequently and persistantly refer to almost anyone having a problem with FS2004 as Whiner or Troll really doesn't add or help anything as well.And the fact that you do it in this thread is IMO the limit.I find it quite outragious that you even suggest (I can't read it otherwise) that the experianced people participating in this thread are Whiners that don't know what they are talking about.So please, think twice next time you repond this way.Regards,Rob(and to the people discussing this FDE topic: My appologies for the off-topic comment, but I had to say this)

[Guest]

I just tested a Whitley, which has an angle of incidence of 6.5 degrees. This aircraft normally cruises at a nose-down pitch of -2.2 degrees in CFS2. It apparently has NO effect in FS9, as it's now cruising at a nose-up attitude. This is a bit of a drag, as there are certain aircraft, like the Whitley, that have very distinctive cruise attitudes and just don't look right otherwise.

[Guest]

Thanks to all of you for re-testing and to all others who have contributed.I believe we have all reached the same conclusion now with everyone eventually confirming my finding that both incidence and twist, together with their pitch and drag consequentials, default to zero at all times in FS2004. After giving this some thought I now conclude that this is not a mistake. It looks more like a a design time decision. I find it unlikely that the different variables relating to incidence and twist could go missing from the different equations in the flight model unless someone was instructed to go through the code and remove them everywhere they occur. Someone has. If this was an error some of the variables would still be working.Since the terms often get confused let me explain that FS2002 had an excellent flight model but dreadful default flight dynamics. The flight model is in the binary code of the product and is used by every aircraft. The flight dynamics belong to a particular aircraft and are coded in each aircraft.cfg and air file. The people who wrote the original flight model for Microsoft understood aerodynamics. The people who wrote their flight dynamics did not.Since there was nothing significantly wrong with the flight model and it had the capability to support realistic flight dynamics some of us who understand real world flight dynamics set about writing flight dynamics files for MSFS which exploited the capabilities of the flight model better than the proprietary default flight dynamics. By the middle of this year tens of thousands of Microsoft customers were downloading our work for free and enjoying the additional realism which we were able to unlock. Increasingly consumers were also buying payware aircraft because they were obviously superior to the aircraft delivered by Microsoft.What those who have contributed to this thread have just proved is that Microsoft have degraded the internal flight model equations just enough to ensure that realistic flight dynamics will no longer work in FS2004. We have been very careful to test with their SDK compliant default aircraft and at full realism. By carefully altering their proprietary code Microsoft have ensured that their commercial competitors, however small and insignificant, can no longer deliver products which are superior to their own. Some of you will have noticed for instance that Rob Young has posted elsewhere that Microsoft have removed the ability of the SF260 to spin in FS2004, whilst enabling spin within the Extra and Jenny FDE.This is entirely consistent with US law and entirely in accordance with the long term competition strategy of Microsoft as a corporation. Microsoft are perfectly entitled to react to competition by altering their proprietary code in ways which disadvantage others and make Microsoft look good.Opportunity, motive and modus operandi? You decide.The destruction of the pitch attitude and drag equations within the internal flight model stands in stark contrast to the impression which Microsoft conveyed prior to the release of FS2004. We have just proved that FS2004 is not compatible with any existing aircraft flight dynamics, even when they were fully compliant with all Microsoft SDKs. Destruction of the realistic pitch equation has ensured that FS2004 displays such aircraft at fake nose up pitch angles which preclude an appropriate view over the panel or VC. By removing the ability to process the drag correction from air file Section 1101-50h Microsoft have ensured that such aircraft suffer degraded performance in FS2004 because they always have excess drag. They become visually and dynamically incompatible with FS2004.FS2004 does not have an FDE converter. It just ignores key aerodynamic data from earlier SDK compliant FDE, degrading them so that they are no better than the new default FDE. Third party aircraft produced by experienced FDE authors, whether freeware or payware, always had significantly more realistic flight dynamics than MS default aircraft and are therefore degraded more. The Microsoft default FDE were so unrealistic that removal of the chosen aerodynamic variables from the flight model has hardly changed their attributes. I believe this points to careful selection and beta testing of the variables removed from the flight model equations.The implications for payware publishers whose expertise lay in producing realistic aircraft which exploited the internal flight model to the full are obviously grave, but they are not the only ones who suffer. The vast majority of MSFS consumers could never tell that the default aircraft had faulty flight dynamics and are therefore no worse off. The minority who could tell, including aviation practitioners and those who have invested hundreds of hours using the product to learn how to operate aircraft realistically from scratch, have been slapped in the face. The equations in question did not have to be destroyed for the eye candy aspects of FS2004 to work. Microsoft could have ensured that your favourite FS2002 freeware aircraft and your collections of FS2002 payware aircraft continued to work in FS2004, just by doing nothing at all to the flight model. Instead they made changes which ensure that all your FS2002 aircraft are degraded. We have proved that Microsoft have removed key aerodynamic variables from the flight model equations. Accident or design? You decide.Now I need to address a 'what if' that have come up in this thread suggesting that there is an FDE work around which can overcome removal of the variables.Ron, Bob and Douglas are talking about how substituting variation of AoA for AoI still 'works' and will have to be employed instead. Whilst this could restore realistic pitch it cannot restore realistic drag and will make the drag result even worse.Since Microsoft have ensured that FS2004 cannot process the drag data correction from Section 1101-50h the result of using an AoA rotation to substitute for an AoI rotation is a cartoon rotation which produces the wrong induced drag and a very distorted performance envelope. The drag consequences of +4dAoA and +4dAoI are very different. Picture a wing meeting the air and the bottom of the fuselage meeting the air in an aircraft where incidence = 4 and AoA = 4. The fuselage is level (aircraft has zero pitch) but the wing is four degrees nose up and is inducing substantial drag at 4dAOA. In FS2002 we could code the pitch and the drag for that aircraft differently and correctly. Now if we use an AoA rotation to remove the incorrect value of zero AoI which Microsoft have imposed for all aircraft in FS2004 we must make the wing have zero AoA to show the fuselage level again (zero aircraft pitch). Having reduced the AoA by 4 degrees to force the fuselage to zero pitch there is now also zero angle of attack and zero induced drag, producing a huge drag error.The proposal that AoA rotation substitute for AoI rotation ignores the fact that we have just proved that Microsoft have destroyed the drag equation as well as the pitch equation. The induced drag error cannot be corrected even though the pitch error can be corrected by the means proposed. This thread was never about data loading and reloading bugs in FS2004 real as they seem to be for some people. This is about the extent to which FS2004 is still a flight simulator at all.An FDE author can force FS2004 to display aircraft at the correct pitch but not with realistic drag. In FS2004 there is still a link between AoA and drag, but Microsoft have destroyed the link between pitch and drag. To make an MDL 'fly' at the right visual pitch it now has to be 'animated' like a cartoon. The MDLs are no longer 'flying' because in FS2004 as we have just proved they are not following the laws of flight. The consequence is that those who choose to produce FS2004 aircraft and updates will have to invoke a solution which is part video game and part flight simulator. Part cartoon animation and part dynamics code. The implications of this internal code change extend far beyond the world of FDE authors. Would be FS2004 MDL authors and painters of quality products have not understood yet. flight dynamics authors will have to explain it to them.When an aircraft is produced for use in any flight simulator, not just this one, the net flight incidence component of the flight dynamics equations is used by the FDE author to rotate the MDL to allow for wing incidence after it has been produced by the MDL maker. This FDE code also controls what can be seen over the panel or VC at run time. The FDE author then corrects any consequential drag error separately. That the FDE author can no longer do any of this in FS2004 is what this thread proved. For use in a video game which lacks wing incidence as a flight dynamic variable the MDLs have to be produced with their incidence rotation built in by the MDL maker at design time. We have just proved that the incidence variable is absent in FS2004.Let that sink in now and get ready to explain it to your project collaborators. That is what I mean by a *serious* bug in FS2004. The other new bugs are inconsequential by comparison.If producers have the goal of releasing FS2004 aircraft with even somewhat realistic performance envelopes which also fly at the correct displayed pitch attitude the only solution is as follows. 1) MDLs have to be rotated nose down by the net incidence of the real aircraft at design time to display correctly. 2) The MDL animations have to be prepared to match that nose down rotation.3) The textures also have to be rotated nose down in the paint package. 4) The FDE then have to be prepared with an 'overstiff' nose oleo which 'corrects' the nose down sit of the rotated MDL on the runway. Mainwheel oleos of tailwheel aircraft may be stiff enough already. I have tested and this works well.5) The MDL oleo animation may have to be written accordingly and not accurately. 6) The rest of the FDE then have to be written to match an 'equivalent aircraft' of zero incidence and zero twist but retaining the real world lift slope and consequential induced drag. Drag errors can then be 'somewhat corrected' using other data fields in Section 1101 which FS2004 can still process.If AoA rotations are used in lieu of the MDL rotation, as some have proposed, there is no way to correct the induced drag, (consider the zero case to understand why), and FS2004 is just a video game with animated cartoon aircraft. That seems to be the way this product is developing and I acknowledge that the majority of consumers who only use the product as virtual airport spectators and virtual passengers will be quite happy with that. The compromise above will therefore satisfy most FS2004 users, including most payware customers, but it is still a compromise with less accurate flight dynamics than FS2002. The comprise is largest for the fastest aircraft. Consequently I doubt that FDE authors whose expertise lies in creating realistic flight models will choose to spend hundreds of hours over the next couple of years producing or updating 'compromised' FDE for FS2004. They may decide to write payware FDE for FS2004 if the price is right, but their more demanding customers will always expect more realism than we now know is possible in FS2004. Those who have promised to produce FS2004 updates have a larger problem. Rotating pre existing MDLs is simple enough, but rotating all the animations and all the textures of a pre existing MDL may not be at all simple. It depends on the package used to create the aircraft originally. The FDE have to be rewritten anyway. All the other new FS2004 bugs also have to be taken on board and if possible fixed. The most important of these are the CoG bugs. Since I think I have now decoded them I will try to explain them later in a different thread. If anyone wants to design a Whitley for use in FS2004 the only choice will be an MDL rotated at design time, but I expect that most FS2004 third party aircraft will be displayed at fake pitch angles within the video game and most users will not notice. However since the fake pitch angles are always nose high you cannot obtain the correct view over the panel and you will wind up having to cheat in various ways to see where you are going, by scrolling the panel, or using a video game zoom factor, or some other video game cheat, to control the game. This has never been a requirement when flying with realistic flight dynamics.Due to removal of the incidence and twist variables the VIEW_FORWARD_DIR and SIZE_Y variables within panel.cfg, cannot always be used solve the view on approach problem in FS2004 in cockpit view due to ground / air mismatches previously solved by FDE code. There are no equivalents for the VC anyway. Setting the correct view over the VC 'panel' has to be resolved by MDL rotation in FS2004. All of which leads to my position on updating my own 'realistic' FS2002 freeware flight dynamics.My finding that FS2004 is unable to process three key aerodynamic variables essential to realistic flight simulation has now been confirmed by a range of experts. It is therefore not a question of how long it would take to produce FDE updates. FDE which are realistic in FS2002 cannot be updated to be realistic in FS2004. It cannot process the variables and equations which would allow real world inputs from flight manuals to cause the real world outputs. I cannot update my FDE for realistic first person flight simulation use in FS2004. The necessary code has been removed by Microsoft. Of course if the key variables were removed by mistake all Microsoft have to do is restore the old equations. They know where to find them. FSAviator

[Guest wkzzo]

These are some of the most fascinating threads I have read in along time. I have just installed FS2004, and installed my first fs2002 aircraft ,the MAAM B25. One of the first things I noticed was the ability to taxi at much lower rpm.(reduced ground friction?)Takeoff was extremly rapid, I had to pull back to 25"@ 2400rpm and was still able to climb out at 2000fpm at nearly 200mph. Alot different to fs2002 climbout at 35" @ 2400 1000fpm at 170 mph. It almost seemed as if the MAP was not actually changing as I pulled back from takeoff power to 30"MAP, there was no apparent change in speed.On approach to land the nose seemed to be pitched up quite a bit more than in fs2002,even with full flaps. Always fascinating to read the ins and outs of the airfile guru's and your work is greatly appreciated ,Thankyou.

[Guest Douglas K]

>The consequence is that those who choose to produce FS2004 aircraft and updates will have to invoke a solution which is part video game and part flight simulator. Part cartoon animation and part dynamics code.