Hi.I don

Lou I do not think this thread is aimed at Dreamfleet but a chat about the limitations of the MSFS FDE in general?No one has mentioned a single twin created by anyone which is close to reality in the slow speed engine out scenario. I take the point about forces and control hardware although that isnt the only equation.I have purchased both the Bonanza and Baron and both are truly stunning creations.The Bonanza is my single of choice because it is so good in every respect and I have to admit that at present it is the only single that I use in FS.I am sure that you and Dreamfleet are aware of the limitations in MSFS and equally are looking for ways to plug those limitations in striving for ultimate realism?I didnt see this as a critical swipe at Dreamfleet.I for one wouldnt take part in such an exercise with a producer who I hold in such high esteem.Best wishesPeter

>Allcott, after searching the FAQ and all the posts back to>September in the DF forum(s), I still don

X-plane got its certification due to its ability to simulate asymetric flight. The certification is only relevant in tandem with the certified hardware. ELITE based FNPT II simulators, whose graphics so many people find laughable, is also certified due to is ability to replicate the key elements of the flight envelope accurately enough.Expecting an all rounder like FS to faithfully mimic the minutiae of nitty picky aspects of flying is unrealistic. Also, modelling Vmc accurately is probably waste of time other than for demonstration purposes. In a real aircraft you will never be permitted to shut down an engine or use a zero thrust setting (simulates a feathered prop) on one engine at anything below single engine safety speed (Vsse) so if you are looking to relicate realistic operational procedures don't worry about it.

Can you please give me a link to where Ron Freimuth pointed out the errors in the FDE?

>Can you please give me a link to where Ron Freimuth pointed>out the errors in the FDE?No, not the errors in the FDE, the errors in the Zyskowski .pdf.http://www.avhistory.org/scripts/MegaBBS/t...eID=12259#12259Allcott

I apologize for making those assumptions about DF. I confess I know basically nil about gaming/sim programming and I have the greatest respect and admiration for you guys that do.To satisfy my mechanical engineering curiousity, I was waiting (and hoping) somebody would post a technical explanation something along the lines of,

>>I was waiting (and hoping) somebody would post a technical explanation >>something along the lines of,

I checked that link. Ron Freimuth says "I might say that some of the components shown in the paper do not work" but as far as I can see doesn't say which.

>There is no indication in that document that>the author has been allowed access to the privileged>information that would be required to reach the conclusions he>does, and indeed Ron Freimuth, one of the leading lights in>the FDE world, has already pointed out errors in the document,>which suggest to me that the author - a wiz on aerodynmics ->knows naff-all about the MSFS FDE. What that suggests to me is that neither you nor Ron F. know just who Mike Zykowski is, or what his bona fides are: http://blogs.technet.com/skyhawk/I'll stick my neck out a bit and bet that a person who works directly on the development of the product likely knows a great deal more than anyone who merely works with the product in question... :-lol

> think a flight model could, if there was enough variables to fully >express the multitude of changes that occur when one engine quits, >or there is a generic algorithmic equation that will take care of >event satisfactorily. ELITE falls into the first category because >it is all hard coded and X-plane into the second. I guess from the >Dreamfleet view, that with FS it is like pressing bubbles on >wallpaper, you get rid of one, only to find the problem pops up >again somewhere else.I wonder if there

Allcott,Thanks for your explanation:>MSFS has a time based protocol on control surface response to>controller input, NOT just movement. You should carry out your own>investigations into this as the implications for the interchange>between your CH Products rudder and YOU may have a bearing on how>the control surface responds in the sim. If you adjust the>sensitivity settings then sit in spot view you will see what I>mean. Reduced sensitivity doens't just reduce peak response value,>it also reduces the RATE at which the control surface responds to>the controller. This can lead to overcontrol issues as you may>believe when you stop applying additional input, the control>surface in the sim will stay at that last setting. It doesn't. Yes, I admit I was not aware of this until recently even though it

>What that suggests to me is that neither you nor Ron F. know>just who Mike Zykowski is, or what his bona fides are: >>http://blogs.technet.com/skyhawk/>>I'll stick my neck out a bit and bet that a person who works>directly on the development of the product likely knows a>great deal more than anyone who merely works with the>product in question... :-lol Well, this I would like to believe, but Ron Freimuth, Jerry Beckwith, Herve Sors and several other `back room` boys have proved beyond reasonable doubt that several of the assumptions that MS make about the structure of the .air file are not correct. That's YEARS of research, backed up by evidential analysis, cross-corroboration and peer review, not just throwaway comments on a forum. One suggestion is that the air file SDK has not been released because MS didn't write it, don't own it, and don't have to understand what's in it because it's farmed out to outside contractors. If that isn't the case, one of the MSFS bloggers could tell us on one of their blog sites exactly WHY the SDK has never been released. The hogwash about `proprietary information` from aircraft manufacturers being used in the air files is so clearly baloney, you can make a sandwich with it. We can look at the air files themselves. We can decompile and analyse. If there is information of a privileged nature in there, they didn't do a very good job of safeguarding it! The air file is a set of mathematical equations, nothing more. By themselves each is important, but it is the interaction of the many components that makes what is going on inside really interesting. MSFS included modified lines and equations in the adapted-for-FS2004 air files for the default aircraft that have been shown to do NOTHING AT ALL. Why would they do that if they understood it, and if the information IS proprietary, why include potentially private information if it is unnecessary for the proper operation of the air file in question? And the BIG question: if the information is proprietary, then why is it wrong? And how can aftermarket developers, with no intrinsic knowledge of this `insider information` produce results which are more accurate, more realistic and just better than the company who supposedly devised the air file structure and had direct access to the privileged data used to compile it?So it is entirely possible that MZ is wrong. I'm sure Ron could give you the technical answers, but I'm equally sure it's beyond the scope of this discussion in this forum. But it has been discussed elsewhere http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchand at the Avhistory forumshttp://www.avhistory.org/scripts/MegaBBS/f...w.asp?forumid=5So you can see this is not a simple discussion at all, it even touches on areas of the sim that we ALL thought we knew - like limiting the fps might actually enhance the flight modelling if it matches the refresh rate in the sim 16-32-48 fps may be much better than 20-30-40 fps because the FM update rate is fixed. Never seen a thread about that, but it certainly lends an intersting slant to those who swear that the frame rate slider should be set to `unlimited`. This is a very complex issue, with much known, but still much more to uncover. MS have been exceedingly quiet on this subject and frankly, given their business ethics, its not beyond the realms of possibility that the Zyskowski document is a deliberate red herring. But it is more likely that most of what he says is accurate - to the best of his knowledge.Allcott

>>I wonder if there

In http://forums.avsim.net/dcboard.php?az=sho...ing_type=search Ron Friemuth says:"I see MSFS iterates the FM only 16 times per second, doubling to 32 Hz at times. JSBsim, used in FlightGear has a user settable rate, and 120 per second is typical." The paper says:"Flight Simulator incorporates a subroutine which computes what DeltaT should be based on the current framne rate the program is achieving. As the performance of the program degrades, the simulation dynamically alters the time slice to take less processing time between cycles.Combat Flight Simulator utilizes a fixed DeltaT of 16Hz... We therefore incorporate a doubling... ultimately achieving a fixed DeltaT of 32Hz"I think we need hard evidence of where Microsoft is wrong - not just unsubstantiated assertions.