Enabling and managing power output (including WEP) in F...

[Guest _FSAviator]

Avsim forum rules not withstanding, I reserve the right to publish what follows elsewhere, and by other means, but extend that right to others only in respect of the included _ref file which may be copied and modified at will.The original WEP thread caught my eye, but it quickly drifted off to discuss eye candy, so I decided to start a new one. Having some time on my hands yesterday I decided to attempt an explanation of power limits and the best way of providing end users with the possibility of simulating them realistically. A basic understanding of air file editing, gauge code editing, and output testing during product development is assumed in what follows. However I have tried hard not to assume any prior understanding of the real world issues or acronyms. I have no doubt that in a post of this complexity there will be some errors and omissions.How to simulate use of a particular power setting in FS8/9 is a deceptively simple question, but it requires a rather complicated answer. So complicated that I have ignored turbine engines altogether. Including War Emergency Power (WEP) or any number of different power settings in MSFS has not been a problem since FS6. WEP and overboost are not special cases. Every throttle gated, multi throttle, or supercompressed piston engine has a whole series of power ratings, some of which are limited in duration, by catastrophic failure, injector tank capacity, international treaty, national certification, time between overhaul criteria, or mandatory employer policy and military doctrine. WEP is just another example of a power setting that the FS designer can allow the end user to create. The only problem is explaining to the end user how, when, and why they should create WEP, or any of the many other power settings and limits that govern realistic use of the engine in question. As in real life it should be up to end users whether they observe or ignore the promulgated safety limits. Unlike real life it is entirely up to the FS aircraft design team whether, and to what exact extent, the end user is penalised for non compliance. None of the following applies to aircraft produced or repainted for offline AI use in MSFS or CFS, or to aircraft developed for CFS online combat, but the following capabilities of CFS may be relevant. CFS default flight dynamics allow the FDE author to specify a different maximum supercompression and critical altitude either for WEP or for safe overboost, but not both. Nor do they allow a different max engine rpm when applying WEP, so default CFS FDE do not usually allow realistic simulation of WEP and/or overboost. 'Mopar' Mike Wagner has nevertheless provided the FS8/9 freeware community with a 'WEP switch' that can emulate this default CFS WEP capability. A Google search or download of e.g. any recent P-38 upload for MSFS (not CFS) should provide his FS8/9 WEP switch gauge. Observe any copyright restriction that may apply. However the ability to emulate CFS default FDE may be of dubious value when designing aircraft for use in FS8/9. I will return to real world usage and recommended usage of 'WEP switch' gauges in MSFS far below.When an FDE author writes the code for any large piston engine they must logically make (at least) TOGA (Take Off and Go Around) power available. In real life TOGA usage is (time) limited just like WEP usage. The gauge author for the project can include code within the CHT (Cylinder Head Temperature) or EGT (Exhaust Gas Temperature) gauges to gradually, or suddenly, fail the engines when they reach a threshold temperature due to engine abuse by whatever means. TOGA abuse, WEP abuse and overboost abuse are not special cases. Failure to operate the cowl flaps, excessive leaning etc., can have the same consequence (or none) in FS8/9 terms. These are just realism choices that are usually omitted by the design team as most end users cannot cope and become frustrated by the consequences of such encoded realism.Study existing high quality aircraft uploads which feature large supercompressed engines for use in FS8 or FS9 and you will see that they provide detailed handling notes which explain how to manipulate MAP and rpm to manage applied power. These are the key to including WEP or any other power limit in MSFS. They explain how each power setting is achieved via a safe MAP and safe rpm which will avoid both over torque (excess BMEP) and overheating, (of the cylinder head, or exhaust valves when present). They also disclose any associated matching operation of mixture levers, radiator shutters, cowl flaps etc. They may also specify the temperature limits to be observed since what is safe in ISA (International Standard Atmosphere) conditions may be unsafe at higher outside temperatures. However this is essential only if engine failure is to be triggered via the CHT or EGT code. TOGA is no more continuously available in real life than WEP, so even if the aircraft is an airliner rather than a combat aircraft the settings for METO (Maximum Except Take Off), each stage of climb power, various cruise and approach settings need to be disclosed, together with appropriate guidance on the circumstances which dictate whether it is MAP or rpm which should be manipulated and when each shift of MAP and/or rpm should, (or must), be made.Since MSFS does not have native support for multi speed supercharging it is always simply a question of telling the end user what MAP and rpm they must set to achieve the power setting applicable to each phase of flight. Each phase of the simulation is defined by the concurrent goals that the person conducting the simulation must achieve before moving to the next phase of the simulation. The goals to be achieved may be any combination of heights, altitudes, configuration changes, rates of climb, airspeed, waypoints or military / naval mission objectives, but they should be real goals mandated by the (engine) certification documents or real employer doctrine.The F10 key calls the on screen, in flight, briefing notes. Format the handling notes so they are step by step operating instructions and not a narrative. Make sure they explain the goals as well as the procedures that must be employed to achieve those goals. For use in FS9 compile the handling notes to HTML and save them as filename_ref.htm. I use MS Word as my HTML compiler as it is fully compatible with MSFS. Some (many?) freeware HTML compilers are not. Alias the appropriate compiled handling notes from each ui_variation in the FDE thus; kb_reference=filename_refIt is then up to the end user to press the F10 key and make use of the on screen briefing / handling notes to moderate MAP and/or rpm to create WEP / overboost / TOGA / METO / noise abatement or any other power setting relevant to that engine, as and when appropriate. The gauge author decides whether the end user will be penalised for non compliance and in what way. If appropriate to the engine a dummy switch for changing supercharger gear can be included in the panel and the relevant instructions may be included in the handling notes.When creating handling notes try to avoid V speed jargon, if possible, as it will be useless to most end users and pilots can understand plain words just fine. Here is an example filename_ref.txt which may be copied, saved, modified and then compiled as filename_ref.htm. ****************************************************Douglas DC-6A/B Handling Notes (R-2800-CB17 engines)****************************************************NOT FOR REAL WORLD FLIGHTThis version of the DC-6A/B has four 1750hp Pratt & Whitney R-2800-CB17 Double Wasp engines which are carburetted and highly supercharged to give international rated power up to 15000 feet. 2500hp is available for Take off and Go Around at sea level, and for two minutes in case of emergency using water/methanol injection.METO power is 1900hp up to 7,100 feet. Continuous safe operation of the engines beyond 1800hp without water/methanol injection requires 145 Octane fuel. The constant speed propellers can be feathered and have reverse pitch via the Martin Bar. Automixture control is provided, but may be overridden. All flight planning fuel burn figures are indicative and will vary slightly with altitude. ***************************************************************HANDLING THE AIRCRAFT****************************Take Off (with water/meth injection): SELECT - 145 Octane fuelAPPLY BRAKES MIXTURE - MANUAL FULL RICHCARB HEAT - COLDCOWL FLAPS - MIDTRIM 20% full range NOSE UP FLAP - STAGE 2CALL for TOGA POWER (2500hp)PROPS FULLY FINEINVOKE - water/methanol injectionSlowly apply FULL THROTTLE WHEN - > 60 inches MAPBRAKES - RELEASEROTATE at 120 KIAS (@ 107000lbs) Establish positive rate of climbGEAR UP ACCELERATE > 130 KIAS @ <= 500 ft/minCLIMB 300 feet AGLFLAP - STAGE 1ACCELERATE 140 KIAS @ <= 500 ft/minFLAP - UPEstablish 500 VSI MIXTURE - AUTORICHCALL for METO Power**********************************First climb segment:SELECT - 145 Octane fuelMETO Power (1900hp)COWL FLAPS - MID51.5 inches MAP2600 RPM REVOKE - water/methanol injectionEstablish 500 VSI Check CHT < 260CPlan 620 USG per hourWHEN IAS > 160 KIASCALL for ATC climb power***********************************Second Climb segment:Compatible with 135 Octane FuelIFR minimum climb power: (1600hp)COWL FLAPS - MID41 inches MAP2400 RPMEstablish 500 VSI Plan 550 USG per hourCheck CHT < 232CWHEN IAS > 160 KIASCALL for Climb powerIF VFR or ATC have granted dispensation to climb < 500 VSIMAINTAIN 160 KIASWHEN VSI > 500CALL for Climb power***********************************Third Climb segment:Climb Power: (1450hp)COWL FLAPS - MID39 inches MAP2400 RPM160 KIAS (WARNING - 400 VSI at max weight)Check CHT < 232CPlan 500 USG per hourWHEN IAS > 160 KIAS @ 500 VSICall for Economy climb***********************************Final Climb segment:Economy climb (1350hp)COWL FLAPS - MID37 inches MAP (500 VSI at lighter weights)2400 RPM165 KIAS Check CHT < 232CPlan 450 USG per hour****************************Climb ABOVE FL160:COWL FLAPS - MIDFULL THROTTLE2400 RPM160 KIAS Check CHT < 232CPlan 440 USG per hour***********************************Max Cruise:CALL for max cruise (1300hp x 4)COWL FLAPS - CLOSED36 inches MAP 2200 RPMCheck CHT < 232CPlan 435 USG per hour***********************************Fast Cruise (FL195 and below):CALL for high speed cruise (1200hp x 4)COWL FLAPS - CLOSED33 inches MAP 2200 RPMCheck CHT < 232CPlan 400 USG per hour****************************Econ Cruise (FL155 and below):CALL for economy cruise power (4 x 1100hp)COWL FLAPS - CLOSED30 inches MAP2100 RPMCheck CHT < 232CPlan 370 USG per hour*****************************Econ Cruise (FL160 to FL225):CALL for economy cruise power (4 x 1050hp)COWL FLAPS - CLOSED30 inches MAP1800 RPMCheck CHT < 232CPlan 350 USG per hour****************************Long Range Cruise:When < 30% fuel remainsCall for long range cruise (4 x 1000hp)COWL FLAPS - CLOSED30 inches MAP1650 RPMCheck CHT < 232CPlan 325 USG per hour****************************High Blower METO FL150: (1750hp)FULL THROTTLE2600 RPM****************************Descent:ABOVE FL170 DO NOT EXCEED Mno = 220 KIASDO NOT EXCEED Vno = 250 KIASAUTOMIXTURE - ONCOWL FLAPS - CRACKED2000 RPMREDUCE MAP in stages of 3 inches (per minute)MINIMUM 20 INCHES MAPSee CARB HEAT below*****************************Holding:FLAP - UPCOWL FLAPS - CRACKED2000 RPMSlowly REDUCE MAPTo obtain 160 KIASCheck CHT < 232CPlan 230 USG per hour****************************Approach and Landing:SELECT - 145 Octane FuelMIXTURE - AUTORICHCOWL FLAPS - MID2000 RPM30 inches MAPREDUCE < 170 KIASLANDING LIGHTS - DEPLOY + ONREDUCE < 160 KIASFLAP - STAGE 1REDUCE < 150 KIASFLAP - STAGE 2REDUCE < 140 KIASFLAP - STAGE 3MAINTAIN 130 KIASON descendingGEAR DOWNFLAP - STAGE 4 REDUCE < 120 KIASFLAP - STAGE 5 Cross airfield boundary 107 KIAS (@ 88,000lbs) FLARE and LANDCOWL FLAPS - FULL OPENAFTER NOSEWHEEL CONTACTREVERSE PITCH (use Martin Bar) WHEEL BRAKES as required****************************Baulked Landing:CALL for EMERGENCY POWERPROPS FULL FINEFULL THROTTLE (auto-invokes water/meth injection)COWL FLAPS - CLOSEDROTATE and CLIMB 115 KIASClear of obstacle GEAR - UPACCELERATE >140 KIASCOWL FLAPS - MIDFLAPS - UP (by stages)ACCELERATE 165 KIASLANDING LIGHTS - OFF and RETRACT****************************Carb Heat:When < 30 inches MAP with an OAT below 5C (40F) use carb heat periodically to clear carburettor ice. Continuous use of carb heat is not recommended.****************************General:AEROBATICS are PROHIBITEDNEVER EXCEED FL230DO NOT EXCEED Vno = 251 KIASAbove FL170 NEVER EXCEED Mno = 220 KIASAP in use never exceed 217 KIASFLAP 1 never exceed 174 KIASGEAR DOWN never exceed 174 KIASFULL FLAP never exceed 152 KIASCLEAN STALL 107 KIASCritical Engine Out safety speed 83 KIASSTALL with FULL FLAP 83 KIAS********************************************************************************NOTE: The real world handling notes have been simplified for use with MSFS********************************************************************************This example of a _ref file may act as a guide to the information that needs to be researched and promulgated, but if you cannot find it all do not despair (see later). To allow the end user to employ WEP as well as TOGA all you have to do is research the values and set the top end of the air file power curve to (at least) the max WEP power, at the WEP limit boost, WEP critical altitude and WEP limit rpm instead of setting them to the TOGA limits. Then tell the end user the time and/or temperature limits of WEP, the goals it is used to achieve, how to invoke it, and how to revoke it, via a further section in the handling notes. They still need to know how to create TOGA, overboost, MIL, METO and all the lesser power limits that apply to that ui_variation. In the simplified FS9 flight dynamics the power curve is interpolated solely from TBL508 and TBL509 of the air file. The maximal data therein must match the maxima in the aircraft.cfg and should of course match the data in the handling notes, and the real engine data for the fuel being simulated to the maximum extent possible in MSFS, but the notes above and any which you may issue should apply to the published FDE. There are bound to be some differences and some alternative operating procedures in real life and of course the real ops manual also provides non ISA tables, dry take off data etc. In the example above the real engine has a two speed supercharger which MSFS cannot simulate, but as far as possible the air file curves are constructed to simulate low blower at low altitude and high blower at appropriate higher altitudes. However it is entirely up to the end user to create the power output of the different blowers using the promulgated MAP and rpm settings for the relevant altitude band. The more blowers the engine has the more altitude bands you must write specific handling notes for. Thus continuous use of METO for the engine failure case at any level is preserved with realistic performance. When designing multi crew aircraft for single crew operation within MSFS it is appropriate to consider the need to automate some functions on the grounds that they are being performed by the unseen co-pilot, navigator, radio operator, or flight engineer. In this already released FS aircraft cowl flap drag was enabled, but water/methanol injection and supercharger gear changes were automated and extended power use > METO was not penalised. Consequently end users could ignore the functional realism enabled within the upload if that was their preference, or need. The handling notes above incorporate only the minimum instructions needed to operate the aircraft and engines within their real world limits and more or less real world procedures. For this project we decided not to inflict BMEP limits on the end user via these mimimal on screen handling notes, but tried to ensure that all the procedures promulgated in terms of MAP and rpm complied with the real BMEP limits. A more comprehensive simulation of the flight engineer function, including BMEP monitoring, utilising additional data from the real flight manuals was enabled via other means for those who required more information and a more complex simulation. Within the handling notes called via the F10 key the phases of the simulation are arranged in a logical sequence for on screen use throughout. A checklist is something else and is much longer, but crucially a checklist does not tell the end user what simulation goals must be achieved before making the next power or configuration change. In case this is not clear let me repeat and explain in plain words one section of the handling notes. Skip it if you understand already.**********************************First climb segment:SELECT - 145 Octane fuelMETO Power (1900hp)COWL FLAPS - MID51.5 inches MAP2600 RPM REVOKE - water/methanol injectionEstablish 500 VSI Check CHT < 260CPlan 620 USG per hourWHEN IAS > 160 KIASCALL for ATC climb power***********************************After take off the aircraft is accelerated and the configuration cleaned up in accordance with the Take Off section of the notes. By the time all those goals have been achieved, the water methanol injectant may be (almost) exhausted. Take off ends and the first climb segment begins. The end user must now limit the engines to METO power by retarding the throttles to 51.5 inches MAP and shifting the rpm to 2600 using the rpm levers. Having done so and before making another tank selection, allowing MAP to drift from 51.5 inches or moving the rpm levers from 2600 the end user must achieve the three goals of the first climb segment. 1) Establish and maintain a rate of climb of 500 ft/min2) Concurrently achieve > 160 KIAS3) with a cylinder head temperature below 260 CelsiusAchieving all three goals of stage one climb using the maximum available engine power, which is now only METO, may take some considerable time and accurate flying. Depending on the altitude of the runway recently departed the end user may be continuously moving the throttles to maintain 51.5 MAP as air density diminishes. Only when these three goals are achieved concurrently is first stage climb complete. Appropriate new goals are then pursued with a new lower power limit in place. That reduction in available power for stage 2 climb is mandated by the terms of the engine manufacturer's guarantee concerning time between overhauls and military standing orders or civilian conditions of employment. Many of the limitations that must be observed when flying an aircraft are mandated by law, or doctrine, rather than Newtonian dynamics, but without the water/meth injection no more than METO is safely available for stage 1 climb. In case anyone is still missing the point the FDE author cannot come round to the end users house and apply these sequential power limits for them, and no FDE author or AI routine can replicate it as a script which an end user just has to install. The AI cannot read handling notes. It just provides cartoon animation. Programs such as FSNavigator can follow a flight plan using the AP, but the AP cannot read or apply handling notes either. Again it supplies cartoon animation around a more realistic route. All the FDE author can do is tell the end user what they are supposed to do, when to start doing it, and when to stop. If the end user fails to make the inputs they cannot simulate METO, MIL, TOGA, WEP, overboost or any other power applicable to that aircraft, but to create those power settings all they ever have to do is make the inputs specified in the handling notes. Contrary to popular opinion realistic flight dynamics are primarily something created by an end user, not something created by an FDE author.Note that METO is the maximum power that may be applied continuously and safely under ISA conditions. On a hot day, or in a hot climate, it may be necessary to offload passengers or cargo to achieve 500 VSI at > 160 KIAS and 8) When you have matched the simulation output to the handling notes, to the best of your ability, via iterative testing and rewriting of the curves. 9) REWRITE the handling notes so that they reflect the FDE you have managed to produce, the gauges actually included in the release panel, and not the real engines and gauges. You are producing all these software files so that someone can conduct a simulation using MSFS and not so that they can fly the real thing. Try to explain that FDE and panels are not mix and match, even though end users won't believe you. Tell the end user the inputs they must make to create the real world output during the simulation, even if they are not the real world inputs. Tell them which gauges on the release panel they must use to control their inputs (is the next input MAP or rpm) and which they must use to monitor their concurrent simulation goals in real time (is the next goal VSI or ASI related). 10) When you are sure you are ready to release the FDE use the simulator to extract, from the power curve you have just created, any missing data you never discovered about the real power curve, and now add the simulation derived data to the release handling notes. There is no real need to identify it as such.Please note that this post is not intended to rail against the distribution of FDE that are based on less than perfect data. That will always be the norm, and this post is not really about FDE anyway, but before you start taking data from the simulation curves you just created, instead of the real world, make those curves as realistic as you can.Of course only a few end users will take up the challenge of operating within realistic limits, using the handling notes you supply, but they are anyway the only end users who have any use for realistic FDE, so there is little point creating 'realistic' FDE without telling those few what the multiple power and aerodynamic limits are and how to observe them. Imperfect input data is not a good excuse for failing to provide handling notes to the end user to promulgate, as far as possible, how to operate the aircraft. I am not talking about teaching people how to fly an aeroplane, I am talking about providing the data a qualified pilot needs to operate that aircraft safely, and that includes the power management data.Books written by aircraft enthusiasts masquerading as aviation historians tend to emphasise the maxima of an aircraft's capabilities, often achieved only in one narrow altitude band, during a few minutes of TOGA or WEP. It is a poor way to characterise the capabilities of an aircraft or aero engine to an unsuspecting audience. Flight simulation, conducted with realistic handling notes, using carefully researched and realistic flight dynamics, can deliver a far more comprehensive and rounded understanding of that aircraft, its limitations and capabilities, than any book ever will, even though it will never match flying the real thing. If we make it possible for end users to obtain that greater understanding from their simulation time, we will have achieved something worthwhile.Decide with care whether to produce gauges that will penalise end users for non compliance with real world limits and procedures. I recommend that you allow end users to ignore most limits and procedures without penalty, as the vast majority will give up in frustration if you do not. Let them progress from pretending to fly aircraft to simulating flying an aircraft one step at a time. Most users of MSFS start out as aviation spectators who understand and crave only visual realism and cannot cope with the functional realism desired by aviation practitioners. Those who are minded to master the functional reality, (including non pilots), will take the time, and make the effort anyway, provided you give them the information they need. Sometimes however a particular aircraft was subject to a limitation or design weakness that became its defining trait. In those circumstances the whole character of the aircraft may be lost if you do not impose the key trait(s) on the end user.In this post I have tried to explain why FDE development is the lesser part of the process of providing the end user with the ability to create and manage WEP, overboost, TOGA, MIL, noise abatement, max climb, max cruise, normal cruise, econ cruise, max range cruise or any other of the many real power limits and settings which define the real speed, range and climb performance envelopes of real aircraft. From an FDE authoring point of view the larger problem may be production of the thrust curve from the power curve when you create the airscrew efficiency curve that is the interpolation of TBLs 511 and 512 within the FS9 air file. During the FDE design process take care to isolate development of the engine dynamics in TBLs 508 and 509 from the airscrew dynamics in TBLs 511 and 512 else you will chase your engine and airscrew input and output data in circles during iterative testing and development. Develop the engine dynamics first unless the airscrew is fixed pitch in which case you may find it convenient to develop both together.FSAviator

[Guest Douglas K]

>The original WEP thread caught my eye, but it quickly driftedoff to discuss eye candy, so I decided to start a new one.CFS default flight dynamics allow the FDE author to specify a different maximum supercompression and critical altitude either for WEP or for safe overboost, but not both. Nor do they allow a different max engine rpm when applying WEP, so default CFS FDE do not usually allow realistic simulation of WEP and/or overboost.Contrary to popular opinion realistic flight dynamics are primarily something created by an end user, not something created by an FDE authorImperfect input data is not a good excuse for failing to provide handling notes to the end user to promulgate, as far as possible, how to operate the aircraft. I am not talking about teaching people how to fly an aeroplane, I am talking about providing the data a qualified pilot needs to operate that aircraft safely, and that includes the power management data.During the FDE design process take care to isolate development of the engine dynamics in TBLs 508 and 509 from the airscrew dynamics in TBLs 511 and 512 else you will chase your engine and airscrew input and output data in circles during iterative testing and development.

[Guest Milton]

Gentlemen,Thank you very much for this "gift". I look forward to using it in my future efforts.Greatly appreciated.Milton

[Guest airhead]

Greetings gents,Good to hear from you again FSAviator. As always your offering is quite thorough and informative, as I have come to expect and appreciate. :) This is not to say that I fully understand it all (my head almost exploded on first reading), but that is, of course, my problem. Apologies for the 'eye candy' digression in the previous posting, I was just happy to get something to work for once, and the gun effects were the success du jour.Douglas, as I was the author of the original post, I can say that I would be happy to get ANYTHING in regards to WEP working at this point, be it a key press or full system simulation. In truth, I would prefer the full system sim, but as I currently hold sub-noob status when it comes to FDE, I guess you could say I'm working with a bit of a handicap. Modeling and xml gauge work are more my forte, but thought I would give it a shot as I have no other alternatives. Not being a real world pilot, aircraft engineer or aircraft mechanic, you can see why I might fall a bit short in this area. Ok, who am I kidding, I know nothing....which is why I appreciate the postings of folks such as yourself, FSAviator, Ron Freimuth (sp?) and others. I do my best to soak up what I can from the postings, but as you both know the FDE 'pool' is quite a deep one to dive into with no real world association to flying and aircraft.I, in fact, would like nothing more than to create an ultra realistic simulation of the P-47D (-25 or -30, haven't decided yet), as far as it is possible within the limits of MSFS. This is regardless of the fact that it might not be popular with the majority of end users, and as you both have stated, it likely would not be. As I am not a real pilot, and even if I was, would likely never have the opportunity to fly the real deal, the sim is truly 'as real as it get' for me at this point. The possiblity of simulating the reality of operating an aircraft is a large part of the attraction to this whole thing for me. After all, if I want to fly it like a game there are plenty of other options already on the market to choose from. I suppose I should start off with something a bit easier for the focus of my projects and work my way up, but I find the old warbirds too attractive to resist, and there are already enough C172's and the like available. I have no desire to fly a jetliner with a glass cockpit and flight computer, but prefer the hands on approach to flight. These (jets) have been quite overdone in my opinion as well. Anyway, I want to fly it, not have it fly me. I have a strong interest in the actual operation of these older aircraft, but unfortunately lack the bulk of knowledge required to produce realistic systems and complex dynamics. Maybe I'm selling myself a bit short here, but suffice it to say I feel that I know barely enough to be considered dangerous. At the least I'm willing to try....In closing, I offer my abilities in xml gauge programming (however limited) to a possible collaboration on simulating some of these systems if anyone is interested. Though if I'm not mistaken, Douglas also does gauge work, and quite possibly is better at it than I, so the value of my offer may very well be a moot point. Either way, I am glad to see that my post has sparked some interest and discussion on this subject and I sincerely hope that something good will come of this for the benefit of those who truly enjoy the sim for what it is (or is supposed to be), a simulation and not a game (don't tell MS though, they apparently still perceive it as a game, which I find a bit disheartening).Thanks again guys for your input in regards to my original question. I personally feel the sharing of knowledge and ideas is what makes the flight sim community so great! A good day and happy new year to the both of you. You to Milton. Still enjoying the hell outta your Aero Commander series, nice work! :)

[Guest Douglas K]

>Douglas, as I was the author of the original post, I can saythat I would be happy to get ANYTHING in regards to WEPworking at this point, be it a key press or full systemsimulation.As I am not a real pilot, and even if I was, would likely never have the opportunity to fly the real deal,I have no desire to fly a jetliner with a glass cockpit and flight computer, butprefer the hands on approach to flight. These (jets) have been quite overdone in my opinion as well. Anyway, I want tofly it, not have it fly me.In closing, I offer my abilities in xml gauge programming(however limited) to a possible collaboration on simulatingsome of these systems if anyone is interested. Though if I'mnot mistaken, Douglas also does gauge work, and quitepossibly is better at it than I, so the value of my offer mayvery well be a moot point.I sincerely hope that something good will come ofthis for the benefit of those who truly enjoy the sim forwhat it is (or is supposed to be), a simulation and not agame (don't tell MS though, they apparently still perceive itas a game, which I find a bit disheartening).

[Guest _FSAviator]

Some interesting points arise, and perhaps some confusion. I will begin with the first post from Douglas, but my reply is aimed at a wider audience and includes some 'Devil's advocacy'.<<..(MSFS).. does do a good job of modeling the basic aspects of turbochargers, and a single stage/single speed supercharger can be passably modeled by setting the critical altitude to a low value. >>The supercompression code in the FS8 flight model was bugged. The bugs have been patched in the FS9 flight model. So whilst it was necessary to declare a false value when writing FDE for FS8 it is now necessary to declare the true value when writing FDE for FS9. The two flight models are not compatible for aircraft with supercompressed, throttle gated or multi throttle engines.<>Increasingly the flight dynamics equations (FDE) are distributed between the air file and the (third party developer) gauges. This process began back in FS7. Unfortunately many end users do not understand this and believe that they can use any gauges (any panel.cfg) with any set of FDE. The simulation of significant functional reality always depends on the use of the provided gauges with the provided air file. This is especially true of power management, regardless of whether the gauges fail the engines after mishandling, as they do in the YS-11, or just control parameters such as temperature and drag without imposing a failure as they do in the DC-6A/B. Unfortunately some independent panel developers, (not gauge developers), add to this confusion. These days huge swathes of the flight dynamics could be in the project gauge code.<>The creation of flight dynamics files which permit enhanced functional realism should not deny those who struggle with the concept the opportunity to enjoy all the work put in by the MDL maker, panel maker and painters. I fear that any extension of the 'YS-11' trend to deny use of the rest of the package to those who cannot cope with the flight dynamics will backfire on those of us who wish to see functional realism incorporated in as many releases as possible. I use the YS-11 as my example only because Douglas K invoked it. There are quite a few other well known examples. I am not going to address turbine engine dynamics in any reply in this thread.Microsoft have, on the whole, worked hard to develop a 'flight simulator', which favours the aviation spectator over the aviation practitioner, but which does not disregard the needs of the minority. I think that third party developers who favour the needs of (us) the minority over the needs of the majority, are not just risking a backlash against their offerings, but potentially against functional realism itself.I cannot resist the occasional jibe about 'eye candy' ('Airhead' knows me well enough not to take offence), but I fear that the FS community will split into opposing camps, rather than co-existing collaborators, if developers are not careful. I know I have often annoyed my fellow producers by arguing for more functional realism than they wish to contemplate, but never at the expense of restricting use of their MDLs, panels or repaints to those who share my enthusiasm. Since gauges and air files are increasingly interwoven and interdependent this is an issue for both FDE authors and gauge authors to contemplate.My solution is that proposed at the top of this thread. Argue the case with fellow producers for the maximum possible functional realism to be included in the project. Enable it via gauges and FDE and explain how to access it, but don't force it on end users. I am all in favour of encouraging more and more users of MSFS to understand and incorporate elements of functional realism into their use of the product, but I am against punishing them (significantly) for failing.Although the number of downloads achieved by a product are often used as a measure of its success, they are no measure at all of how many hours of enjoyment it provided to its downloaders, (or purchasers). If we could obtain data for utilisation I feel sure the most utilised aircraft would be those that enable many hours of challenging and realistic use by a few 'hard core' users and occasional unrealistic use, without too steep a learning curve, by the majority.<>After reading this I fear you may have misunderstood parts of my post. I will have another go at explaining why no compromise is necessary. 1) Reset the engine maxima to 2800 throughout2) Reset max MAP to 52 in the aircraft.cfg (only)3) In the handling notes promulgate max MAP and max rpm for each of the two circumstances. If a single set of FDE must simulate both circumstances, then the FDE author must allow up to 2800 rpm and 52 inches to be applied by the end user, but it is entirely the job of the end user to apply the MAP/rpm appropriate to the circumstance they choose to simulate. No new gauges are needed. This is not a problem crying out for a gauge based solution. It is just an enhanced simulation opportunity awaiting realistic input. It is not the job of FDE authors or gauge authors to prevent end users making unrealistic inputs. We just decide the severity of the consequence (YS-11 versus DC-6A/:(. After all if your goal were to prevent use of the higher limit when 'not approved' all you have to do is make two different FDE each with the appropriate MAP and rpm limit.I understand fully that you wish to combine them so that it is easier for the end user to evaluate the relative capabilities with minimum hassle, but it will always be up to them to conduct that comparative simulation. The crew member appointed is responsible for moving the relevant levers and monitoring the MAP and rpm gauges to create no more than the limit value in each circumstance. Giving them the opportunity to replicate that real world responsibility is simple and involves no compromises at all. The last thing I would want to do at this point in developing those FDE is pretend that a C-47 has a fly by wire computer which will protect them from error with 'a gauge based software override solution'. Good FDE decision for an A320, but bad decision for a C-47. Just in case there is any confusion there is slight further workload for the FDE author. He has already made 48/2700 produce 1,200 bhp when authoring the power curve for the 'first circumstance'. To also allow simulation of the second he must now make 52/2800 produce 1,350 bhp. If he only wants the power output to be correct this won't take more than a few minutes of iterative testing, beginning from straight line extrapolation of the existing air file curves, even if he knows nothing about engine dynamics equations, (but see below). <>I agree. I hope the explanations above make the context plainer. The FDE author cannot make realistic simulation possible solely by provision of 'a realistic flight model'. They must also declare the dynamic inputs required to create realistic dynamic output. The end user has no hope of guessing what they are. 'Gauge based software override solutions' should be reserved for fly by wire aircraft. Gauge code should enable functional realism, not impose it, and in particular should not be used to impose criteria which may deny enjoyment of the aircraft as a whole. Please do not confuse those concepts with the idea that it's OK to create flight dynamics that impose a faulty flight model.<<...the development of a good engine model in MSFS depends upon documentation that is often hard to come by. >>Indeed, but MSFS provides good feedback. If you insert a few real data points on a curve and then shape the curve so that the real world performance envelope is achieved during simulation you may be able to extract what should have been input as output and inform the end user of the inputs they must make to replicate the real world envelope. Of course no one can contemplate making an aircraft for first person flight simulation use without a wealth of information that will never emerge from 3 view drawings and photos. Output accuracy should take priority over input accuracy when compromises are required, for instance when replicating the inputs and matched outputs of an engine with two speed superchargers. The input error % that arises from using simulation derived output as user input need not be any greater. You always need to research some real world data points on each curve though.<>The flight models, (back to at least FS7), have all the code necessary to link rpm to MAP, (yes - including engines attached to c/s props). It is the (default?) flight dynamics you have studied that lack the appropriate code. This could get complicated so I will sum it up as follows.Suppose TBL508 = A and TBL 509 = B. There are a series of (equiscaled) values of A and B for which A divided by B = correct power (A/B=TRUE), but only one value of A and only one value of B which interpolate to the correct MAP/rpm dependence (A and B = TRUE). Think of it as a conceptual interpolation not literally as one divided by the other. Making A and B = TRUE is the trick. Several (sometimes many) hours of empirical curve shifting after you have achieved A/B = TRUE may be required to approximate A and B = TRUE. Text book equations may guide you to appropriate first approximations.The real problem is finding the prototypical dependency data, not getting the flight model to read it from the flight dynamics. The flight model always reads the input data for dependency. Unfortunately the input data is usually erroneous. The AI engine does not cope well with rpm collapse. It expects a simple power v throttle relationship. In some cases the dependency error is deliberate. Lots of FDE are compromised for compatibility with AI use but that has nothing to do with the flight models.>Milton, you are welcome. Thank you for the aircraft you have co-produced and distributed as freeware.>Moving to Airhead's post.I realised you would welcome a fully realistic solution. The problem is that it may not be easy to research let alone achieve. Consider therefore that FS9 will import (convert) CFS2/3 dynamics, but will make some omissions in translation and will usually make some errors. The immediate relevance of Mike Wagner's 'WEP switch' is that it will 'add back' the omitted power data at run time leaving you with engine and airscrew dynamics in FS9 not obviously worse than they were in CFS2/3. At that point if you do not consider the imported engine dynamics sufficiently realistic you can start by proof reading the code for mistakes and correcting them and / or experimenting by trial and error. Whether the aerodynamics will survive conversion is a bigger issue, but is not the subject of this thread. You are providing your own MDL etc.The same aircraft are created more than once, not just because there is repeat demand, but often because they are the ones which are easiest to research, or easiest to 'clone' from default or existing FDE. The P-47D has been an MS default aircraft (twice?). There may well be superior third party examples available. I have not checked but the first stage of project definition must be to examine what is already available. It follows that you won't need any special gauges, especially if you obtain Mike Wagner's FS8/9 WEP switch. WEP in the P-47D relies on water/ meth injection, TOGA may or may not, but the power limits for the other 99.5% of each flight do not, so you still need to inform end users (and yourself) what they are, and how to set them using default gauges, or those you choose to create even though you do not need to.I am sure you will be able to create a better MDL and VC than is available for FS9, but you may not need to create better FDE than are currently available, and the attempt may be a 'bridge too far' at the moment.So far as learning to write FDE I have the following generic advice.If a lecturer in dynamics who was a pilot asked me to teach them how to impose their knowledge on MSFS I am confident that I could teach them what they needed to know in a few hours. If a programmer who understood the air file structure, but not aviation or the laws of dynamics, asked a lecturer in dynamics and a pilot to teach them what they need to know from the real world dynamics text books, and aircraft operating manuals, I have no confidence that it could be achieved in less than several months of full time study. The much requested air file tutorial is not the problem. Once you understand how it works for real aircraft applying the knowledge using an air file editor is much the lesser problem.No one can expect to create realistic flight dynamics, for a particular aircraft, without understanding aircraft dynamics, engine dynamics and operation of the aircraft in question. Expect to spend a lot of money on books and a lot of time grappling with their content. For the same reason that no one learns to fly in a P-47D I would not recommend developing one as an FDE learning experience. What anyone who wants to progress with FDE writing needs to do is start by converting the simplest FDE files they can find into dynamics for another very similar and equally simple aircraft. Gradually build up to more demanding transpositions. You need to research all the data for the target aircraft of course, but that is a key part of the exercise. After a while working out what you need to impose on the next air file will take longer than writing and testing it after you know what you need to impose.In other words researching the data and creating the handling notes, from which the FDE are to be written, often takes longer than creating and testing the FDE.Which is where I came in.FSAviator

[Guest Douglas K]

>The flight models, (back to at least FS7), have all the code necessary to link rpm to MAP, (yes - including engines attached to c/s props). It is the (default?) flight dynamics you have studied that lack the appropriate code.:) I am a little dismayed that it could take you several or many hours to tailor the curves to accomplish the desired result. Judging by my past efforts at cracking the secrets of even one airfile table, much less two interrelated tables, I will have to weigh the benefits of linked rpm to manifold pressure against what will surely be a much longer time spent editing 508 & 509 before I see the results I want. >It follows that you won't need any special gauges, especially if you obtain Mike Wagner's FS8/9 WEP switch. WEP in the P-47D relies on water/ meth injection, TOGA may or may not, but the power limits for the other 99.5% of each flight do not, so you still need to inform end users (and yourself) what they are, and how to set them using default gauges, or those you choose to create even though you do not need to.

[Guest airhead]

Boy Howdy, this thread is gettin' good (he says whilst scraping the remains of his 'gray matter' from his keyboard and monitor). You gents sure know how to make a guy's head hurt. :( But I did ask the original question....didn't I....I'll attempt to cover portions of the responses in order of posting for the appearance of clarity (of which I have none).>I'll look at the MS F4U Corsair that Idid for FS2002 and update it a little, and if you want I'llE-mail the .air and .cfg files to you. Let me know if youwant them, but it will take some time to look them over andupdate them to my current state of the art.Yeah. I see Crimson Skies is on XBox now. Hmmmmm.....I cannot resist the occasional jibe about 'eye candy' ('Airhead' knows me well enough not to take offence):)But seriously, while I attempt to strive for the realism, as you well know FSAviator, I do like to make 'em pretty too (I did mention that my forte is more in the modeling and visuals, didn't I...). In regards to the realism, I see where you are coming from. As I certainly don't want to punish the end user with systems complicated enough to discourage enjoyment of the finished aircraft, there is something very attractive (at least to me personally) about the challenge of realistically managing a high performance aircraft and paying a price if I fail to do so correctly. Giving the end user a choice is likely the most diplomatic method of handling this as to not royally #### anyone off after taking the time to download my creation, and not being able to use it as they wish, at least to some extent. Point well taken...Something that I need a little clarification on here. Are you saying that instead of setting up the FDE with the published max RPM and MP to produce max horsepower for normal flight, to use the RPM and MP published to produce the horsepower rating for WEP as these values? If so, would the end user then control the application of WEP based on adjusting the engine controls to their maximum limits and less than 100% throw of these controls to attain true max std or 100% power? For example (and maybe not the best one), in the Decathlon project, on take off prop is set fully fine and throttle is pushed to the firewall, producing max takeoff power. But for the P-47 these same relative settings would produce the configuration for WEP based on how the FDE are written. I don't mean to trivialize or detract from the depth of ideas being presented here by you guys, I guess I'm just trying to get a grip on the basic idea of how to implement this. Again, bear in mind that I'm a noob when it comes to this stuff so please excuse me for over simplification.And now to add a little more fuel to the fire. While examining some documents and cockpit photos of P-47's, I noticed that to the left of the throttle is a lever for the supercharger. Was the supercharger engaged manually? This may sound like a dumb question, but you must understand my background. I grew up around cars, and spent most of my teenage years rebuilding and tweaking them. Grease monkey, gearhead, motorhead, call me what you will. In particular, I always had a love for streetrods and muscle cars. Some of these high performance vehicles use superchargers and/or turbos, none of which are engaged manually. That is unless you consider stomping on the gas pedal manual engagement. I guess I should say that they are not activated by a separate manual control. I suppose I just assumed that aircraft worked under a similar principle. I was wondering if you guys could shed a little light on my thick skull and enlighten me as to how this control was used. I'm not sure if it is possible to simulate this, or even if it would be necessary, but it would be nice to know anyway.>I am sure you will be able to create a better MDL and VC than is available for FS9, but you may not need to create better FDE than are currently availableIn other words researching the data and creating the handling notes, from which the FDE are to be written, often takes longer than creating and testing the FDEAt the risk of becoming pedantic:DPedantic, I think the last time I saw that one was on a vocabulary test in my high school English Comp class. That one's worth at least 75 cents if not a buck....ROFL

[Guest Douglas K]

>Sure, if you feel up to it and have the time. I'm always interested in learning more about this stuff (or attempting to), and you obviously have a leg up on me with FDE. If I'm not mistaken, didn't the F4U use some version of the P&W R-2800 Double Wasp, similar to that used in the P-47? If so I would guess this adds some extra value to examining them. Again only if you have the time, I know you said previously that you don't get much time to work on FS stuff as it is and I do not wish to inconvenience you. I do sincerely appreciate the offer.Though this being the case, Douglas, if you need any gauge assistance with one of your projects, I would be happy to help. Least I can do for your offering of the F4U files for reference.Something that I need a little clarification on here. Are you saying that instead of setting up the FDE with the published max RPM and MP to produce max horsepower for normal flight, to use the RPM and MP published to produce the horsepower rating for WEP as these values? If so, would the end user then control the application of WEP based on adjusting the engine controls to their maximum limits and less than 100% throw of these controls to attain true max std or 100% power?And now to add a little more fuel to the fire. While examining some documents and cockpit photos of P-47's, I noticed that to the left of the throttle is a lever for the supercharger. Was the supercharger engaged manually? This may sound like a dumb question, but you must understand my background. I grew up around cars, and spent most of my teenage years rebuilding and tweaking them. Grease monkey, gearhead, motorhead, call me what you will. In particular, I always had a love for streetrods and muscle cars. Some of these high performance vehicles use superchargers and/or turbos, none of which are engaged manually. That is unless you consider stomping on the gas pedal manual engagement. I guess I should say that they are not activated by a separate manual control. I suppose I just assumed that aircraft worked under a similar principle. I was wondering if you guys could shed a little light on my thick skull and enlighten me as to how this control was used. I'm not sure if it is possible to simulate this, or even if it would be necessary, but it would be nice to know anyway.

[Guest Douglas K]

airhead,I made a lucky find tonight while searching for a flight manual. Check out this site for a lot of good information on the P-47, and the GE turbosupercharger:http://rwebs.net/avhistory/opsman.htmAfter reading the GE document 'The Turbosupercharger and the Airplane Power Plant', it looks like the P-47 probably had a single speed mechanical internal supercharger augmented by the more powerful GE turbosupercharger, and was not a normally aspirated engine with a turbo as I stated in my earlier reply. This arrangement makes more sense from an operational standpoint, as a warplane without any supercharging at all would be next to useless. It would provide systems redundancy in the event the turbo failed or was damaged in battle, but above 10000 ft the single speed supercharger isn't very efficient, and performance really suffers. But a single speed blower is better than nothing at all, if the turbo is shot to pieces.It looks like the cockpit lever is the boost control, which explains the 'B' on the knob, and it is connected to the regulator (see fig. 9). According to GE, the boost control causes the regulator to position the wastegate and obtain the proper manifold pressure for cruise, normal or military power. See Section 12 'Turbosupercharger Regulation' for a complete explanation of the regulator and how it functions to control the wastegate and turbine speed.In Section 15 'Operation' GE recommends warmup with the boost control lever in the 'OFF' position to open the waste gate, and when the engine warmup (and I presume runup checks) are complete, they advise setting the propeller at the rpm specified for take-off, then opening the throttle wide and using the boost control to set the desired manifold pressure as quickly as possible. You then lock the boost control and close the throttle after the turbosupercharger has had sufficient time to reach the proper speed and the manifold pressure is stabilized. I have serious reservations about using this method on a tail dragger with 2000 hp, although it probably works just fine for a B-17 or B-24. With a Thunderbolt, you might find yourself with an unusual and undesirable view forward when it goes up on its nose. But there is a whole lotta airplane aft of the main gear, so maybe it's possible without nosing over.Read Section 15 for a complete description.This webpage on the same site:http://rwebs.net/avhistory/opsman/pursuit/section6.htmhas a checklist for the P-47. Item C in the Starting Engine section sets the

[Guest _FSAviator]

I would like to thank Douglas K for posting more detail about water/meth injection in turbocharged engines. It certainly increased my understanding of how it works in that particular system.A few clarifications (I hope) for the benefit of those who do not understand this as well as Douglas.<>The increase varied from mark to mark, but the point is well made. With regard to the thread as a whole it is important to remember that this is the norm and the P-47 is the exception. Most piston engined combat aircraft don't have turbocharged engines, some aircraft use other fluids to develop WEP, not all are anti detonants, (so are not ADI), and most engines with WEP use none at all. There is no conflict in a any of the posts here just the generic information for all piston engines versus specific information for one way it was done.The information provided in post 1 of this thread works for all reciprocating engines.<>Agreed for aircraft with ADI attempting to generate WEP without it, but that does not mean that generating WEP in a P-38 or P-51 involves more risk than generating WEP in a P-47. Mean time to failure is a (rating authority) constant. P-47 (using ADI) WEP limit is higher at identical risk.<>Douglas means low density = high altitude or high temperature. <>ADI in turbine engines is being discussed in the thread concerning xml gauges and catapult launching from aircraft carriers. The advice I have given in this thread does not work for many turbine engines, for reasons explained in the other thread. That is why I don't want to discuss turboprops in this thread. In the other thread we are close to resolving, by other means, the turboprop case which Douglas K describes. ADI is normally used in turboprops as explained by Douglas but not all turboprops use it that way.<>This is a critical issue which I think many users of MSFS still miss. Both the power generated, and whether there is any flow of injectant, depends on the position and management of throttle (and/or rpm) levers and not just the flicking of a 'WEP switch'. The injectant does not flow and exhaust on the basis of the ADI switch position (usually misdescribed as a 'WEP' switch in gauge names).I will take this up with Doug Dawson (see other thread) in relation to turboprop module content.In so far as that paragraph also relates to piston engines the result is that the advice in post 1 of this thread leads only to the loss of a time limit after which the injectant is exhausted. I believe Mike Wagner's WEP switch is an on/off switch for ADI flow and not an on/off switch for the throttle microswitches. With his permission the code could be altered to sense throttle % and rpm % as well as ADI switch status. Note however that Mike Wagner's switch only interfaces with the FS8/9 piston engine flight models. Hence the need for the turboprop module being discussed in the other thread.Moving to Airhead's post.<< You gents sure know how to make a guy's head hurt. But I did ask the original question....didn't I....>>Sorry, I tend to have that effect, but remember my first post is complicated because it covers every case. My point was that you don't need to do anything special with the FDE, or produce any special gauges. The possible limitations of the existing 'WEP switch' are addressed above. I don't think you need to know how the real engine delivers the output. You just need to enable the output and tell the end user what lever positions create it. If you try to make FS9 do it the way the real engine does it, instead of making FS9 just do it, you are climbing a mountain you do not need to climb. Douglas' explanation of how it works in the real thing is excellent, but for FS9 product development there may be easier ways of getting the same end result.I am trying to point everyone to the simpler solution, even though I am enjoying learning more about the detail.<Yes.The air file curves have to go (at least) as far as whatever maximum you decide is going to be the maximum in your product. WEP is just one choice from many possibilities.<< If so, would the end user then control the application of WEP based on adjusting the engine controls to their maximum limits and less than 100% throw of these controls to attain true max std or 100% power? >>Yes. See my reply to Douglas concerning the DC-3 cases for more detail. Note potential application of Mike Wagner's 'WEP switch' and potential for further modification.<<..in the Decathlon ..on take off prop is set fully fine and throttle is pushed to the firewall, producing takeoff power. But for the P-47 these same relative settings would produce the configuration for WEP based on how the FDE are written. >>Based on reality as well. In most aircraft which have WEP, WEP > TOGA so the levers must be advanced through the TOGA gate to achieve WEP. See Douglas' description of the relationship of the ADI switch to the microswitches (in the gate). <>There is no supercharger in a P-47D. In his final posts Douglas is also slowly getting confused by too much new information. Many US built aircraft had no supercharger. Most are not generally considered to have been useless, (though the British were never exactly keen on them). American usage of the terms supercharger, turbosupercharger and turbocharger, even in official documents, lacks clarity and is sometimes plain wrong. See extensive replies from Douglas K for more detail on turbochargers.<< I guess I have chosen this aircraft.......based solely on the fact that I have an interest in the aircraft......Maybe this is a less than valid reason for selecting the aircraft, but that's usually how the process works for me. In a way, the projects choose me, not the other way around. Is that odd?>>Not odd, just a mountain to climb if you cannot find collaborators with the right specialisations who are also interested in that aircraft. Most potential collaborators on such aircraft projects are more interested in CFS3 than FS9. That gives you a problem that you need to take into account when selecting a project. I am not available for this project for other reasons which I explained elsewhere.A few final thoughts specific to P-47 development.The specific information is certainly nice to know, but may be very difficult to replicate in FS9 anyway. To replicate the system in the P-47D in more detail than is possible via the generic route described in post 1 you will need to develop both specific gauges and specific FSUIPC modules. Even then I don't think there is any certainty that the specifics can be imposed on FS9. Best of luck if you decide to attempt to replicate the inner workings of one type of engine rather than just delivering its output in real time as the end user moves the throttle and rpm lever with the ADI enabled. It's up to you whether you fail engines and stop people enjoying your aircraft if they do not operate them realistically. You know my advice. Warning lights are a good idea.See also the last paragraph of my first post. You may be in danger of spending many hours replicating the power curve and still not be able to replicate the thrust curve. Other than as an academic exercise there is no point in making the power curve more accurate than the airscrew efficiency curve. Take this into account when deciding exactly which version of the P-47 you are going to produce. At that point you have written just four air file sections. Returning quickly to the later posts from Douglas, but not the P-47. Thanks for taking the time to explain turbochargers in detail.<>The answer is simple. 1% will and 99% won't. It is not a producer problem. All we should do is tell end users how to operate the aircraft realistically. If we see a few more uploads with the data needed by the 1% who would like the opportunity to simulate the realistic operation of the aircraft, that will be a big plus. <>In very many piston engined aircraft it depended on the fuel octane loaded on a day by day basis. Don't think US internal, think international. High octane fuel availability was not a given on every commercial airfield, (or in every theatre, or every island, of every war). This reality can all be simulated, but < 1% will bother. The rest lose the variety and the challenges that go with the reality but can still enjoy the aircraft in their own limited way. FSAviator

[Guest Douglas K]

>Douglas means low density = high altitude or high temperature.

[Guest _FSAviator]

[Guest Ron Freimuth]

"<>" Do you know why magnetoes are stamped with "D" or "G" to indicate rotation direction? Bet there aren't many around who know the answer. ;) Ron

[Guest _FSAviator]

I regret that there were some material inaccuracies concerning the development and deployment of the P-38 in my post which was number 12 of this thread. I should have checked my memory of the situation against the relevant references, or not have commented on those issues at all. I am about to ask the moderator to remove it.Briefly the actual situation was that the British Purchasing Commission ordered 143 x Lightning I analogous to the P-38E, but with superchargers and without handed engines, for low level roles and 524 x Lightning II with turbochargers which were analogous to the P-38F for high level roles. Ordered at the same time in May 1940, by the time any Lightnings were actually available the Beaufighter and Mosquito were already replacing the Blenheim successfully in all roles and at all levels. The terms of the original contracts were not met, but the exact nature of the breaches is less clear than I originally thought.Here is a summary of the relevant information from the removed post.Superchargers are superior for some applications and turbochargers are superior for others. Some aircraft were fitted with both a turbocharger and an auxiliary supercharger but I am as certain as I can be that the P-47D did not have an auxiliary supercharger. In my opinion that was the norm since the weight and expense of dual provision made it an unusual choice.All turbocharged aircraft are high altitude aircraft since turbochargers are inefficient at low altitude. If an auxiliary supercharger is added it is to provide adequate performance at lower altitudes where the turbocharger is least efficient. It all comes down to the original question. How do I enable and use the various power limits of a piston engined aircraft in FS9. This still comes down to using the throttle and rpm controls within FS9 to set the limit MAP and rpm values stated in the handling notes. For MSFS product development the internal details of the power train may be interesting, but are otherwise completely irrelevant. You do not need any data you cannot impose, or do not have the intention to impose, on TBL 508 and TBL 509. There are no other relevant curves available to you for use in FS9. The data you need for this R-2800 engined FS9 project is limited to the data you need to vary the numbers in the R-2800-CB17 (FS9) handling notes I provided as a template in post one of this thread.Finally Ron, the British also took over the French order for P-38s in June 1940, (after France fell). They had specified handed engines so I expect some parts of (some) handed engines were stamped D for Droit and G for Gauche during manufacture. However I intend to stick to talking about MSFS in any future posts as checking what I think I know about the details and history of real aircraft against the appropriate references is too time consuming and probably off topic anyway.FSAviator