Manifold Pressure

[taguilo 33]

""Your job is making sure that the big needle with the knob on top is displayed at exactly 50% in the console arc when the gauge is sending the message 'big needle with knob on top = 50% travel', and nothing more.""It depends. If you are working on a project that has to be as real as it gets, you need to suit FS parameters and simulate gauge readings so that 'big needle with knob on top = 50% travel' comes from the REAL aircraft requeriments and not otherwise. That's the big challenge every panel developer has to deal with. In fact, most of the very popular payware panels (LDS, PMDG, etc) has some "cosmetics" on their gauges, as to simulate as much as possible the real systems functions.FS .air file is a pretty well job done by the MS team. However, in some sections, like Engine tables for example, things are a bit rigid. Interpolation between columns follows a linear pattern, where in RW values usually follow a polinomial order, so no matter the best work you do with those tables, there would be inaccurancies that can be solved by coding the panel gauges properly.EPR and EGT in turbo/jet engine are unrealistically modeled to say the least. But they can be simulated to match RW data almost perfectly, and with no penalty at all in aircraft performance.I agree flight dynamics should be respected, but not to the point of compromising REAL data output in panel gauges for those of us who want to play "real", in those situations where FS performance won't be substantially altered by customized code.As a specific example, it tooks me quite a lot of time to program the REAL engine startup sequence for my 757, yet being not finished at all. The complexity of this process goes well beyond what the generic FS jet engine is able to simulate, and there is no smart FD adaption that can make the numbers match as needed. But a bunch of XML polinomials did make my day, and now the needles point where Boeing (and not MS) intended they have to.""<>Of course it is. Those data are then carefully imposed on the engine specific flight dynamics by the flight dynamics author.""Unfortunately, flight dynamics alone can't solve much of complex aircraft system's behavior, due to the inherent limitations stated above. That's when smart coded gauges do their job...""Consequently there is no problem to be solved.""For all of us who make panels for our own enjoyment (or other valid reasons), thanks god ALWAYS will exist problems to be solved!:-) Tom

[Guest Douglas K]

FSAviator,Man, as much as I hate to admit it, it looks like Bill Leaming was right when he stated in another thread that if someone asked you for the time, you would build them a watch. More like an atomic clock

[n4gix 4,947]

"Man, as much as I hate to admit it, it looks like Bill Leaming was right when he stated in another thread that if someone asked you for the time, you would build them a watch. More like an atomic clock

[Guest Douglas K]

>>>>Even though I'm a member of the "professional develolper class," I'm humble enough to admit that I'm on one of the lowest tiers - if not the bottom itself.<<<

[nickpike 0]

>>>>I

[Guest _FSAviator_]

Answering Nick's questions in full took hardly any time at all, but useful information in the forums is increasingly shouted down by consumers who have failed to control what happens within FS9, but who feel the need to blame developers for their failure. That plague has now spread to developer forums. My explanation of the bi-polar nature of the market was mostly directed at Nick. He has to decide who his target consumer is. The 2% or the 98%. If the former he must obtain the manuals and impose the data upon his product. If the latter he should neither bother, nor apologize. Ford have no reason to apologize for developing and selling the Focus just because a Ferrari is what a select few demand. Those who desire a Ferrari should not go to Ford dealerships and rant because the Ford dealer is unable to supply a Ferrari and those who supply Fords have to stop pretending that they are just as good as Ferraris.This thread is all about the realistic coding of MAP v rpm correlation in piston engines. I have explained that we have known for many years how to solve all the relevant problems of realistic usage and development, but also that since 98% of consumers do not desire realism there is limited reason to develop realistic code. Douglas, I devoted significant time to your point about supercharger operating complexity because I thought you would appreciate a candid explanation of why a capability which you have requested more than once is still not available. Since both turbochargers and superchargers have waste gates and the means to simulate those is available from third parties your specific wish can only be that the consumer be required to control the rpm of a supercharger manually and independently from engine rpm which they are already required to control manually and independently from fuel flow. I believe you have failed to understand that there is no way to make this optional. It can only be present or absent.I wonder if you believe that because developers do not impose this extra burden on consumers that we do not automate the blower switching? The consequences of blower switching is often incorporated in products aimed at the 2%. What most of them would not welcome is mandatory manual compliance. It follows that if a consumer using such a product wishes to perform manual blower gear selection all they need to do is add the requisite number of dummy supercharger gear selectors to the relevant cockpit environment and add the manual switching to the handling notes. Experienced non aircrew consumers are struggling with the mandatory realism already present in some products. Even those who develop for the 2% and who have succeeded in incorporating substantial realism into their simulation experience have to think carefully about the net advantage of making a realistic automated process manual and mandatory.Experienced developers have a good feel for how well consumers are coping with current products and are pushing the mandatory realism boundary as fast as they dare, but before they can add more mandatory realism they need more consumers to develop the intention to incorporate realism within their simulation experience. That is why those who are pushing the realism boundary forward need to negate the nonsense from the naysayers, and explain that nothing is impossible provided sufficient consumer demand exists.Consumer acceptance of increased mandatory realism is not a payware versus freeware issue at all. This is about pushing boundaries of consumer acceptance. It is not about money. The market gets what it demands from both payware and freeware developers.<

[adr179 0]

WOW, this topic really developed! Are we finally, after two pages of bla-bla, after offending 98% of FS community by declaring them "not interested" and some other dueling, maybe ready for some positive creativity?Since, Douglas, the plane doesn't need to be a vintage category, even new production planes with wariable pitch propeller (PA32 Saratoga or PA46Malibu or the twin Senecas) still uses the same technology and consequently their MP raises if the RPM is reduced, there is no "set it, forget it" option like in the turoprops when managing the power settings. I don't care what Microsoft will or won't do, their main goal is to sell the product by making it more and more "sexy", but I'm sure there is quite a hefty number of users that do know the stuff. Personally I don't mind if there is a flock of seagulls in my home bay or not, but I do get excited if the aircraft, it's systems and instrumentation are far from what they're supposed to be. Have a look at the FS9 default DC3:RPM and MP gauges are racing from their minimums to maximums at a rate that would make any formula one driver say:"Hey, I need this kind of engine in my car!", but they were supposed to imitate the reactions of a 1830 cubical inches in 14 cylinders of the R-1830 Twin Wasp. The RB needle of the ADF is able to turn from the off to the position of the current value in a fraction of a second, the ADF gain is "jumpy" and indicating signal only to some 10 miles from the station. And there is more, but there are still some people here on the forums, that will claim, that everything was already perfectly done, and nothing needs to be changed and these claims are as furious as screams of a drowning person. I did managed to cure most of the mentioned issues by, let's say tweaking, of the existing gauges with no penalties whatsoever and got stuck with the manifold pressure, since I don't know enough of XML coding. I do know which relationships need to be adjusted, but can't produce a working code for the situation. My activities in this topic were never intended as a criticisms of a product called MSFS 9 - it is treaded as a game, all of us who are trying to increase the level of it's realism can only be thankfull to the Microsoft for providing us with the open code and SDK's, making all this a great hobby for all of us and a job and source of income for the best. Is anybody trying to solve the MP gauge behavior issue?

[n4gix 4,947]

>Have a look at the FS9 default DC3:>RPM and MP gauges are racing from their minimums to maximums>at a rate that would make any formula one driver say:"Hey, I>need this kind of engine in my car!", but they were supposed>to imitate the reactions of a 1830 cubical inches in 14>cylinders of the R-1830 Twin Wasp. The RB needle of the ADF is>able to turn from the off to the position of the current value>in a fraction of a second, the ADF gain is "jumpy" and>indicating signal only to some 10 miles from the station.You are describing two different issues: gauge dampening and gauge input errors.The example of the ADF needle is a case of insufficient "gauge dampening," meaning that the rotation of the needle requires additional lag, or latency to at least provide the appearance of reality. In the real world the bearing from two tuned NDBs does in fact change instantaneously, but the indicating needle has a dampening mechanism added to mitigate quiver and rapid movements.The example of the MP gauge on the other hand, is a case of gauge input errors. This does not make the gauge faulty: it is reporting accurately whatever input is provided to it. Granted, as in the case of the ADF needle, some additional dampening may be applied, but this will not change the input error(s).As FSAVIATOR points out, all the calculations are done within the core code of FS, based on coded tables within the .air file and/or data sets enumerated in the aircraft.cfg file...If you wish to have the MP gauge on the DC3 behave with fidelity, there is no place other than the FDE to make such adjustments.It is certainly possible to code some algorithim within either a C or XML gauge that will fake such behavior, but that won't alter the fundamental performance behavior of the sim's engine model, nor its operational behavior.

[adr179 0]

Thanks for Your reply Bill. I'm aware of and do understand all of Your statements. And I never claimed, the MP gauge in any of the default aircraft was faulty, my only claim was always about unrealistic behavior, otherwise I know that the gauge is showing exactlly correct values supplied from the air file and Aircraft.cfg.As I already said, I managed to produce quite resonable behavior of all other gauges but MP. I was fiddling with the 500 range values in the air file to achieve at least some feel of big mass inertia in the engine propeller combination, but the problem with the MP gauge persists and I really don't see other solution but (from the purist's point of view) to fake the gauge behavior, since I strongly bielive, that the final user won't bother how it was done if it "plays" as it should. I really don't expect any other parameter will need an alteration after implementation of a gauge modified in a way I already described before. But even if I'm wrong about this I don't see a problem why the necessary parameters in the air file and Aircraft.cfg couldn't be changed afterwards if necessary.

[Guest Douglas K]

>>>>Answering Nick's questions in full took hardly any time at all, but useful information in the forums is increasingly shouted down by consumers who have failed to control what happens within FS9, but who feel the need to blame developers for their failure. That plague has now spread to developer forums. <<<

[Guest Douglas K]

>>>>Since, Douglas, the plane doesn't need to be a vintage category, even new production planes with wariable pitch propeller (PA32 Saratoga or PA46Malibu or the twin Senecas)<<<

[n4gix 4,947]

I'm proud to announce that I've submitted FSAVIATOR as a candidate for the "2006 Verbose Vendor of Vacuuous Verbiage Award."The VVVV is a very prestigious award!

[Guest _FSAviator_]

I have not dodged any questions. I have instead explained the misconceptions upon which each rested. Some here still demand that an answer matching their misconception be provided. That would not be productive. I will ignore the childish name calling and point scoring to explain the last vestiges of what still seems to be misunderstood.A developer is anyone who develops a product. Product development is the process by which value is added to the product. No one here needed a dictionary to understand those simple concepts even if they had never thought about it in those terms before.If realistic values for each of the variables and tables made available by Microsoft within the flight dynamics become available to a developer and they are then encoded within the flight dynamics the correlations between those variables also become realistic. The variables and tables provided by Microsoft are the ones required to achieve that goal. I am not going to list all the variables to be researched or their location in the FD. That is all readily available elsewhere. Creation of the level of realism desired by aircrew requires very extensive research which may also be very expensive research. It is no use demanding over and over again that I explain how to calculate the values to be encoded. I have explained that they must be researched.If they are not researched generic code that meets the needs of 98% of this community will need to be encoded instead. The correlations will be false because the data will be false. Fewer than 2% of consumers will notice or mind. Lack of research data needed to encode behaviour X and Y or system X and Y does not imply that MSFS cannot deliver X and Y. It only implies that the research was not done because the target consumer had no relevant need.Yet, it matters whether MSFS can, or cannot, do X and Y in principle since knowledge of what it can and cannot do is the first criterion for deciding whether to bother to research the data in question. The more that consumers claim that Microsoft air files are a done deal and that MSFS cannot do things that it can do the less likely it is that anyone will bother to do the research that would deliver the enhanced realism to consumers.Those who name variables for Microsoft do not necessarily have a professional background in aviation. The fact that MSFS only has a turbocharged = variable, but no supercharged = variable, does not mean that it can simulate the operation of turbochargers more easily than superchargers. It only means that a variable which should have been named more pedantically and generically as supercompressed = 0/1 was 'misnamed' as turbocharged = 0/1. Equally the fact that MSFS has waste_gate status variables rather than the pedantically more correct and generic automatic_boost_control status variables, does not mean that MSFS cannot simulate automatic boost control in supercharged engines as easily as automatic boost control in turbocharged engines. Again it just means that the naming of the variable was 'wrong' at the pedantic level of professional aviation knowledge.Automatic boost control in supercharged engines in real life is no more achieved by variation of the gearing or variation of supercharger rpm than it is achieved by waste gates. It is typically achieved by aneroid monitoring of overboost and automatic operation of the throttle butterfly after auto-disconnecting it from the cockpit throttle levers. Supercharger rpm does not vary as has been suggested and the means by which overboost protection is provided has nothing to do with gearing. However it does not matter how either system for either gas compressor type achieves automatic boost control in real life. Developers have to implement it by other means in MSFS regardless. There are neither throttle disconnects nor waste gates inside computers. Pilots are the first to forget that they are operating a computer not an aeroplane.Supercharged engines that have automatic boost control in real life, (and most of them do), can be simulated using the misnamed variables as easily as turbocharged engines and their specific means of regulating boost. In MSFS supercharged engines 'have waste gates' because the automatic boost control variables were 'misnamed' by Microsoft as waste_gate variables. Those who choose to promulgate the idea that MSFS cannot already simulate superchargers as easily as it can simulate turbochargers are simply wrong. Microsoft do not need to research how the real systems work. They know. They have provided the means to encode their operation. They have just used variable names that are 'inappropriate' at a pedantic level.<

[Guest Douglas K]

FSAviator,Kindly read the following very carefully. I

[n4gix 4,947]

>Bill Leaming immediately understood what I was saying, and>stated that he