NOALB

That cant is definitely what I'm most curious about as far as flight characteristics are concerned. Like, can I expect that the drift angle indicator will read 0° throughout most of the speed range past full translational lift, or only within a narrow band good for attack runs? Likewise, how much is it affected by crosswinds and density altitude? Do the stub wings and balancing characteristics increase flight efficiency and allow lower fuel consumption or less collective pitch in forward flight? Will control inputs at hover differ less from neutral compared to the Mi-8 due to the airframe itself aerodynamically compensating more for unbalanced forces? Do you have any good sources where I can read about that particular aspect myself? :D

Although DCS doesn't make it particularly easy, it's definitely possible to use S-5 rockets (from the MiG-21 module I believe?). Easiest way to do it is as follows: -Use the mission editor to add a new loadout to the Mi-8, filling all 6 hardpoints/stations—doesn't matter with what; just add anything—then name it something easy to search for, like "UB-32_LOADOUT" or something -In your DCS Saved Games folder, open the following file for editing: MissionEditor\UnitPayloads\Mi-8MT.lua -Search for the loadout you just created and replace all ["CLSID"] = "WHATEVER",lines with ["CLSID"] = "{UB-16_S5M}", or ["CLSID"] = "{UB-32_S5M}", It should look something like this when finished: [50] = { ["name"] = "UB-32/UB-16+", ["pylons"] = { [1] = { ["CLSID"] = "{UB-16_S5M}", ["num"] = 6, }, [2] = { ["CLSID"] = "{UB-16_S5M}", ["num"] = 5, }, [3] = { ["CLSID"] = "{UB-32_S5M}", ["num"] = 4, }, [4] = { ["CLSID"] = "{UB-32_S5M}", ["num"] = 3, }, [5] = { ["CLSID"] = "{UB-16_S5M}", ["num"] = 2, }, [6] = { ["CLSID"] = "{UB-16_S5M}", ["num"] = 1, }, }, ["tasks"] = { [1] = 35, }, },-Save your changes, go back into DCS and select the loadout. The stations should now have S-5 rockets. They work surprisingly well with the module, and it immediately becomes apparent why the rockets can only be set to launch in bursts of 4, 8, and 16 Disclaimer: I haven't tested this in a while now and I don't have time to verify that it still works atm, so let me know if doesn't.

Alright, I'll assume you already did everything I suggested. I don't think I can help given the information, but if you want you could post a short track demonstrating the issue, along with a detailed description of exactly what your control inputs are. It might help me or someone else figure out what's up.

Hmm, odd. First thing I'd do is carefully check that only the axes you use for pitch and roll are actually assigned to those functions, since DCS can sometimes be overzealous in assigning default axes. Then try hitting reset in axis tune to be sure a sensitivity curve or slider setting isn't messing it up. Also, I know I already suggested it, but check to be absolutely sure that the button used for trim reset is only bound to that function; the best way to check is to open Control Options, push the trim button, clear the assignment, and then push it again to ensure it doesn't jump to another assignment. If none of that works, I'm not sure I can help beyond suggesting to just delete your control settings for the module :/

Then it must be getting overridden by one of the default profiles provided for some peripherals. Add the code yourself to the file for your device if it isn't already commented out there - for example, Joystick - HOTAS Warthog.lua has the same code on line 244 which should only need to be uncommented to work.

First of all, I am SO sorry for the long delay in replying; it kept slipping my mind If by some chance you haven't already resolved the issue yourself, I'll admit I'm not entirely sure what you're looking for - I rather hastily assumed you were looking for a way to bind a 3-way switch on a physical controller (which is what the mentioned default.lua file is for). If you're simply looking for the control name in the settings, what you want is "GUV Mode Switch - Decrease" and "GUV Mode Switch - Increase". Their default keybinds respectively (I think) are Right Alt + Right Ctrl + [ and Right Alt + Right Ctrl + ]. If instead you're looking for a set of keybinds to directly select a particular switch position (instead of the Increase/Decrease rotary we're given), I think I could whip something up real quick. EDIT: If I've already answered your question, you can ignore everything past here if you want. What follows is a description of how to add certain custom functionality to DCS; if that isn't what you're interested in it's probably a waste of time to read. Here's the requisite code; I don't intend to use it myself, though I did test that it works. {down = 3042, value_down = 0.0, cockpit_device_id = 12, name = _('# GUV Mode Switch - OFF'), category = {_('Left Overhead Panel'), _('Armament System'), _('# Custom')}}, {down = 3042, value_down = 0.3, cockpit_device_id = 12, name = _('# GUV Mode Switch - 622'), category = {_('Left Overhead Panel'), _('Armament System'), _('# Custom')}}, {down = 3042, value_down = 0.2, cockpit_device_id = 12, name = _('# GUV Mode Switch - 624'), category = {_('Left Overhead Panel'), _('Armament System'), _('# Custom')}}, {down = 3042, value_down = 0.1, cockpit_device_id = 12, name = _('# GUV Mode Switch - 800'), category = {_('Left Overhead Panel'), _('Armament System'), _('# Custom')}},From your question, I assume you're not familiar with the function of the default.lua file I mentioned. I haven't really seen any good, concise explanations so I'll try to summarize: The files in question can be found at [DCS]\Mods\aircraft\[Module]\Input\[Module] or something similar. What they do is define functions which can be bound to physical controls, so they're often edited to adapt DCS's keybinding functionality to a particular peripheral device (usually to support toggle switches). This means that typically, only the joystick/default.lua file is edited, although the keyboard/default.lua file can also be edited to change or add functions which can be bound to keypresses. Looking at an example, in this case [DCS]\Mods\aircraft\Mi-8MTV2\Input\Mi-8MTV2\keyboard\default.lua we can see some script stuff happening at the top (which I'm not gonna explain in order to keep this somewhat concise), then underneath is the start of a long block of code concatenating base.keyCommands with all the necessary controls to actually use the module (this means that you could add your own join(base.keyCommands,{}) block, though you may prefer to just insert your modifications into the existing block). So, in order to actually use the code I've provided, you'd open the file and then paste the code within the join(base.keyCommands,{}) block, which would then look something like this (excerpted): ignore_features(base.keyCommands,{ "Camera jiggle" }) join(base.keyCommands,{ {down = 3042, value_down = 0.0, cockpit_device_id = 12, name = _('# GUV Mode Switch - OFF'), category = {_('Left Overhead Panel'), _('Armament System'), _('# Custom')}}, {down = 3042, value_down = 0.3, cockpit_device_id = 12, name = _('# GUV Mode Switch - 622'), category = {_('Left Overhead Panel'), _('Armament System'), _('# Custom')}}, {down = 3042, value_down = 0.2, cockpit_device_id = 12, name = _('# GUV Mode Switch - 624'), category = {_('Left Overhead Panel'), _('Armament System'), _('# Custom')}}, {down = 3042, value_down = 0.1, cockpit_device_id = 12, name = _('# GUV Mode Switch - 800'), category = {_('Left Overhead Panel'), _('Armament System'), _('# Custom')}}, ------------------------------------------------ -- Cheat --------------------------------------- ------------------------------------------------ {combos = {{key = 'Home', reformers = {'LWin'}}}, down = iCommandEnginesStart, name = _('Auto Start'), category = _('Cheat')}, {combos = {{key = 'End' , reformers = {'LWin'}}}, down = iCommandEnginesStop, name = _('Auto Stop'), category = _('Cheat')},This will cause four new controls to appear after restarting DCS, allowing you to easily bind keypresses to individual GUV Mode Switch positions. It's also important to note that files under the main DCS directory (as opposed to Saved Games) will be overwritten when updating the game, so keep a backup or use something like JSGME (if anyone knows of a way to use Saved Games for this, please correct me!).

The strange thing about this is that the necessary line of code is already present in the joystick default.lua, just commented out. Search for the line containing "Set Gunner Seat" and you'll find it - all you need to do is delete the leading "--" to match the other lines. Presumably they had their reason to disallow binding that function to a peripheral, but I have no clue why. So if you uncomment the line just be aware it might possibly cause some other control to break (though it seemed to work fine for me). I should note I also generally delete all the other files besides default.lua because I prefer to set things up myself, so also be aware that some other peripheral's default bindings might interfere.

That sort of thing is generally caused by mechanical imperfections in the stick, which can be exacerbated by very precise sensors. Try adding a small deadzone, then increasing it until the stick remains centered with repeated trimmer presses. If I'm misunderstanding the issue and the problem is that the controls register a sharp deflection when pressing the trimmer, you may somehow have the trimmer bound to that stick direction (as in the binary "bang-bang" control, not the analog control in the axis group).

Sure - using %USERPROFILE%\Saved Games the .sdef files are [DCS]\Sounds\sdef\Aircrafts\Cockpits\TrimmerClickHold.sdef [DCS]\Sounds\sdef\Aircrafts\Cockpits\TrimmerClickRelease.sdef [DCS]\Sounds\sdef\Aircrafts\Mi-8MTV2\Cockpit\Mi8WheelBrakeOff_In.sdef [DCS]\Sounds\sdef\Aircrafts\Mi-8MTV2\Cockpit\Mi8WheelBrakeOn_In.sdefI'm also using a small sound mod from here: https://www.digitalcombatsimulator.com/en/files/2083710/ Something of a "trick" you can do to adjust the gain of a sound without calculating for each value manually is to structure the file such that a line like local gf = 2.0 appears at the top, and gain = (gain * gf) appears at the bottom. For example, the file [DCS]\Sounds\sdef\Aircrafts\Mi-8MTV2\JumpAlarm.sdef has the following contents by default: wave = "Effects/Aircrafts/Mi-8MTV2/JumpAlarm" inner_radius = 10 outer_radius = 100 attack = 0.05 release = 0.1 gain = 0.65To double the gain programmatically, change it to: local gf = 2.0 wave = "Effects/Aircrafts/Mi-8MTV2/JumpAlarm" inner_radius = 10 outer_radius = 100 attack = 0.05 release = 0.1 gain = 0.65 gain = (gain * gf)

Amazing video! As said, it really shows how BST have put in the effort for authentic sounds. I especially enjoyed hearing the rotors as the "needles split". It also seems to confirm among other videos that the sounds of the wheel brakes releasing and the trimmer magnetic brake are somewhat muted in the sim (so a while back I bumped them up a bit).

{down = 3042, value_down = 0.3, up = 3042, value_up = 0.2, cockpit_device_id = 12, name = _('# GUV Mode Switch - 622/624'), category = {_('Left Overhead Panel'), _('Armament System'), _('# Custom')}}, {down = 3042, value_down = 0.1, up = 3042, value_up = 0.2, cockpit_device_id = 12, name = _('# GUV Mode Switch - 624/800'), category = {_('Left Overhead Panel'), _('Armament System'), _('# Custom')}}, Copy/pasted from my default.lua. The '#'s are there so the custom additions appear at the top of the sort order, as well as the '# Custom' category. If you want them to be sorted normally delete the leading # and space.

:D (sadly the S-24 doesn't seem to work)

Looks good now! That switch doesn't need to be on for anything (unless mines are added), though you do need to ensure that the weapon/payload selection rotary isn't set to ГУВ, or nothing will jettison. A nice little "undocumented feature" of the bomb system is that it can be used to "trick" the weapons system to perform selective jettison of stores, which can be useful if you've expended all your ammo from a rocket or gun pod (though it's not realistic to do so of course): first set the payload selector to a position in which the store you want to jettison would be considered a bomb (e.g. II, all bombs). Arm the master arm and the bomb release with the ГЛАВНЫЙ ВЫКЛЮЧ БВ switch on the right panel, then use the ЭСБР box below the copilot's instrument panel to carry out the normal bomb release procedure.

Wow! That's quite a good tutorial - I like the use of images to point out controls. Just a few small remarks: In step 4, the left switch you've highlighted (главный выключатель минного вооружения) is for controlling the mine dispensing systems, so it's unnecessary to use in the sim as of now. In step 5.1, that switch doesn't need to be in any particular position to use the ГУВ pods, though it does indeed need to be set to РС (which I assume stands for Ракетная Система or something) to fire rockets. The ПУС (Прибор Управления Стрельбой) arming button highlighted in step 5.2 is only used to prepare the ПУС to fire rockets in the correct sequence, so it only needs to be pressed when using the С-8 or С-5 rockets. Lastly, you can verify the ГУВ or УПК pods are ready to fire by checking that the red lights just above their ammo counter drums are illuminated. Anyway, yeah; there's a lot of little "gotchas" and unintuitive steps involved with the Mi-8's weapons systems and if I tried to list them for all the different configurations I'd just end up mostly repeating the manual. Come to think of it, a flowchart would probably be a more useful format rather than a linear checklist. Ah, bombs. If only...

We can now safely consider СПО-10 to be confirmed, yes? Sorry if I missed a previous confirmation.

And don't forget you can switch the individual guns on and off using the overhead CBs :D Useful if you don't want to burn through your ammo quite so fast (although those pods sure do carry a lot!)

Sorry to necro this thread, but I wanted to post an update for anyone still affected by this. I recently learned of the alternative to editing the views.lua file - as per https://forums.eagle.ru/showthread.php?p=3760023&postcount=9 a copy of the server.lua file under Saved Games should be edited instead by appending the necessary code. The ID you want for the Mi-8 is Mi-8MT e.g. ViewSettings["Mi-8MT"] = { Cockpit = { [1] = {-- player slot 1 CockpitLocalPoint = {3.916, -0.11 , 0.0}, CameraViewAngleLimits = {20.000000,160.000000}, CameraAngleRestriction = {false,90.000000,0.400000}, CameraAngleLimits = {140.000000,-65.000000,90.000000}, EyePoint = {0.090000,0.000000,0.000000}, limits_6DOF = {x = {-0.200000,0.400000},y ={-0.200000,0.25000},z = {-1.0,0.650000},roll = 90.000000}, }, [2] = {-- player slot 2 CockpitLocalPoint = {3.916, -0.11 , 0.0}, CameraViewAngleLimits = {20.000000,160.000000}, CameraAngleRestriction = {false,90.000000,0.400000}, CameraAngleLimits = {140.000000,-65.000000,90.000000}, EyePoint = {0.090000,0.000000,0.000000}, limits_6DOF = {x = {-0.200000,0.350000},y ={-0.200000,0.25000},z = {-0.400000,1.0},roll = 90.000000}, }, [3] = {-- player slot 3 CockpitLocalPoint = {3.916, -0.11 , 0.0}, CameraViewAngleLimits = {20.000000,160.000000}, CameraAngleRestriction = {false,90.000000,0.400000}, CameraAngleLimits = {140.000000,-65.000000,90.000000}, EyePoint = {0.090000,0.000000,0.000000}, limits_6DOF = {x = {-4.500000,0.400000},y ={-0.200000,0.30000},z = {-0.400000,0.4},roll = 90.000000}, }, [4] = {-- player slot 4 CockpitLocalPoint = {3.916, -0.11 , 0.0}, CockpitLocalPointAzimuth = 90, CameraViewAngleLimits = {20.000000,135.000000}, CameraAngleRestriction = {false,90.000000,0.400000}, CameraAngleLimits = {140.000000,-65.000000,90.000000}, EyePoint = {0.090000,0.000000,0.000000}, limits_6DOF = {x = {-1.8, 0.2}, y = {-0.6,0.5}, z = {-1.1,0.25}, roll = 90.000000}, }, }, -- Cockpit Chase = { LocalPoint = {-5.700000,1.400000,-3}, AnglesDefault = {0,-8.000000}, }, -- Chase Arcade = { LocalPoint = {-20.000000,5.000000,0.000000}, AnglesDefault = {0.000000,-8.000000}, }, -- Arcade }

I've killed a few helos in flight with HOT-3 missiles (not MP, but still...) and I figure if you have the skill to get consistent hits with RB-05 on anything, an A-A 9M114 oughta be completely doable :D

Thanks a bunch - really appreciate all you contribute here, especially the presentations which have been invaluable to my understanding of these systems. And such good pictures too!

Speaking as a user of self-centering pedals, I was curious and had to test the AP yaw channel with Rudder Trimmer off (I've only ever had it on). At least in Central Position Trimmer Mode, it seems to do absolutely nothing. So if you want the benefit of the heading hold, it seems Rudder Trimmer must be enabled. I personally would never forgo the yaw AP channel because it's actually pretty amazing; once it reaches its 20% authority limit, it switches to "displacement mode" (as the Dash 10 refers to it [2-46]), allowing the system to move the pedals to adjust the trim through its entire range, effectively giving the yaw channel 100% authority. If you take it a bit slow, it's possible to transition through all flight regimes from ground to cruising at altitude to landing while not touching the pedals once. Certainly on. Unless I'm mistaken and it's still possible to take advantage of the yaw AP channel with Rudder Trimmer off... Yeah, trying to fight the Ka-50's AP is just painful. I consider FD mode so essential I have it bound to my stick's weapon release button and I press it whenever I need to do, well, nearly any maneuver that isn't just adjusting my trim a bit. Keep in mind that holding the trim button has basically the same effect on the AP as activating FD mode, which is why it makes the process so smooth. Hold trim, adjust attitude/heading, step on the ball, release trim, perfect coordinated flight :D (even works with the Mi-8 most of the time as well for me) As the manual states (pg 221), "In the Mi-8 depression and holding of the trimmer button do not engage alignment mode of the autopilot, as it is done in the Ka-50. I.e. trimmer as object is not interacting with autopilot at all." The trimmer shouldn't affect the AP whatsoever; the smoothness of your trimming only has to do with your trimming method and settings. You really shouldn't have to reset the trim at all unless you suddenly need to do some hard maneuvering and need the entire range of control. If you have a self-centering stick which returns to center quickly and accurately when you let go, I'd recommend giving Central Position Trimmer Mode a try if you haven't. As far as smoothness goes, it's the next best thing to a springless or actual FFB stick. And now the big one: It took me a little while, but I figured out why the yaw AP channel is sometimes inconsistent in setting a new heading, and it's rather strange; if you look at the АП-34Б control panel, at the centering knobs with the small windows just above them, you'll notice that when any particular channel isn't engaged, the indicator disks in the windows rotate on their own, corresponding to the attitude of the helicopter (e.g., when the helicopter's heading is steady, the indicator dial under "НАПРАВЛЕНИЕ" won't be rotating). If you turn and change your heading quickly, you'll notice that the indicator takes some time to catch up to the new detected heading. Halting the disk's rotation too early by activating the autopilot channel (or releasing the rudder pedals if the AP was already active) will cause the system to lock to a point between its last setting and the new heading (for example, making a rapid turn from a heading of 5° to a heading of 90° and then immediately activating the yaw AP channel could cause the system to "lock" onto a heading of 30°). In practice, what this means is that every time you make a major adjustment to your attitude/heading, you must watch the indicator window to make sure the dial has stopped rotating, otherwise you may inadvertently set the channel to a point that's too "early" in the arc. If the yaw AP setting is too far off your actual heading, it will indeed cause the pedals to go massively out of alignment and destabilize the helicopter. Now I have a mouse with a freewheeling scroll wheel, so I wanted to mess with the AP a bit since I can shift+scroll like nobody's business :P As it turns out, the indicator might not actually be realistically limited in how much it can lag behind. Turning the centering knob with a good, solid flick of the wheel resulted in the system taking over a minute and a half to realign. The dial can also be sped up to expedite realignment by turning it in the direction of your turn. Unrelated, but the autopilot indicator that shows up with the controls indicator seems to feature Cyrillic characters regardless of language or cockpit settings, including the 'Л' and 'П' indicators which show up in the heading AP channel when the system enters "displacement" mode to move the pedals. Further trivia: this seems to be the only indicator of when the pedals are being moved by the AP (other than seeing them move of course). OKAY, this is the last of the text wall; it's a question for any devs or experts who may be reading: In the Dash 10 (2-46), it states "When the pilot’s feet are on the pedals, the sub-pedal microswitches activate, the force trim disengages, and the yaw channel operates in stabilization mode." So, my question is, is the "stabilization mode" implemented in the sim in any way? As I understand it, the pedal microswitches are simulated by the AP disengaging when the pedals are moved (always wondered why that couldn't be implemented with an additional option of having the toe brakes activate the switches), but I'm not noticing any additional "stabilization" when the pedals are off-center with the AP on. Is the Dash 10 or my reading comprehension just off base here?

Oh no.. I hadn't even really considered that aspect. Was the announcement made after BST was certain of the merge with ED? Worst case scenario, doesn't that leave open the possibility the module could be put on hold indefinitely? The teaser in that video for the F-18 is at least some good news timeframe-wise, right? Couldn't that problem AND the "mushroom PR" be avoided if they simply gave an honest assessment of their current progress, with no plans or predictions given? If anything, it would reduce the pressure on them since the community would have their curiosity as to the state of the module sated. Personally speaking, I wouldn't even mind if they said "we have nothing but the model and some textures completed" since it'd be something to go on.

I also made a post about this issue here https://forums.eagle.ru/showthread.php?p=3617011&t=219595 I expect these sorts of problems will be on the backburner until the F-18 is further along in development. I don't think issues like these will disappear without a complete overhaul of the lighting. (Maybe even delayed until after the release of the Mi-24? I certainly hope not...)

+1 But I'd like to go slightly off topic to elaborate for the benefit of anyone who hasn't had the "fun" of experiencing this for themselves, because it's nearly impossible to exaggerate how dreadful night flying is for Mi-8 players after prematurely forcing the deferred shading lighting engine on us. Let's break out the old 1.5.8 install for comparison purposes... The versions in use here are 1.5.8.12823 and 2.5.3.21153, henceforth "Old" and "New" DCS. First, here are the settings I'll use for the screenshots. They're not particularly important though, because the only one that has any significant effect for my purposes is gamma (which will be 1.8 or 3.5[maximum]). Mi-8 will be at Batumi with default weather and time of around 00:00. Due to ground lighting being added in the New version, I've removed objects around the starting area to improve the comparison. Here's the pilot's view at night with no external lights and full instrument lighting (except for the anticollision beacon in Old DCS): Old, New (γ = 1.[noparse]8)[/noparse], New (γ = 3.5) On my monitor, New DCS with moderate gamma is unusable. The instrument lighting is absurdly dim and provides almost no contrast against the dark instrument panel. In addition, the blue interior provides no benefit to contrast or visibility without additional lighting, which is especially clear in the boosted gamma image. In Old DCS, the blue coloration helps to delineate the instruments even in a totally dark cockpit. This image is New DCS (γ = 3.5) with all external lighting minus taxi and landing lights, showing the bizarre effect of external lights on interior lighting. The visible anticollision strobe has been extensively reported, so I won't elaborate on that, but the effect of the navigation lights is equally intrusive; minus the red from the strobe, the sudden change in brightness here is entirely due to having the nav lights set to bright; when set to dim, the cockpit returns to light levels from the last example screenshot. It's strangely all-or-nothing. This comparison needs no introduction: Besides the extremely obnoxious and distracting effect of the taxi light on interior lighting in New DCS (which has likewise been reported extensively so I'll leave that there), note perhaps more importantly how ineffectively it performs its function; it's to the point that it's now worse than useless since the distracting effect of the bright interior detracts from the meager improvement in external visibility. These are the external views with taxi lights on and landing lights rotated back to improve lateral visibility (New γ = 3.5) The lights in New DCS seem to barely illuminate beyond the rotor disk. You must rely entirely on NVGs when landing in unlighted areas. Not much more to say here. These are the F4 external views - Old, New (γ = 1.[noparse]8)[/noparse] Since the New DCS overhead view used a high gamma, I've included this to show what I'm trying to work with here. The goggles do everything! Last example is an animation showing the differences in appearance of the Old vs New (γ = 3.5) PTIT gauge (which I chose because it includes some color) under (respectively) both red plafond flood lights, the pilot's red light only, the pilot's white light only, and both white lights: Because of the very dim instrument lighting in the New version, instruments suffer far more inconsistency in appearance under different ambient lighting conditions. I don't know whether or not this is realistic, but the extreme dimness in blackout conditions leads me to believe it isn't. Either way, I would expect a bump in brightness to improve the consistency, and thus readability. (side note: you may have noticed some of the images posted are .jpg instead of .png. Imgur was giving me issues with those for some reason so I converted them. The quality should still be almost completely intact though)

Yeah, the APU will flat-out refuse to start above a certain density altitude. I did some testing and found that the APU will refuse to start above 4422m ASL (true as taken from the F2 external view) @ 20°C & 760mmHg QNH as set in the editor (OAT read about -9°C). My altitude off the altimeter was about 4366m (with the Kollsman window set to 760mmHg). I've wondered about that question myself, and I've tried just about everything including running all of the anti-ice systems, repeatedly trying to start the APU, running the КО-50, switching on only the essential CBs, using ground power, etc. It seems that the only way to achieve proper conditions for starting the APU is to be within the temperature and density altitude limits. And it's a HARD limit; the APU would refuse to start in my test if I moved the starting point just 1m up the slope (the limits are also affected by temperature and QNH changes). I wish I could provide a formula for finding the density altitude using the OAT gauge and altimeter, but I can't figure that out right now, lol Only advice I can give is that if you need the engines running at very high altitude, either don't shut them off after starting at a lower altitude or use the hot start option in the editor. I would certainly like to be wrong about this (if anyone else can provide info) as it's been a minor annoyance to me as well.