Serious FDE bug in FS2004?

[Guest JeanLuc_]

Hi Ron,I'm certainly not an FDE guru to understand the inner workings, but the FS2004 version of the Meridian is flying really well compared to the FS2002 version. In all honesty it flies much better than the other aircrafts I've tried so far, and its flight characteristics seems to be little if not affected by the change.As a user, I guess from this example it is doable to port a flight model from FS2002 to FS2004 with great success.Hope this helps!

[Guest]

I ran this issue by Aviation Week's Mike Dornheim, a colleague who's an aeronautical engineer and was involved with the development of Boeing's sims some time ago.He also feels (completely off the record, of course) that what MS has done is to simply go to a more efficient, less processor-intensive method of calculating the total drag. If the total drag, as calculated by FS9 without the incidence, fuselage angle, and twist information is nearly exactly the same as it would have been in FS2002 WITH that same information, what they've done -- as described by Mr. Scott in his post above -- is to streamline the process a bit, at least on their end. And if the net performance of the aircraft is very nearly the same, the goal has been met.Mr. Scott's assessment above mirrors what Mike had speculated; he just provided the mathematical backup. Mike's basic feeling was that rather than calculate total drag from the sum of a bunch of individual parts, MS is now doing it more simply, with less paramaters, but with nearly equal results.My tests with the Whitley have proven to be very satisfactory in terms of overall performance and behavior, so this may prove to be something we can work around and adapt to.

[Guest]

Given the number of posts this thread is generating I cannot reply to everyone who contributes. I will try to answer the direct questions.Ron - You and I seem to be on the same page now. I note your point about the FSedit records, but will not have an opportunity to test in FS2004 until Monday at the earliest. Since Microsoft seem to no longer use them I don't hold out much hope. At this point other options look more promising.You say;Sorry Ron it had been a long hot day. Ignore what I posted about CL and AoA. You are right, what I posted is true in the real world, but not in MSFS. I don't think processing of AoA or CL has changed in FS2004. Hence I accept;"Cd=Cdo+((AoA+AoAmd)*d/Cl/dAoA)Cl=0)^2 * Induced_Drag_Constant""dCl/dAoA is 'average Cl vs AoA slope' in TBL 404"The following stuff understood. I am struggling to work out whether the AoA shift must lead to changed trim and changed trim drag even if the induced drag is identical. That could complicate testing.Bob - You are ahead of me now and in conjunction with Ron may have a solution. See my apology to Ron above. Others are reporting success, but not entirely clear how precisely they are able to measure. Do you see identical trim as well as identical pitch and IAS at constant power and thrust? Do you have test gauges to assist in testing?Since we are seeking identical performance with and without three named variables the tests can in theory be done in entirely in FS2002, before and after zeroing the three variables. It should then be possible to test with AFSD or other tools which work only in FS2002. If an aircraft which is made identical under those conditions is not identical in FS2004 then there are other bugs of consequence in FS2004. Since that is at least a possibility it may be that testing for same performance non zero / zero in FS2002 with precise test tools should be a precursor.Unfortunately I am now away until Sunday night.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'?Matt said; The flight dynamics SDK is an internal 'commercial in confidence' document. The means by which we tested that the flight dynamics of fully SDK compliant aircraft were unable to pass the relevant variables to the flight model equations, was by testing multiple Microsoft default aircraft. We know they are compliant with the current internal commercial in confidence 'SDK' even though we have no access to its content. The answer is complex. I guess it is all in AirEd.ini one way or another. Bob's latest post covers most of it and it seems that there may be no need after all. Elevator trim does not correlate to pitch it correlates to AoA so the MDL rotation does not affect trim. An MDL rotation changes nothing at all in the equations. If Bill stands his MDL on its tail it will fly exactly the same, only the displayed pitch in chase plane view and the view from inside will alter. < I'm not sure if the actual view from the cockpit would be affected in any way. >View ahead is a direct consequence of displayed pitch in both cockpit view and VC view. It could not be otherwise.Fraser said;Some drag equations such as the one driven by REC 1507 depend on the square of current IAS and others on the inverse. The missing data depends on the inverse square and so it is more appropriate to use REC 404 instead.Maybe 10% of those who use MSFS ever add anything other than a joystick free or otherwise. Addons are an issue for a tiny minority. Tom Allensworth gave an interesting interview on this topic recently. See if you can hunt it down.There is a difference between choosing to spend huge amounts of our spare time to upgrade our work to take advantage of new features and contemplating spending huge amounts of our time to downgrade or achieve nothing new. It is fixing the same aircraft over and over again that is boring. There are a thousand real world aircraft that have never had a decent set of flight dynamics in MSFS and most FDE authors would rather produce something new to fly. There is no enjoyment in repeating what we have done before.Changes which improve and innovate are welcome. Degrading the flight model for no good reason, (or even through carelessness if you wish), is the issue here.JeanLuc - Microsoft often ignore beta testers. Many of the' bugs' being reported in various forums were reported by the beta testers. As you can see we are working hard to find all the bugs, evaluate the new bugs, and then fix the new bugs. Those who allow themselves to be used as beta testers preclude themselves from being useful in this regard. They must promise not to reveal bugs they discovered during beta testing to anyone but Microsoft. It is very important that Microsoft do not manage to recruit all the experts as beta testers. As I have explained, there will never be a flight model SDK and that is why we have to do the work. Some aircraft in FS2002 will have been coded with little net incidence or even zero incidence. They will fly (about) the same in FS2004. The Meridian may be an example.--FSAviator

[Guest Ron Freimuth]

>Hi Ron,>>I'm certainly not an FDE guru to understand the inner>workings, but the FS2004 version of the Meridian is flying>really well compared to the FS2002 version. In all honesty it>flies much better than the other aircrafts I've tried so far,>and its flight characteristics seems to be little if not>affected by the change. From the F1 Meridian aircaft.cfg:[airplane_geometry].....wing_dihedral=4.0wing_incidence=1.0wing_twist=-1.0 Note wing_incidence + twist/2 = 1.0 -0.5 = 0.5. I felt my FS2K2 AC flew well in FS9, however we are talking about details of flight pitch and drag in this thread. In FS9 I'd expect the Meridean to fly 0.5 degree lower in pitch. Hard to notice unless one makes a detailed comparison. I'd also expect the Induced Drag parabola to be shifted 0.50 degree to the right. Assuming the minimum is set where TBL 404 goes through zero (not yet established). In cruise, half a degree change in pitch/AoA can have a significant effect on induced drag; in this case maybe 20%. However, in cruise Cdi is typically 20% of total drag, so even if it changes 20%, total drag might only change 0.20 * 0.20 = 4%. That would only affect top speed by 1/1.04^1/3. Only 1.3% lower. Something one would never see unless he made careful tests. OTOH, with drag 4% higher, fuel consumption would also be 4% high. Again, not normally noticable, but significant as far as I'm concerned. When the descrepancy is small, the FS AC may actually be closer to the real AC. But, on the average, I'd expect a poorer fit. ----------------- Now in climb one may set pitch so L/D is maximum. At this point Cdi = Cdo. AoA and Cdi are higher than in cruise. However, a small change in climb IAS will change Cdi by a larger percent. We know the drag minimum/best climb has a broad region so it would probably also be hard to see the difference. One might have to increase climb IAS from say 85 kts to 87 kts to get near the same climb rate.>As a user, I guess from this example it is doable to port a>flight model from FS2002 to FS2004 with great success.>Hope this helps! Overall, many FS2K2 AC appear to peform well in FS2K4. However, it may be that the MS screwup makes it impossible to adjust anything to get exactly the right drag. I just DL'ed FSUIPC 3.3. Herve' Sors sent me a small app that will display Fuel/Air ratio, SFC, etc. So, I'll be able to check some details in FS2K4 more closely now. Herve' mentioned a new AFSD for FS2K4 appears feasible. That will make tests easier and more accurate. Howver, the changes in the new FS will also mean he will have to change the coding for AFSD. Another PITA and delay. Ron

[Guest Ron Freimuth]

>I ran this issue by Aviation Week's Mike Dornheim, a>colleague who's an aeronautical engineer and was involved with>the development of Boeing's sims some time ago.>>He also feels (completely off the record, of course) that what>MS has done is to simply go to a more efficient, less>processor-intensive method of calculating the total drag. I doubt it. MS just screwed up. Otherwise they should have removed the incidence and twist from aircraft.cfg. Further, calculating induced drag is only a small part of the CPU load in the flight model code. We figure a drag parabola is generated when the AC is loaded, then used in flight. Many other details are also calculated, such as total MoI, when the AC is first loaded. That's why there is some delay involved in initializing a reload.>Mr. Scott's assessment above mirrors what Mike had speculated;>he just provided the mathematical backup. Mike's basic>feeling was that rather than calculate total drag from the sum>of a bunch of individual parts, MS is now doing it more>simply, with less paramaters, but with nearly equal results. Herve' Sors programmed a predecessor of AFSD to do virtually the same drag calculations FS2K does. 'FSTP' read many tables in the AIR file so it could calculate drags. One could reload FSTP and the time it took to do this and recalculate the effect of incidence and twist was neglible. Further, I found FSTP and now AFSD load the CPU very little compared to FS. FS mainly loads the CPU with graphics and other workloads. Though, when an AC is changing attitude rapidly one might notice fps slows as FS has to do more lookups of AoA and other tables in the AIR file. Ron

[Guest Ron Freimuth]

>Given the number of posts this thread is generating I cannot>reply to everyone who contributes. I will try to answer the>direct questions.>Ron - You and I seem to be on the same page now. I note your>point about the FSedit records, but will not have an>opportunity to test in FS2004 until Monday at the earliest. ...>You say;>>parabola on AoA, not CL! There is a formula and information>for REC 1101:50 in Aired.ini that explains this.>>....>about CL and AoA. You are right, what I posted is true in the>real world, but not in MSFS. I don't think processing of AoA>or CL has changed in FS2004. Actually, basing Cdi on CL^2, while common, is not correct. A few months ago I looked at NACA curves of CD vs AoA as Mach increases. The data was presented in terms of AoA, not CL. ................>JeanLuc - Microsoft often ignore beta testers. Many of the'>bugs' being reported in various forums were reported by the>beta testers. As you can see we are working hard to find all>the bugs, evaluate the new bugs, and then fix the new bugs.>Those who allow themselves to be used as beta testers preclude>themselves from being useful in this regard. They must promise>not to reveal bugs they discovered during beta testing to>anyone but Microsoft. It is very important that Microsoft do>not manage to recruit all the experts as beta testers. As I>have explained, there will never be a flight model SDK and>that is why we have to do the work. Some aircraft in FS2002>will have been coded with little net incidence or even zero>incidence. They will fly (about) the same in FS2004. The>Meridian may be an example.>FSAviator In fact, Steve Small related his experience in the FS2K2 beta test after the NDA was lifted. He tried to get the MS 'Airheads' to fix the strong pull to the left in the Baron 58. Their response: "Set the Realism sliders lower". Steve mentioned to me he managed to get into the FS9 beta test. But, some MS person noted him and had him removed. IOW, MS doesn't want people who know something about the issues to confuse their Airheads. MS told Lou Betti the FS9 beta test was full, so they couldn't let me and some other new DF people in it. I emailed Lou as soon as I knew his intentions that "I didn't think MS would want me". Further, I didn't want to waste my time trying to get their Airheads to undersand and fix existing problems. I understand that MS added a new element to the NDA for FS9: that one can't EVER talk about what went on in a beta test. Not suprising, from what I've seen MS FS beta tests are very poorly run and often ignore inputs from testers. I expect the top MSFS management is responsible for this policy. Many MS people working on FS would be glad to be more helpful, but get squashed before long. Rather than fix serious problems with FS2K2 MS came up with an excuse why they would not. Further, they came up with a BS statement about why they don't realease details of the 'flight model'. Based on the fact I've had to change virtually all the tables relating to wing and turbine peformance the idea that there is any 'propriatory data' in the AIR file is silly. If there is, it is not correctly applied.Ron

[Guest]

Assuming MS shows up at this years Avsim conference in Reading, PA, instead of groveling at their feet like so many did at the Tahoe show, hit them between the eyes with real questions. Ask them why they turned CFS3 into a big (bad) game and why they are doing the same to the civilian FS. Ask them why they claim to be a friend to designers and then limit the ability for designers to make aircraft "as real as it gets".Get their business cards and write down quotes. (as real reporters do) Then you can post the quotes in this and other forums. Make them accountable for their actions.Warning, some MS groupie die-hards do not like it when you tell the Emperor that he's naked. Dave Eckertwww.daviator.comPS Thanks again FSAviator for the great Stearman FDE!

[Guest N73GX]

First off, I

[John_Cillis 2,406]

Jason...On the proprietary "excuse"--I scoffed at this when I read it from Microsoft, and I still do. I just can't accept that Cessna, Boeing, etc have sensitive data stored in the MSFS .air files that Microsoft feels compelled to protect. It'd be pretty scary, since that would hint at some tiny chip running MSFS built into some 172, controlling the way it handles in the air :) NOT!!!!The .air files and .cfg files exploit software methods to emulate aircraft, period. There's nothing proprietary about sitting in a cockpit and knowing how an aircraft feels and responds to input--whether it be via yoke, throttle, or external input (i.e. wind, temp, pressure, chop)... As developers, we either have the knowledge given to us to emulate that, or we don't. Cessna certainly can't say "sorry, you can't emulate our secret AOI parameters in MSFS" when any pilot can see out the window what they are, given their cruise settings. Essentially, Microsoft's withholding of info regarding the .air files simply gives a crippled picture of what we can do.If I could guess, the proprietary comment we saw from Microsoft was a poorly worded statement, meant to say that Microsoft's methods of emulating flight vs. what was buried in the .air files was proprietary. I think the aircraft.cfg came about as a concession that "some" parameters would have to be tweakable if pilots were to stay interested in the sim.If that is the case, I might then buy into the argument that Microsoft has been serving as at least a partial roadblock to development, and I almost have to wonder if they are setting up developers for some type of paid licensing scheme combined with an NDA of some type. In that case, my argument is the same I voiced for FSUIPC.... Payware development promotes FS2004 and sells it, just as FSUIPC based add-ons also promote it and sell it. If I were in the Microsoft team's shoes, I would at least start responding to what I suspect is a flood of emails.Last, in terms of your thoughts on the team being within Microsoft and this driven by a higher mandate, you are quite right. But I doubt Microsoft micromanages the process. The AOI/Twist issue that launched this thread seems more of an issue which didn't get trapped or it was done for a reason having nothing to do with dumbing down the flight model--such as the a/c behaviour being better modelled another way. Simply because the code was there before, and it doesn't seem to be active now. I think whatever happened was caused by the COF devel team alone, whether it was intentional or not. -John

[Chris Willis 8]

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 :-( Fs2004 Beta Ms testerThanksChris Willis[link:fsw.simflight.com/FSWMenuFsSim.html]Clouds And Addons For MsFs

[John_Cillis 2,406]

Chris...I understand why you suggest people wait for the SDK, but many can't afford to--they have projects in the pipeline now that they'd like to tune right. Historically, SDK's have been released so late in the sim's cycle that the a/c designers end up releasing products that don't entirely meet their design vision.-John

[LAdamson 240]

>If I am doing a>serious flight you will not find me going to spot view unless>I am taking a screen shot. Nothing to do with the rest of this interesting thread.........But sometimes "spot view" is more realistic than either a VC or 2D view. They're both far too limiting in peripheral vision. If you need to spot other aircraft or do any low level bush type flying, the panaramic view from "spot" is much closer to what your eyes would actually see. When on these types of simulated flight, I do a lot of jumping from spot, VC, full screen (no panel), and 2D panel if required.L.Adamson

[nudata 10]

GREAT IDEA. In addition to taking notes on the responses of the Microsoft representitive, please note who tries to move you away from them using the usual excuse that you should not monopolize their time as they try to shut you up. Above all be courteous. The poor soul that they send is probably as frustrated as you are. The Team knows the problems but the "skilled" marketing types do micro-manage and can ruin a products development - FLY!. Once a pig-headed marketing type determines that the development of visuals is 90% of the market goodbye to real simulation. How can a dumb analyst ever understand the complexities of the market. So press for answers. If none are forthcoming do not settle for the "we will get back to you". That is a personal insult and means go away you are bothering me. If that happens get the name and email or number of who you should contact for the info.Perhaps a miracle will happen. We know that the Product Manager has either read or knows about the issues. The smart thing for him/her is to arm their representitive(s) with a solution(s). This would gain a lot of friends quickly at no cost since Tom is probably picking up the tab for the hotel at least.I would EXPECT Avsim to have a "reporter" speaking with the Microsoft person(s). From that should come the answers we expect not the usual drivel about the wonder of flight, how hard the team worked, how Wagstaff contributed, and how the next upgrade will be even better. 2 years between patches is poor customer service.Dick KLBEPS: I did marketing and product development and a very critical area. It sets the product's tone and direction. The analysts must then follow. If marketing believes pink trees will sell - code it.... or else...>Assuming MS shows up at this years Avsim conference in>Reading, PA, instead of groveling at their feet like so many>did at the Tahoe show, hit them between the eyes with real>questions. >>Ask them why they turned CFS3 into a big (bad) game and why>they are doing the same to the civilian FS. Ask them why they>claim to be a friend to designers and then limit the ability>for designers to make aircraft "as real as it gets".>>Get their business cards and write down quotes. (as real>reporters do) Then you can post the quotes in this and other>forums. Make them accountable for their actions.>>Warning, some MS groupie die-hards do not like it when you>tell the Emperor that he's naked. >>Dave Eckert>www.daviator.com>PS Thanks again FSAviator for the great Stearman FDE!>>>Dick KLBE

[John_Cillis 2,406]

I have paraphrased and edited the reply I received for reasons of the NDA under which I am still bound, but I was granted permission to share this. I won't comment--I'm not an engineer, so I can't say whether what is mentioned makes sense. But I (and the devel staff at Microsoft) hope this helps:_______________________________________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. In most aircraft, the incidence and twist angles are relatively small, and generally even offset each other. Thus, the net effect is usually small. The correct thing to do, which is what was changed, is to go into the table with alpha for the whole airplane, because we don't really care what the wing does by itself. We are simulating the whole airplane, which is what the table represents. So this is actually a correction.In reality, this shouldn't "disable" any aircraft because of the nature of these angles as mentioned above. While it is understandable that there may be minor differences with FS2002 performance, most users haven't noted any major problems because of the reasons mentioned above. So where are the complaints coming from? First, --flight models where the incidence angle is used to tune the cruise pitch angle of the aircraft in flight. This is an incorrect method that would result in masking an incorrect lift table with a bogus incidence angle value. The lift table should be tuned, which in fact people are already discovering. The other thing that is going on is that people are changing this value, and when they see it doesn't affect the runtime, they assume something is broken. In the FS2002 SDK, we explained that manyvalues are there for use in the Fsedit aero generation. These values are still inputs into the aero generation. This is being updated in the (soon to be completed) FS9 aircraft sdk.___________________Edit...I should add (and I'm guessing) that the last paragraph means that the new FSEdit will no longer reference the two variables, as essentially the aircraft.cfg is a result of FSEdit--not the other way around.

[Guest]

The SDKs from MS remind me of an old MS joke. A pilot coming into SEATAC loses his navigation equipment and gets lost. He dips down below the clouds and as he flys by a building with an open window shouts "Hey! Where am I!?" The person in the window shouts backs "You're in an airplane!"With that the pilot changes his course and makes a perfect landing.Amazed his passenger exclaims "Wow! How do you know where to go from what the guy in the window told you?" The pilot explains "Simple. Judging from the answer I got which was totally correct but totally useless, I knew it must have been a Microsoft employee giving me the answer. Therefore I was able to deduct where I was since I know where the MS campus is in relation to the airport."The only difference is that the SDKs are often wrong.David Eckertwww.daviator.com