Even with collective fully down (governor on) descent rate is 1000-1500 ft/min, max 2000. It should be around 3000 ft/min or more. When pulling collective the descent is easily stopped and the helicopter floats.

I have looked at blade and engine parameters but not found any solution. I have observed same behaviour with other helicopter models too.

Any ideas what could be the issue?

Best regards,

Andreas

So, to start off with, we need some software. I assume you already have Plane Maker and Airfoil maker installed here.

The first thing you need to do is install LabView 7.0, a free piece of software,found here (as of 10/3/2015):

http://www.ni.com/download/labview-run-time-engine-7.0/750/en/

You need to create an account to download the .exe, but I have yet to receive any communication for LabView whatsoever, so it's a rather pointless exercise.

Once you have that installed, you want to head to the downloads section, and install FoilTrans. Again, free piece of software, made by a member of the community:
http://forums.x-plane.org/index.php?app=downloads&showfile=7896

You may need to restart your computer after installing those two.

Before we can install the airfoil, we need to know 2 things (ideally):

- What airfoil do we want / is it suited for our model?

- What Reynolds number is our plane flying at?

The Reynolds number is useful - the closer you get to your actual plane's number, the more realistic the aerodynamics should be. Plenty of guides on the internet to calculate it.

Now let's choose an airfoil. I'm hopping over to www.airfoiltools.com , a fantastic site with loads of airfoils on their database. For this exercise, we will be installing the NACA RC(4)-10 airfoil. This is what the airfoil's page looks like:
[attachment=189606:RC4 screencap.JPG]

As you can see, we have a selection of Reynolds numbers to choose from. The NCrit value is to do with how likely the flow is to go from laminar turbulent. Default is about 9 here. Let us also pick a value of Re of 1,000,000. Clicking "update plot" gives:
[attachment=189607:RC4 prediction.JPG]

Keep a hold of those polar plots, we will return to them.

As you can see, I have drawn a red circle around the "details" box on the line we are interested in. Click this, or preferably, open it in a new tab. You get the following:
[attachment=189608:RC4 polars.JPG]

Again, I've circled the important link - the .txt file. Click this, and save it somewhere accessible.

Now we open up FoilTrans. We go into the File menu, select Load Foil Data, and select "X-Foil linear interpolation" (NOTE: probably only works with X-Foil generated polars, but not tested yet.)

[attachment=189609:FoilTrans1.jpg]

Click this, and navigate to your polar .txt file. When you open it, you should get something like this:
[attachment=189610:In FoilTrans.JPG]

From Airfoil Tools, we get our thickness, and correct the "Thickness" and "Reynolds Number" tables.

To keep X-Plane happy, go into "Modify", and select "Extend Foil Data", as so:
[attachment=189611:Extendede.png]

Finally, go back into "File", and click "Save Modded Airfoil". Then navigate to X-Plane's Airfoils folder, and save:
[attachment=189612:Saving.JPG]

Close FoilTrans. Open Airfoil Maker, and select your airfoil (File, Open, Airfoils folder, 'Open').

Compare the Airfoil Maker plots to those on the Airfoil Tools site:
[attachment=189613:Compared.png]

Looks good! You can now close Airfoil Maker, use this airfoil on your wing in Airplane Maker.

Good luck, and please be sure to update this as links, etc change

~ Merlyne

An engine's base health can be defined in Plane Maker, but also set with DataRefTool at real time using "sim/aircraft2/engine/engine_health". I'm playing with it at the moment and it seems that it's simply a scalar on:

• power

• RPM, N1, N2

• torque (or prop parameters, influencing torque)

• fuel and oil pressure

Value range is zero to one. At zero, the engine is essentially unusable, but not marked as failed in the failure datarefs.

However, as of 12.3.0r3, setting engine health to zero is absolutely not recommended because of a bug ( @philipp !), which gets some engine related parameters like fuel flow or ITT stuck at "NaN" or "inf", instead of hard capping them at zero or ambient temperature. Using "fix all failures" is not possible here, as the engine is not marked as failed and resetting health to a higher value has no effect. Since some FF and temperature related datarefs are interlocked, using DataRefTool to "reset" one of their values is also not possible and the only way out is reloading the aircraft.

That aside, the feature offers a bit of potential, as you can essentially fly a different engine every session by means of a simple (x)lua or Python script that picks a random value between, say, 0.95* and 1.0 for each member of "sim/aircraft2/engine/engine_health". Or implement a simple, persistent "engine wear and tear" system. Possibilities...

*Could be too little, but I have no idea how much installed engine performence varies in the real world.

I am integrating my plane into PM. Currently modeling the prop's shape, but I cannot figure how to line up PM's propeller to my 3d model. The leading edge lines up without any issue when working with the L. E. offset parameters in Engine specs/Props 2, but the trailing edge settings seems to be of no help.

Here is what it currently looks like:

As you can see, the trailing edge does not line up. When I play with the T. E. offset parameter, it also moves the leading edge. If I then tweak the L. E. offset for the leading edge to go back in place, the trailing edge will go back in its initial place, hence not shaping up to what it's supposed to look like.

Any idea of what I'm doing wrong?

Thanks!

I have been getting back into flying sim lately after a break. I'm running across the same issue on multiple aircraft lately and it's been annoyingly frustrating.

It seems that X Plane 12 changed the global flight model, and maybe Plane Maker, drastically from X plane 11. My understanding is that it models propwash, fuselage side area loading, and loading of the vertical stabilizer differently.

The trend seems to be that a lot of payware are poorly done ports of XP11 models, where the dev did not retune the flight model from scratch. I have run into multiple aircraft that are so messed up with rigging and yaw that they are unflyable to me. Usually required tons of left rudder input in cruise flight, and little or no right rudder on takeoff. This usually causes a constant roll input to be required to maintain wings level as well. It's just baffling to me that there are so many aircraft out there being sold for money, that all have this issue, and I don't see people complaining about it.

The default 172 flies exactly like it should, so it's obvious that dev's are just either lazy and slap a "Compatible with X plane 12" logo on their product and sell it for a money grab, or they just genuinely aren't pilots and don't understand how messed up their model actually flies.

I'm left in a position where I want to learn Plane Maker well enough to take a crack at fixing these aircraft so they are usable, but then again I built my sim to fly, not to become a developer. I can't be the only one here who has noticed this trend? Anyone?

This is my first time ever using Plane Maker and making changes to OBJ attributes, so please excuse my novice-ness. I added an object to the cockpit of my plane but I need it to be completely free from cast shadows and cannot have the object reflecting its color on the rest of the plane. I'm trying to use the shape as a chroma key mask for a VR/mixed reality setup, so I need the color to be completely consistent on the object and can't have other things reflecting the same color.

I've attached the phenomena that I'm talking about and also the OBJ in Notepad++, I've tried so many things from changing emission attributes, the object lighting settings in plane maker, and I just can't find any solutions to this. Any help is appreciated!

• Edit 01/11/25: I've produced an OpendDocument spreadsheet to assemble airfoil file data from Javafoil outputs: https://forums.x-plane.org/forums/topic/338017-javafoil-to-afl-file/#findComment-2964326

Where I'm at:

The cross-section of the airfoils in question is only reprinted in a PDF document and not available any ready to use format (i.e. list of points or on Airfoiltools) whatsoever, so I had to start from the ground. In summary: I've loaded the page of the PDF into GIMP, traced the airfoil shape with a path, then copied that path into a blank image and scaled it up a bit for better resolution, then let GIMP trace (stroke) the path to recreate the airfoil shape in higher resolution, then exported the image in PNG format and opened this image in Javafoil, which generated a list of points from the outline. I set the proper name for the airfoil, corrected the thickness-chord ratio to the book value and saved the points list so I won't have to do the GIMP dance again. In Javafoil, analyzing the airfoil's polar and velocity ratios yields (what I deem) sensible results, so the importing process appears to have worked well.

AFL file shopping list, with questions:

From what I can gather from looking at an AFL file in a text editor and looking at Airfoil Maker, I need:

1. Three header lines.
   I'll just copy and paste these from an existing airfoil.

2. The thickness-chord ratio.
   Check. This is stated in the document the shape is printed in. Javafoil also estimated this with resonable accuracy.

3. The critical mach number.

   If you run a velocity analysis in Javafoil, say between -20° and 20° angle of attack, is this the highest value that can be found in the "M cr" (critcal mach) column of the results table?

4. 14 pairs of points.

   This should be for the visual representation of the airfoil in PlaneMaker. To obtain this list without having to fiddle in Airfoil Maker, I take it that I can just reduce the number of geometry points in Javafoil to 14, save the resulting file and then copy and paste it into the AFL file?

   • Edit: I found a way to convert the shape. See here: https://forums.x-plane.org/forums/topic/338017-javafoil-to-afl-file/#findComment-2961747

5. A mysterious "1".
   Seems to be a placeholder, as all AFL files have it.

   • Edit: This states the amount of "alpha, C_l, C_d and C_m" tables (each specific to a Reynolds number) that follow. See @Voidhawk9 's reply here: https://forums.x-plane.org/forums/topic/338017-javafoil-to-afl-file/#findComment-2961746

6. A whole line of values.
   These represent the values of the settings from the "AoA-20" and "AoA-180" tabs in Airfoil Maker. Are these just for display or actually relevant for X-Plane?
   If they are indeed relevant, can these values be obtained from Javafoil?

   • Edit: These values are specific to a Reynolds number (first value in the line) and determine the shape of the AoA polar for this particular Reynolds Number in Airfoil Maker. These values should match what results in the "alpha, C_l, C_d and C_m" table data following the 721 lines below. If the "alpha, C_l, C_d and C_m" table does not match the parameters, these parameters will generate a new table when the custom airfoil is opened and saved in Airfoil Maker, so exercise due caution if you leave this line unchanged!
     For an "organic" solution it might be better to try and redraw the polar shape generated by Javafoil (and XFLR5, I guess) in Airfoil Maker with the parameters and let it generate the table.

7. 721 rows of "alpha, C_l, C_d and C_m" value pairs.

   From -180° to -20° and 20° to 180°, alpha increments by 1° per step, between -19.9° and 19.9° by 0.1° per step. This data can be obtained from the polar analysis in Javafoil and likely copy and pasted into a spreadsheet to pick the rows and columns that are relevant for the AFL file.

   However, generating the polar requires a Reynolds number and I am unsure what I should set there. As this is a rotor/prop blade maybe around 4,500,000 (as on the default NACA 16)?
   Or should I simply generate polars for Re numbers of, say 100,000 and 5,000,000 (or values calculated with this - using expected velocity range and chord as inputs) and let XP handle everything in between?

   • Edit: According to @Voidhawk9 and as stated by Austin, relevant Reynolds numbers can be obtained from a flight model cycle dump in X-Plane, ideally at close to stalling and maximum speed, with a few other speeds in between.

Since it displays a percentage instead of absolute torque, I assumed the values are calculated by X-Plane like this:

(sim/flightmodel/engine/ENGN_driv_TRQ[0/1...] / sim/aircraft/controls/acf_trq_max_eng) * 100

But if I calculate torque like that in an xlua script, I end up with a delta between the result and what's displayed in the data output of around 9% and I have no idea why.

My little script to test the override datarefs can be seen below:

-- load datarefs
FC_override	=	find_dataref("sim/operation/override/override_flightcontrol")
FC_yoke_pitch_ratio = find_dataref("sim/cockpit2/controls/total_pitch_ratio")
Zulu_time_Sec = find_dataref("sim/cockpit2/clock_timer/zulu_time_seconds")


function flight_start()
	FC_override = 1.0
end


function before_physics()
		FC_yoke_pitch_ratio = (Zulu_time_Sec/30) -1
end

Unfortunately, it seems, that the modification of the pitch control only applies to the pilot side. When I run this script, the left half of the elevator moves according to the script, whereas the right side is standing still.
Does anyone know if there is a way to apply this to both sides?
Thanks in advance

I have a basic plane maker model and would like to edit it in blender using acf mesh tools. I can't seem to find any instructions on how to use it. I only know that it is a terminal command and you need to use command prompt to make it work but I do not know what command to use. 

Thanks!

My understanding of Plane Maker (version 12.2) is that users are currently limited in the way how they can define the engine and rotor locations for helicopters. The rotor position is linked to an engine position with limited possibilities to define an offset between rotor and engine. This limitation seems to impose a specific modeling approach that impacts the accuracy of the aircraft's inertia estimation.

A way to improve this would be to introduce an additional parameter for each propeller (or rotor). This new parameter would introduce a third-axis offset for the thrust point, which would allow a more precise representation of the engine (mass) distribution and, consequently, a more accurate calculation of the helicopter's inertia.

Or maybe I am just lost in all the options to move and rotate interdependent items (rotor and prop). Let me know!

Details:

How to properly model helicopters with two or more engines with X-Plane/Plane Maker (PM)?

Below I explain the current setup, then show the impact of relocating the engine (1.) and then point out the limitation I see (2.).

Current Setup
I do not see a way to define the engine location completely independently from the tail rotor/main rotor location, see the PM-screenshots for the "Props" (no way to modify location/orientation of the props/rotors):

It is indeed possible to define an offset for 2 axes ("thrust-point offset"), but the 3rd axis is missing on the "Engine Specs->Locations" tab.
As a consequence of this deficiency helicopter modelers place the first engine under the rotor hub, the second one is placed at the tail rotor position (this my assumption, there may be other reasons to apply this approach!), see here:

Both engines are linked via a common transmission and a defined gear ratio so the power distribution should be OK. I had a look at the standard X-Plane Sikorsky S-76 but also several other multi engine helicopters in the download section (XFER H145, UH60M, AS365, AH-1Z, CH-53E) are using this modeling approach for engine placement. The data below refers to the S-76 if not otherwise stated.

Now for the moments of inertia:

X-plane offers to automatically calculate the moments of inertia (radii of gyration) based on all the parameters provided in PM. This is (besides other data) based on the mass of the engines and the position of the engines. The engine mass seems to be extrapolated based on the total aircraft mass.

What is important:

Looking at the Cycle Dump.txt (with a lot of assumptions on my side!):
PM estimates the mass of both engines identically with 174 kg each, which makes sense as both provide the same power ("Engine # 0 is mass 174.724 kg..."). Now X-Plane calculates some lever arms (I assume the engine's center of gravity related to the current aircraft center of gravity to use the Steiner's theorem to calculate the resulting moments if inertia for the engines).

Acc. to the CycleDump.txt X-Plane now calculates the distance of the engines to the center of gravity:
Engine # 0 is mass 174.724 kg at x= 0.00, y= 1.43, z= -0.37 (for moment of inertia build-up)
Engine # 1 is mass 174.724 kg at x= -0.46, y= 1.58, z= 7.77 (for moment of inertia build-up)
(Selection of coordinate systems seems different to PM as x seems now to point to the right, y is pointing upwards and z is pointing to the tail of the helicopter, seen from behind of the aircraft).

As expected and as defined in PM the second engine is located far aft. Based on Steiner's theorem this will lead to an increased moment of inertia in the pitch and yaw axis of the helicopter.
I know there is also a tail rotor gear box, but this is not weighing 175 kg...

Sum of all engines have mass of 349.45 kg ( 10% of total):
The radius of gyration of the engines in roll is 1.54 m, based on all engine masses and locations.
The radius of gyration of the engines in pitch is 5.71 m, based on all engine masses and locations.
The radius of gyration of the engines in yaw is 5.51 m, based on all engine masses and locations.

Final combined results for the helicopter:
The radius of gyration in roll is 1.04 m. (that's moment of inertia 3739.568 kg*m*m).
The radius of gyration in pitch is 3.21 m. (that's moment of inertia 35336.504 kg*m*m).
The radius of gyration in yaw is 3.12 m. (that's moment of inertia 33447.984 kg*m*m).

Take this data as the baseline.

Now I tried to define a "more realistic" engine placement, but I did not figure out how to do it properly.
Either this is a limitation of PM or I do not see/understand the required parameters to model it.

1. Step: Move the 2nd engine to the location of the 1st engine.

This is also not the real position, but it will demonstrate the effect of relocating the engine to the moment of inertia (as expected, which is good).
I know this will also move the tail rotor (linked to the 2nd engine position), so the H/C does not fly anymore.

But this configuration will show the impact on the calculated inertia. The resulting figures are as follows:

Engine # 0 is mass 174.724 kg at x= 0.00, y= 1.43, z= -0.37 (for moment of inertia build-up)
Engine # 1 is mass 174.724 kg at x= 0.00, y= 1.43, z= -0.37 (for moment of inertia build-up)

Sum of all engines have mass of 349.45 kg ( 10% of total):
The radius of gyration of the engines in roll is 1.43 m, based on all engine masses and locations.
The radius of gyration of the engines in pitch is 1.48 m, based on all engine masses and locations.
The radius of gyration of the engines in yaw is 0.37 m, based on all engine masses and locations.

Final combined results:
The radius of gyration in roll is 1.03 m. (that's moment of inertia 3610.077 kg*m*m).
The radius of gyration in pitch is 2.62 m. (that's moment of inertia 23600.330 kg*m*m).
The radius of gyration in yaw is 2.52 m. (that's moment of inertia 21762.467 kg*m*m).

Consequence of the modification (as expected):
Moment of inertia in pitch and yaw are reduced by ~33% compared to the original definition.
So there should be an improved estimation of the inertia with a "correct" engine location modeling.

2nd step: Place the engines at the "real" locations and correct the locations of the props (rotors) relative to the engines

I moved the engines slightly behind the rotor head and placed them with a reasonable offset to the left/right:

Now you see the main/tail rotors are not in the correct position anymore (they have moved with the engines)
To correct this the rotors have to be moved.
But the thrust point only allows a movement in 2 axis, for the main rotor a longitudinal and an vertical movement is possible (due to the orientation of the engine itself). You cannot correct the third axis:

Similar situation for the tail rotor:

You can modify the lateral and vertical position, but not the longitudinal position.

Questions:
Do you share my observation? Is there a better way to model such a setup (H/C with more than one engine)?
Please tell me if there is an easy fix for this. Maybe I am lost in all the options to move and rotate interdependent items (rotor and prop).

Who cares? 🙂
I agree, most of the estimations PM is performing are quite reasonable. And there is not much public inertia data for helicopters available to compare with or to use this data to override the automatic calculation of the radii of gyration in PM. But the higher inertia calculated with the current implementation will impact the way how you tune your manual /automatic controls and the thrust to match real live dynamics. So starting with more appropriate inertia data would lead to an overall more realistic setup.

The alternative is to set up a mass model of the components and to calculate the radii of gyration on your own. Not every user can do this and depending on the quality of the data the result will not be more precise than the calculation X-Plane will perform.

Thanks for reading!

Apologies if this has been answered somewhere else - I did spend some time searching, but no luck.

Ok, so for airplanes that use a pusher propeller, does the aerodynamic model from flow around the fuselage affect the flow coming into the propeller? I have seen some info that makes me think the blockage is modeled for tractor propellers, but a definitive answer would be helpful. In particular, I have a design where I expect the fuselage to slow down the flow coming into the propeller, but when I look at the propeller efficiency, it gives a value that makes me think the inflow is not being slowed at all by the fuselage. Given what I know about the blade element method x-plane apparently uses, versus what an inviscid panel method model of a fuselage would do, I am led to believe x-plane will not slow down the flow coming into the propeller because of the plain fuselage geometry.

Does anyone know the answer to this? I doubt this will matter, but I have x-plane 11 on Windows 11

Thank you, 

AeroMonkeyDork

After a long an arduous journey mainly looking at how others have created aircraft, I decided to try add some additional features to an existing aircraft with some success. However, I completely stumped on how Turbo Props/Free Turbines shutdown without over cooking the engines.

In short, I can fire up the engine using the starter and igniters, as NG approaches 60% with a combination of the starter and increased throttle, the engine becomes self-sustaining well within the Max EGT of 750 degrees C. My governor kicks in and the engine sits within the Low and High ranges I've set. All good. I've also adjusted the hi-lo fuel idles.

Now the bit I just can't work out. As I wind down the throttle, even if I leave the NG at 60% for five minutes, as I close the throttle, the temperature races to 900 degrees C

How do you model/simulate the shutdown, without cooking the engine?

Any guidance/feedback/suggestions would be very welcome.

Thank you in advance.

To simulate the static thrust test, I added weight to the vehicle so that the motors would not move and removed all wind components from the scenery.

The output from X-Plane is consistently offset from the actual output of the motors in real life, at all throttle levels, can anyone help me understand? If any further info could be of use, please tell me.

I have a question about the flight model in X-Plane

I am only a "user" of planes and Plane Maker is used for minor corrections
based on the knowledge of other people from the forum (add hook, engine power, etc.)

But what I mean is the flight model

With subsequent releases of X-Plane it is often stated:
 
"A new flight model has been implemented"

Everyone seems to know what a flight model is and it seemed that way to me until now

Once I read:
"flight models based on real aircraft performance data"

That is, data and values entered into Plane Maker in various tabs
These are constant data of a given model and that is clear

Recently I found improved flying models from X-Aerodynamics
Apart from tuning the parameters, they also focused on improving the solid model from Plane Maker

And now I'm having trouble understanding what exactly it is
"Implementing a new flight model"

Are these minor changes added that
allow you to add additional values to even more faithfully reflect real flight behavior
And the flight mole (the basic one) is the same and older planes will fly correctly

Are these significant changes (such as weight and load changes in XP12)
that some of the planes taking off will no longer fly properly

I'm asking because in X-Plane 12.00 I often hear about changing the flight model

and whether it makes sense to buy the add-on:

C-172S, C-172R, C-172M/N Ulepszone modele lotne-xaero-c172 (x-plane.org)

Where the changes are dated: new version for X-Plane 12 (May 2, 2023)

or whether it is worth buying a plane where the developer does not appear on the forum but has introduced changes
for XP12
---------------
X-Plane 12 version now available:

Release (February 7, 2023)

Version 12 (May 23, 2023)

Because if the plane has one
XP12 versions, one assumes that it works correctly
But with significant changes in the flight model, it may be different and not every developer updates them

Regards

100 point coordinates:65A012 coordinates.txt

200 point coordinates:65A012_200.txt

(Had to be posted as .txt)

I would appreciate any possible help, thanks!

@XPJavelin 

I'm a volunteer for the A.V. Roe Museum located in Springbank, Alberta. We are in the process of constructing a 60% scale, flying piloted version of the Avro Arrow.

We have a simulator system that we use for testing the basic aircraft design, and also as an attraction during open houses. We recently upgraded all the hardware, and it now runs both X-Plane 11 and 12.

We've built our aircraft for X-Plane 11 long ago, before I was involved in the museum. It's great fun to fly, like an F-16 sans afterburner.

We imported the same aircraft into X-Plane 12 and it flies like a tank. It takes longer to get off the ground then loses control authority as speed increases until it becomes a ballistic missile.

We have been aching over this for months now and cannot figure it out. I just tonight manually re-built the XP12 aircraft by hand-importing every value from Plane Maker 11 to Plane Maker 12 except for the textures at the moment. Both aircraft are attached here.

Even examining Element Forces gives no clear answer. The only lead we have is that somehow XP12 is calculating our CG as way off whack as displayed in "% MAC", people at the Museum smarter than I am as far as design engineering say this puts the aircraft's CG somewhere between the pilot and passenger, rather than just ahead of the horizontal stab, where it should be.

I'm no expert at this and am at my wit's end trying to get this plane flying in X-Plane 12 so we can continue on normally.

Thanks in advance for any help.

Arrow II Rebuild XP11.7z Arrow II Rebuild XP12.7z

has anybody (successfully) created an VTOL Jet in XP12 already?
I am currently trying to model a Dornier Do31 (world's only VTOL Transport Jet), however I have huge difficulties, as I believe the VTOL section in PM is not optimized for jet engines, especially in the configuration of the Do 31:
2 pusher with thrust vectoring 0-100° and 4 smaller lift jet engines on each wing tip, as well as one bleed air exhaust at the rear of the plane for pitch stability.
Any help is appreciated, the current model is attached. (very rough and PM only, but with very basic 3d cockpit (cube))
Worst case would be developing a complete flight control software in lua or similar.

Thanks in advance

Do31.zip

I am currently developing an Aircraft with 10 engines and would like to use commands/datarefs to start or shut down the engine in flight.

As far as I have seen, there are only commands running from engine 1 to 8 (as in XP11), however I need the other ones as well.

Does anybody know some trick or workaround here to use the full potential of XP12 ?

Thanks and BR

The most important realization here is that your critical altitude in PlaneMaker is your baseline. All engine parameters must be tuned to this altitude.

For a R-985-SB, with its 5,000 ft critical altitude ("Engine Specs" --> "Engines"), this means using 400 (not 450) hp in "Engine Specs --> Locations". Greenline and redline RPM in in "Engine Specs --> Locations" can be per certificate, i.e. 2,200 and 2,300 RPM.

Accurate manifold pressure values are near impossible to achieve, as it's either spot-on at crit. alt. and too low at sea level or spot-on at sea level and too high at crit. alt. Probably an X-Plane limitation.

For the example engine, in "Systems" --> "Limits 1", I've entered 33.0" manifold pressure as the maximum and 36.5" manifold pressure as redline. This makes MP a bit too high at altitude and a bit too low at takeoff, but the deviance is at least less than when tuned for either of the two setpoints.

With the values above, in ISA conditons (+15°C, 1013 mBar/29.92 inHg, no wind), I get 450 hp at 2300 RPM and 36.0" MP and 98.6% throttle at SL when on a takeoff run and 400 hp at 2,200" and 33.7" MP and 100% throttle at 5,000 ft.

Now note how rated takeoff power was achieved at less than 100% throttle. Don't try to be clever and limit available throttle in PlaneMaker now as the parameter also applies to the engine output at critical altitude. While setting "max. throttle" in "Engine Specs" --> "Engines" to 0.98 or 0.99 may yield 450 hp with maximum throttle input on takeoff at sea level, at your critical altitude, you will fall short of the rated 400 hp because said throttle input is rigged to always only produce 98 to 99% of it. Instead, it should be realized that while the engine can be operated at more than the rated takeoff power that is stated in the type certificate, the rating itself is to be interpreted as a "safe power output for a given period of time" and not as "maximum physically possible power output". This is a point that should be kept in mind when anybody complains about too much power output on takeoff with a supercharged piston engine. Normally, exceeding rated takeoff power for a period of time should end in severe engine damage, but since X-Plane does not model this by default, education about proper techniques is all there is.