Search the Community

Good afternoon everyone, Just wanted to let everyone know about a new mini-campaign for the best helicopter in DCS. I'm creating this thread for any feedback, bug reports, etc. because I don't get notified on new Comments in the User Files. The summary: In April of 2022, a Brazilian journalist has been kidnapped near the Ba'ath Dam. You've been hired by a Private Military Company to provide helicopter support and transport to help locate and rescue the journalist. The campaign has full voiceovers with kneeboard pages. It's not meant to be a difficult campaign. As long as you can start up, take off, and land the Huey in FARP-sized landing areas, it will be fine. The difficulty ramps up through the 4 missions, however. If you're interested, here's a link: https://www.digitalcombatsimulator.com/en/files/3334386/ Thanks, and fly safe!

AB-212 / AB-412 / Huey II - look-alike facelift MOD for the UH-1H, plus UH1 Cutters, Winch and Radar Attachments by rato65 UPDATE notes: 05. January 2024 - AB-412 Top texture template AB-412_TopMap_published.psd 25. August 2023 - Nose texture template (all versions) AB-412_NoseMap.zip 23. March 2023 - civil liviery (Gatari) with textured AB-212 turbine cover for download: https://www.dropbox.com/s/zm6lkqk1jmwic5f/AB-212_Gatari.zip?dl=0 - detailed AB-212 turbin cover template texture AB-212_topMap.dds AB-212_topMap.psd 10. March 2023 version: 1.02 - added Huey II variant with payloads - added red nose texture file NOTE: To install update, delete all Mod files from previous releases, including /MissionEditor/UnitPayloads/UH-1H.lua before installation. - corrected UH-1H.lua (missing Huey II cutters_pads configuration, corrected WTS and Powerline loadouts, added cutters to WTS and powerline loadoutsn thanks Neo47) - now included in 1.02, or as separate file here: UH-1H.lua 9. March 2023 version: 1.01 - updated UH-1H.lua for MissionEditor/UnitPayloads with all currently active payloads listed (thanks Neo47) Thanks to EightBall, we now have - a new organization of textures to be used in liveries rather than copying after fixed color scheme - according setup of the sample liveries - all textures saved as dds instead of png 08. March 2023 version: 0.2 - initial release DOWNLOAD: https://www.dropbox.com/s/hfgv036jeow5poz/UH-1H_AB-212_AB-412_Mod v1.02.zip?dl=0 INTRODUCTION: The package contains cutters, a winch, a front radar and pads to mount as loadouts onto the UH-1H. In addition it mounts a new nose and top to make the UH-1 appear like a Huey II, AB-212 or AB-412. Obviuosly, this is just cosmetic and does not provide 4 blades or a new cockpit. So, in the end it is for eye candy and enthusiasm... I made this for myself to gain/improve some skills in 3D modelling, texturing and lua scripting, and because cutters were missing for the civil version of the Huey. Tested with DCS 2.8.0.3. USE AT YOUR OWN RISK! INSTALL: Unzip the package. 1. Copy the content of "tech" into your "Saved Games/DCS/Mods/tech" folder 2. Copy the content of the "/tech/UnitPayloads" into your "Saved Games/DCS/MissionEditor/UnitPayloads" folder. > CAUTION: if you already use attachments for the UH-1H module, make a backup of the "UnitPayloads/Uh-1H.lua" file before you overwrite. I needed to delete it before copying the one in this package, otherwise the game would not recognize. > NOTE: I included EightBalls attachments from https://forum.dcs.world/topic/266028-uh-1h-attachments-mod/ into my "UnitPayloads/Uh-1H.lua" file, so the should be still available after you install this package, if you had used them previously. 3. Copy the example UH-1 liveries into your "Saved Games/DCS/Liveries/UH-1H" folder 4. Use JSGME to install the folder "UH-1H Spec Map Mod" to remove the UH-1H unrealistic shiny effect. USAGE: 1. Loadouts: The Mission Editor Loadout menu offers you to choose from different new payloads attached to Pylon 2 (AB-412, cutters, winch, and radar, pads and their combinations). You cannot change the Pylon, and you need to load the complete payload pack listed. To hide the gun pylons, I strongly recommend to make use of EightBalls "PylonsOff" Livery method: https://forum.dcs.world/topic/266028-uh-1h-attachments-mod/ In ME: - first load the payload - second load EightBalls PylonOff Livery - third load your desired UH-1H Livery 2. Attachment colors (updated): All textures are now in one folder without subfolders, and named after color. They can be chosen by the Livery description.lua you like to use (see below) 3. Liveries: The appearance of the AB-212/AB-412 should be constistent on the complete fuselage. I include 2 real live AB-212/AB-412 liveries which are tuned with spec maps so they match the AB-212/AB-412 attachments relatively well. It was the best I can do, others may have more knowledge to make it even better. See the description.lua how the different colors of the attachments are configured according to the UH-1H livery. 4. JSGME Specular Map value replacement: In order to make the AB-212/AB-412 reflections and metal surfaces look consistent between fuselage and fuselage attachments (see screenshots provided), you need to tweak the games original AB-212.json file. Most of the people have done that long time ago already to remove the unrealistic reflection appearance. I recommend strongly to use JSGME to install the MOD-folder "UH-1H Spec Map Mod" to remove the UH-1H unrealistic shiny effect. With JSGME you can restore the original setting anytime with one click. CREDITS: This mod was inspired through the work from Upuat, EightBall and some chat with Lvergara. I used some snippets of lua-scripts from each of these authors and modified them for this project. The Assets were modelled by me, the AB-212/AB-412 parts were taken from a basic royalty free cad model and modified by me. The example liveries included were published by AWACS_Bandog and tango down565. EightBall proveded some immediate improvement regarding texture organisation and livery configuration. Have fun! cheers, rato65

I am building a motor driven cyclic to provide variable centering torque and trim position, and one of the key goals is to have the stick follow the co-pilot stick when the co-pilot is flying (either when 'autopilot' or in multiplayer) - in the real Huey the two sticks are mechanically linked so the always follow each other, and linking them in the game means that way when you take back control the stick is already in the right place. However I have not been able to find any exportable data for the stick position. (This may be specific to the Huey, I'm not sure, but I imagine the it should probably be common to all aircraft) The list_cockpit_params() lua function returns BASE_SENSOR_STICK_PITCH_POS and BASE_SENSOR_STICK_ROLL_POS, but it is just a reflection of the pilot stick input - when in 'autopilot' it continues emitting the pilot stick input position (ie. my joystick position), not the copilot stick position that is actually controlling the aircraft. When you show the control positions overlay, it is the position of the white copilot diamond I want, not the one that moves with my own stick. This data is obviously there somewhere as it is used to display on the controls overlay and also used to animate the cyclic position when in 'autopilot' mode - the question is, is it accessible from a lua script? Any ideas, anyone?

The synchronized elevators on our huey are symmetrical. They aren't supposed to be. I believe this image shows it off well enough You think it's just an artifact of the old photo? here's a newer photo You want documented proof of it? Page 56 Why has this never come up before even from people who look through data? Because the data usually only ever references the right elevator alone. I don't know why.

OK this subject is fun. FIRST OFF AS IMPLEMENTED our XM60 sight has the 50mil DIAMETER reticle HOWEVER A 50mil RADIUS reticle ALSO exists As does an 80mil DIAMETER reticle. all for the same sight. 3 Different reticles 1 sight Wild, right? Regardless. AS IMPLEMENTED Our sight is the 50 mil DIAMETER sight. As implemented, it IS correctly scaled. A 50m wide object at 1000m will fill the diameter of the 50mil diameter sight. Here is the proof, the C-17 has a wingspan of 53m There is nothing wrong with the reticle itself. The problem lies within the elevation knob. This thing. This knob is measured in mils. So if you increase or decrease it by 50 mils, the 50mil diameter sight should move so that the top is now where the bottom was, or vice versa The reticle should move by 50 mils if you change the knob by 50 mils, simple. HOWEVER. As you can see, to shift our 50mil diameter reticle by 50mils, we have to change the elevation by 95 mils. This is obviously incorrect. This isn't a matter of just changing the scale of the reticle either, as that doesn't fix the issue. The issue is that 5mils of elevation on the knob, does not equate to 5mils of rotation in the reflector sight. Changing the scale of the reticle won't fix that. This matters because the elevation table on the sight itself, this thing Asks you to adjust the elevation by mils. This means adjusting the elevation by 20 mils does not actually adjust the elevation by 20 mils, meaning your sight zeroing is incorrect for your chosen parameters. This needs a fix, either changing the scale depicted on the knob itself, or by changing the amount of elevation displacement so that it matches up to the number of mils on the elevation knob. I do not know which would be the correct option that would make it more like the real thing, however either option fixes the issue.

I don't know if anyone else is having this issue, but its driving me bananas. When flying the UH-1H in the Syria map I get a beacon that I can't turn off. Easy comms off, all radios off, marker beacon volume off. Nothing seems to stop it. Its probably something simple I'm missing. Please help.

Hello everyone MIG-25 Soon KA-27 Soon MIG-21 Soon 82nd Squadron Discord https://discord.gg/T64sr2tcdp 82nd Squadron Instagram https://www.instagram.com/82ndsquadron/ JF-17 Azerbaijan (-) https://www.digitalcombatsimulator.com/en/files/3315051/ JF-17 Azerbaijan Blue by @Kerbo 416 https://www.digitalcombatsimulator.com/en/files/3319796/ SU-25A Azerbaijan (Based on real life) https://www.digitalcombatsimulator.com/en/files/3318990/ SU-25T Azerbaijan https://www.digitalcombatsimulator.com/en/files/3312935/ MIG-29S 2021 (05) (Based on real life) https://www.digitalcombatsimulator.com/en/files/3327895/ MIG-29S (Based Thor77 Userfiles Thank you very much for doing this to him) Updated Version by Aqil Huseynov (Based on real life) https://www.digitalcombatsimulator.com/en/files/3318210/ F/A-18C Fictional skins https://www.digitalcombatsimulator.com/en/files/3329205/ Black https://www.digitalcombatsimulator.com/en/files/3329206/ Blue https://www.digitalcombatsimulator.com/en/files/3329207/ Desert F-16C Desert Fictional https://www.digitalcombatsimulator.com/en/files/3332610/ F-16C Fictional https://www.digitalcombatsimulator.com/en/files/3317665/ UH-1H (Based on real life) https://www.digitalcombatsimulator.com/en/files/3314049/ MI-24P (Based on real life) https://www.digitalcombatsimulator.com/en/files/3316915/ V1 https://www.digitalcombatsimulator.com/en/files/3317025/ V2 Mi-24P Azerbaijan Army Historical 1993 (Based on real life) https://www.digitalcombatsimulator.com/en/files/3330662/ MI-17 Azerbaijan (Based on real life) https://www.digitalcombatsimulator.com/en/files/3319665/ Mi-8MTV2 Azerbaijan Air Force (Based on real life) https://www.digitalcombatsimulator.com/en/files/3316844/ AH-64D Azerbaijan https://www.digitalcombatsimulator.com/en/files/3321584/ L-39 Albatros (Based on real life) https://www.digitalcombatsimulator.com/en/files/3315252/ SU-33 Azerbaijan Air Force (Fictional) by 121Fistick https://www.digitalcombatsimulator.com/en/files/3326763/ MQ-9 Drone https://www.digitalcombatsimulator.com/en/files/3313553/ IL-78M Azerbaijan Based on IL-76 https://www.digitalcombatsimulator.com/en/files/3318990/

It needs another rework. For the points marked as "level flight impossible", I am unsure if it is realistic or not, it is very possible the real aircraft produced enough power that full forward cyclic could not maintain level flight. However data for flight over the Vne of 125knots, let alone over 50PSI is hard to come by, and usually for the UH-1H with the old blades. Overall the huey has more available power, however at low speeds the performance discrepancy is not good. You go from requiring far too much power to requiring far too little power. However, the engine profile doesn't seem to take altitude into account. As for the engine profile itself, it is still underpowered at high power settings. The new profile produces 50PSI (1158shp) at 101% N1 The real huey produces 50PSI (1158shp) at 96-98% N1 However the EGT profile has improved significantly. The hover performance is not great, however. It requires too much power at every weight. Here is a more advanced profiling of the hover performance. The new WIP fuel consumption is far better than it was, but it's still using too much fuel at higher power settings, however it is reaching what could be considered "close enough", but could still use another tweak. The rate of climb is messed up too.

qnh scale shows 3100 between 2999 and 3000 on the copilot's altimeter. both ways. track attached uh1-copilot-qnh-setting 2.trk

11th Separate Army Aviation Regiment - EU Based We are a small Group of Casual DCS Players. We are simulating a real existing Ukrainian Helicopter Squadron. Our Language is English and we are flying all Kind of Helicopters but also Fixed Wing Aircraft. Mainly playing PvE but also looking into maybe joining Blueflag again. Open for new Players with certain maturity but still focused on Fun. No Skill requirement, new Players welcome to learn together to fly Helicopters and Planes. We Fly Transport and Attack Missions and are trained with CTLD/CSAR Script. Roster: 11thSAAR Tobas 11thSAAR Vanguard 11thSAAR RedEffect 11thSAAR Azvel 11thSAAR Scase

Original title of this thread - Intro Mission - Blown Away Reflected - sir, your dream of creating a realistic and extremely engaging campaign seems to be a reality. I sincerely hope this is a financial success for you. That being said, I picked up the Huey over the weekend and purchased your campaign based on the "buzz" around the community. I also was pointed your direction by fellow Campaign creator, @Badger633. I ran the opening mission this morning and was blown away by the immersion. I can see why people are so impressed. If the rest of the campaign resembles the first mission, I am in for a real treat! Just want to say thanks for all the HARD WORK you put into this product. Also - I am enjoying your YouTube videos on building missions/campaigns. You rock!

EDIT: I have done a large amount of personal research on this topic and have posted my findings later in this thread, however I will quote them here There is a lot of confusion, misinformation, and straight up speculation in this thread, I originally barely knew what was going on with any of this when I first posted. The contents of this quote are my current belief on this topic and I'm sure are the definitive answer as well. Anything past this quote is the original text of the opening post. This issue has been present in this module since at least 2016, if not earlier. I figured something as major as a broken flight instrument would be fixed relatively quickly but here we are. This has been reported before as the flight model not requiring right pedal input at speeds nearing and passing cruise. That is entirely false. The flight model has the right pedal requirement at these speeds properly implemented. The actual issue is that the slip indicator does not properly operate alongside this. As the need for right pedal increases, the leftward motion of the slip indicator increases, almost as if its effects are completely inverted. This is not some aerodynamic effect, it's not wind, it's not translating tendency, it's not the fact that the map is not projected on a globe, it's not user error, it's not a flight model issue. This is a genuine bug with a flight instrument. Don't believe me? Here is an image of the huey in cruise with the ball centered alongside an image of that exact moment in tacview. Notice anything? Because I do For comparison, here's an image of the huey in cruise that's actually closer to coordinated flight, look at the slip indicator Notice anything? I do, the slip indicator is wrong. Oh but surely the SMEs didn't let this slip by, surely this is how it's supposed to be. Right? No. Go look up any flight videos of the huey that show the cockpit during level cruise flight. You'll find that at 90knots, the slip indicator will be centered with the pedals slightly to the right, pretty much exactly as much as is required in DCS. The flight model is correct, it's quite good. The slip indicator is broken. I just want to be able to trust my flight instruments. Please, it's been long enough.

is there any Venom mod base on current UH-1 ?

This has major implications on the flight model, to the point where the entire flight model could be considered incorrect. null This document has a lot of interesting information in it, but what we care about is this graph. This graph shows the relation between the position of the anti-torque pedals and the pitch of the blades of the tail rotor. It shows that at full left (0%), the tail rotor blades have a pitch of 18 degrees. It shows that centered (50%), the tail rotor blades have a pitch of 4 degrees. It shows that 65% from full left, the tail rotor blades have a pitch of 0 degrees, making no thrust. It shows that 100% from full left, the tail rotor blades have a pitch of -10.5 degrees, making nose right thrust. The DCS huey's tail rotor blades don't even come close to that. Here is a picture with the pedals full left. The blades have a pitch of about 22-25 degrees. Here is an image with the pedals centered. The blades have a pitch of about 10-12 degrees. Here is an image of the pedals all the way to the right. The blades have a pitch of about 0- -2 degrees, we'll assume 0 degrees and the camera isn't directly above the top of the blade so it looks a little angled. OK, so maybe you think it's just an animation error. I can prove that it is not. I can prove that is how it is modeled in the flight model. But first lets look at that graph again about 24% from full left (52% left of center) shows the blades at a pitch of around 10.5 degrees. 100% from full left (full right) shows the blades at a pitch of around 10.5 degrees in the other direction. With the helicopter stationary on the ground, either of these positions should place the exact same amount of stress on the driveshaft. This means that if we turn the governor off, both positions should reduce RPM by the same amount. Not even close. The bottom left example shows the pedals 25% from full left, considered 50% left of center, this means that the tail rotor blades will be at a SMALLER pitch than what full right should be, therefore should reduce RPM by LESS than the pedals full right would. The top middle example shows the pedals 100% from full left, all the way to the right, barely even touching the RPM, infact the RPM is slightly higher. The tail rotor, as modeled on the DCS UH-1H, is modeled incorrectly, not only visually, but also in terms of how it affects the flight model. The tail rotor is modeled as if full right pedal puts the blades at a pitch of 0 degrees. Producing no thrust. The repercussions of this encompass basically the entire flight model. With the tail rotor acting the way it does, it means that the phyiscal strength of relative torque values is entirely incorrect, and proper trim in a properly modeled aircraft would technically be impossible in some basic turns.

The copilot's attitude indicator in the DCS huey looks akin to a shrunken down version of the one the pilot gets with altered controls. The style we have is more akin to the ones present in UH-1Ns or other modern hueys. Alternatively, it does match the copilot attitude indicators used in a select few australian hueys. However the rest of the instrument layout does not. When in reality, it's supposed to be a Bendix J-8 OR a Bendix MF-2 Seen clearly here in this gulf war UH-1H (of which ours is styled to be) And here Here's all the technical data showing the UH-1H using the J8

Despite being a major function of the flight model in low speed flight, the effect known as translating tendency is not actually modeled. This effect causes the huey to require a bit of left roll to hover in place due to the force of the tail rotor pushing the entire aircraft to the right. This can be seen in these photos. This is extremely easy to test in DCS Simply put the huey into a hover in a mission with no wind. If you hover rolled to the left, translating tendency is modeled. Here is a photo showing the huey hovering completely level in DCS. null The huey DOES require a bit of left cyclic to hover in DCS, but that is only enough to counter the torque caused by the tail rotor being above the center of mass applying a twisting force to the tail. It's enough to stop the helicopter from rolling, not to stop the translating tendency that isn't modeled.

The Copilot's collective in DCS is just a copy pasted version of the pilot's collective, this is wrong. You can see what the Copilot's collective is supposed to look like in these photos and many others.

Blindsided : 5th revision (v6.0.5.0) Original release in 2012, a decade of getting 'Blindsided'! Updated for modern DCS, now fully voice acted and re-scripted with a new twist or two! Mission download here! Co-operative mission supporting up to: 46 player slots (2-6 players recommended default, 3-12 on difficult). Flyable aircraft: CAS (Air to ground) - 2x A-10C (Old), 3x A-10C II, 3x AH-64D, 2x AV-8B, 3x F-16, 3x F/A-18, 2x JF-17, 3x KA-50, 3x Mi-24P, 3x Su-25T CAP (Air to air) - 2x F-14B, 2x F-15C, 3x F-16, 3x F-18, 3x MiG-29, 2x M2000C CSAR (Search and rescue) - 2x Mi-8MTV, 2x UH-1H [Briefing room] We have not received any word back from the eastern patrol, since they reported hearing heavy vehicles in the pass. We can only assume the worst. Twenty minutes ago we received confirmation that insurgent forces are attempting a surprise attack on the Batumi aerodrome. Be advised we have received reports that the insurgents are able to mount a credible anti-air threat, furthermore there are indications they may have the support of unknown airforces. US Specops are right now sending ahead a two man TACP unit, designation 'Ferret', to provide coordination for a counter attack on an insurgent outpost located due east. Before we can rid ourselves of the outpost though, we must succesfully defend Batumi from the insurgent forces closing in. Be aware that we are facing at least two groups heading in from the outpost. Local defense forces are engaged with light enemy units as I speak. Your aircraft have been fueled and armed, there is no time to waste, scramble! Aimed at: Pilots reasonably comfortable with combat tasks and start up, moderate difficulty level. Pilots up for more challenge can enable higher difficulty at the beginning of the mission (Radio options, F10 Other). Featuring: * Co-op and single player support. Note: Difficulty higher for single player. * Plenty of scripted events with radio traffic and detailing. Fully voice acted! * Combined operations of air to ground and air to air aircraft, all playing important but not interdependent roles (Set higher difficulty for best effect). * Adapting mission design: Air to ground, air to air and combat search and rescue operations are each an optional component of the mission. All you need to do is fly the right aircraft and the mission commences. * Dynamically generated randomized air to air threats for the entire duration of the mission. You can't be sure where the enemy air assets will strike from. * Dynamically generated CSAR rescue operations for both stranded aircrews and vehicle crews. * Up-to-date tasking can be requested even if a player enters the mission in the middle of it. No more guessing what state the mission is in. * Choice of two difficulty levels. * Some more aggressive, scripted AI behaviour. * Some munitions restricted through the warehouse functionality for a proper challenge. * On the move troop deployments. * Airlifted JTAC available (but not necessary) for operations against the insurgent outpost. * Optional AFAC available for the defense phase of the mission. * Adapt to rapidly developing situations as you fight an enemy that fights back rather than passively waiting for you to attack. * Be a part of a team where your actions truly matter to the outcome of the mission. License: Freeware, distribution allowed as is with all files and attributions intact. All rights otherwise reserved, unless specifically agreed upon. (It's ok to ask.) Mission download here!

my situation. looking to build a low profile light weight mock doorgun controller (in anticipation for joystick control of mi24 doorgun) i need it light weight so that i can mount it on my motion platform. i had previously built a doorgun joystick resembling a minigun with vibration effects powered by small tactile feedback pucks (bass shakers) pushed by andre's simshakre software... IT WORKS AMAZING but it was a massive undertaking to build and would be too heavy to mount on my motion rig. im going for a simpler build and already have an idea on how to build, but it will lack vibration until i can find a solution.. that doesnt use buttkickers (because the shakers are just heavy) vibration motors seem to be my solution, but i have no idea yet on how to implement... will have to get my head into vibration circuits.. my goal is to have it read lua export send data as off/on state to arduino to send voltage to vibration motors... any mad scientists in here?

I'm going to start this with yes I know the airspeed indicator isn't supposed to indicate speed perfectly. There is a degree of error at different speeds. This is about the module's airspeed indicator not properly following the error the real aircraft has. I'm going to preface with this, yes, it's a discrepancy of 8 knots, normally it wouldn't be THAT bad. The problem is that this error is at a true airspeed under 40 knots. While you're trying to land. Where accurate speed monitoring is important. Here is a profiling of 30-130knots true airspeed. You'll notice at speeds above 40 it's pretty much perfect, completely acceptable. I have ZERO issues with the calibration above 40knots. But you can see what's happening below 40. Here are some profilings of 50-30knots true airspeed You can see that there is a very clear pattern of error in our airspeed indicator that the real thing does not follow. This is part of why it hangs under 20 for so long. Another part of why is because the indicator doesn't really start moving until you hit about 25knots TAS. Documented data points toward this likely being inaccurate and 15knots TAS at 0 indicated likely being correct instead. Here is a chart comparing the current calibration vs the real one Here is that same chart but with what I suggest as a more reasonable adjustment This isn't really a critical issue like the performance model or the tail rotor being wrong, but it is an error that could be corrected. The expected IAS reading data were taken from the huey's flight manual. And the charts were taken from the composite blade performance profiling document

2022-12-16 18:02:03.393 ERROR APP (Main): Error: Unit [UH-1H]: Corrupt damage model.

I'll make it short and sweet before getting to the dataposting. The huey has a transmission power limit of 1158shaft horsepower, HOWEVER, the engine itself, while being capable of 1400shp, is actually limited to an N1% RPM of 101.8%, which is over 1300, not 1158, not 1100. In the DCS huey, the N1 limit for the engine is supposed to be higher than it is, but as implemented in DCS, it is 1158shp. At 100% N1 RPM the aircraft is producing 1158shp, instead of the correct higher value, this means that you are at 50psi of torque at 100% N1 RPM. The correct setup would be to have the aircraft produce 50psi of torque at 98% N1 RPM instead of 100%. Why is this relevant? This is relevant because at 98% N1 RPM on the real huey, you are only generating around 580C of EGT. That's right, at 1158shp, your transmission limit, you shouldn't even be close to overheating the engine. (At sea level, flight parameters change as your density altitude increases) As the huey is currently modeled, 98% N1 RPM actually produces about 590C, but it is also only producing about 990-1000shp. As we go up in N1 to reach 1158shp we rapidly gain EGT to the point where in quite a few flight profiles, we are overheating the engine, where we realistically shouldn't be, meaning we need to lower our power output to prevent the overheating when we shouldn't need to. As for the data 0 I also took the liberty of graphing the same data from the DCS huey and overlaying the different sets of data. As you can see by the horsepower graph, it very clearly does not line up with 5 other UH-1H engines that very clearly stay near each other minus a few stray datapoints. If we simply project our DCS data onto the real data plot and line them up, and assume the engine does just have a linear power curve all the way to 100% N1, we would reach 1333SHP. And if we consult null We can see that out of 12162.1 minutes of flight, this UH-1H spent 20 seconds at 1300shp. So the engine can in fact reach 1300shp while mounted in a huey. So 1333 doesn't seem like an unreasonable limit. The EGT comparison is also interesting, showing an underproduction of EGT at low N1 settings but an OVER production of EGT at high N1 settings. And before you question this and say "well maybe it's just modeled as an old engine". First, there is an engine resource slider, effectively an engine age/health slider already built into the game to simulate this so it shouldn't be modeled as having reduced power to begin with. Second. Taken from null Here is a graph comparing 2 sets of EGT data One set showing a new engine with only 16hours of operation before the data collection Another showing that same engine after 1939.1 hours of operation, the engine failed less than 10 hours later. Now here it is overlaid with our DCS EGT data There are plenty of other issues with the module, I would like to see this one (two?) fixed however. Our engine model has 1158shp as 100% N1 but is using an EGT curve similar to one with a higher 100% N1 limit, meaning we are getting less power for the same EGT output. 100% N1 Should be producing more power than it currently is. Some data says 1200shp at 100%, other data says 1330shp+ at 100%. Pre-production huey data states 100% N1 to be 1340shp. The EGT curve could use a little tweaking as well.

To put the TLDR first, our huey is underperforming by 3400lbs while being provided a lower available power than the real thing, and made slower than it's actually supposed to be at low altitude (which is where it normally operates) So what are my sources? Before that, lets start with a very simple summary of HOW WRONG the module's performance actually is. null Now, I won't act like that's the whole story with all the context, because it's definitely not. There are things like the transmission limit to take into account. But those sources, lets see them. Here are the 3 main sources, there are several other minor sources as well, however the majority of the data comes from these 3 documents. null So allow me to clarify something, our huey is one with a 1990s refit, it is the one with composite blades. You may have noticed, one of those sources explicitly mentions the composite blades in the title. That source is a performance profiling of our exact model of huey. Refits and all. Now, there's something else to talk about, the huey's operations manual. You might be familiar with this chart. This chart is useless. This chart doesn't tell us where the transmission limit is, it doesn't tell us how much engine power is being used to generate those speeds, it doesn't tell us ANYTHING. That chart is a significant misrepresentation of the huey's performance capabilities, because all that chart shows is a paper limit on the huey's speed. Vne, Velocity, never exceed. A scary term, used to define a speed you are to not exceed for assorted reasons. For the huey, the Vne is in place to keep the pilots from accelerating into retreating blade stall, nothing more. It's a paper limit to keep the pilots safe, it tells us NOTHING about how the aircraft performs. However, if you look at the bottom of that chart, "Data basis AEFA Project No. 84-33" Go back and look at top of the source that mentions the composite blades, that is AEFA Project No. 84-33. The data from that document was used to generate that chart in the manual. So before we go farther, how do we corroborate all our sources to make sure they're on the same page and providing us valid information. Cross checking. Take one set of data, and see if the patterns within it match the patterns in another set of data. We can do that. Here is the overall performance of a huey with the standard blades at 7,500lbs, derived from the data within the UH-1H flight profile performance handbook. Pay attention to the density altitude of 7500ft, you see where the yellow and red (transmission limit and power limit) lines intersect, that is where the engine can no longer provide enough power to max out the transmission. Now here is the hover performance chart from the composite blade document. Look at the rightmost line. "2ft IGE, standard day". You might have already noticed it. Incase you didn't. So our documents are in agreement, what do we do with this information? We start comparing it to the performance of our huey in DCS. Lets start with a more complete performance profiling of the real huey with the standard blades, once again, this data is derived from the UH-1H flight profile performance handbook. This data is for a huey with non composite blades. So there are multiple plots here, let me walk you through them. The first one that likely sticks out is the blue line since it's away from all the others, that is the Vne. The fact that it is placed lower than all the other data reminds us of the chart in the manual. I said that chart was useless, because as you can see by this graph, every single other plot of data performs significantly over what the Vne would have you believe. The next two that likely stick out are the red and teal lines. These are the performance of the DCS huey plotted onto the same graph, the red line abides by the incorrect EGT limit placed upon the module, the teal line ignores said limit and properly maxes out the transmission where it can. Next would be the green and yellow lines, the green line shows the maximum power the engine can normally push, regardless of any other factor, at sea level that would be 1340shp. The yellow line shows the maximum CONTINUOUS power the engine can push. This means the engine can run at this power setting indefinitely without much issue. And finally, the orange line, this line shows the safe limit of the transmission, specifically, 1158shp, or 50psi on the torque indicator. This is the huey's military thrust it can use this power for 30 minutes. This is not the LIMIT of the aircraft's performance, the transmission CAN PUSH HARDER, it just does so at the risk of being damaged. Yes, this means that, per this data, the huey should be able to reach 141knots in level flight. Something you'll notice, the teal line, our huey's performance, can't even reach the transmission limit at sea level. While, conversely, our huey's performance actually PASSES the real huey's maximum possible performance at higher altitudes. So, from this alone, you can see that the module's performance accuracy is not great. But that's not the whole story, that's just for the standard huey, and we haven't even gotten into engine performance per speed yet. We'll do that now. Here is a chart from the composite blade document, it shows the level flight performance in speed compared to the shaft horsepower generated by the engine to achieve said speed at a gross weight of 9500lbs at sea level in 15C temperature air, ISA conditions. On it, you will see a pink data plot. That is our huey measured by the same metric. 9500lbs, Sea level, 15C air temperature, ISA conditions. You'll notice that our huey isn't even performing as well as the huey with the standard blades, let alone the one with the composite blades. But first, how did I get the horsepwer data from the DCS huey, we don't have access to that data. Except we do. We are given the torquemeter, which when combined with the rotor RPM, we can derive the current SHP put out by the engine. As per our previously unreferenced source "Helicopter drive system load analysis". Pages 43-44 detail a formula to do exactly that, derive shaft horsepower from our torquemeter reading, and rotor RPM. Here is that formula. SHP=3.88*((10^-3*Rotor RPM)*((17.76*Torquemeter Torque)+33.33)) Now, you'll notice that graph shows the composite blades as being measured with the rotor at 314rpm, that's ok the difference in the result isn't exceptional, however here is a table showing the same data and including 324rpm on the composite blades. So, 639shp to push the helicopter to 100knots at sea level at 15C at a gross weight of 9500lbs. That would be 26.745psi on the torque indicator in the cockpit. As you can see by the pink line on the graph, however, we didn't even get close. We hit 36, possibly 37psi on the torque indicator at those parameters. Level flight, 9500lbs, sea level, 15C, 100knots. 36psi at 324rotor rpm, as per the formula, is about 845shp, over 200shp too high. Now, we can use this formula to find something dire. Lets make the huey as light as we can and see how it performs. 6100lbs, all it has is about 9 minutes of fuel Sea level 15C 100knots level flight about 30.5psi in those parameters. 722.8shp at 100knots. The real huey pulls 639shp in those parameters at 9500lbs. Our huey, at 6100lbs, is performing WORSE than the real huey at 9500lbs. Our huey is underperforming by over 3400lbs at low altitude. That is unacceptable. Interestingly, these high torque values also explain why we need an unrealistic amount of left pedal, which when combined with the incorrectly modeled tail rotor, brings about some interesting comparisons. So, now that we have the well documented performance profile from the standard blade huey, honestly, we could just use that one for our huey and it would be fine, the overall speed differences shouldn't be drastic, it'd be far more accurate than what we have now. As for why our huey overperforms so much at high altitude, I don't know. All my efforts were aimed at understanding its performance at low altitude as that's generally where players utilize the aircraft. I suspect it may be a combination of the engine not losing enough power at altitude and rotor mach drag not being modeled. However, for now, I believe this should be sufficient to warrant the developers looking at it. Please. Properly implemented, our torque indicator should actually max out at around 58.15psi while the N1% (gas producer) gauge reads 100% As it stands, we are using too much power, to generate too little speed, at too high of an EGT, causing us to have even less power. We are underperforming by over 3400lbs at sea level, it needs to change.

Been watching alot of videos on the M2 Browning Ma' Deuce, now inspired to make a wanna be controller, that will be functional for the UH-1H and Mi24P doorgun position. (hoping it will work for SA342 minigun variant and ch47 Chinook in future) **UPDATE** 07.26.2023 Eagle Dynamics added joystick binds to the Mi24P doorgun, so this build is working The minigun build is a blast to use, but agony to build. Trying to make this a fun project! ***NOTE**** if you plan to incorporate a bass shaker, you should add a relay to the trigger circuit, else any butt kicker out put will go to the shaker regardless if you are pulling the trigger our not, butt kicker wiring diagram TBA LINK TO STL FILES Spade Grip assembly https://www.thingiverse.com/thing:5863116 Top Gimbal Section https://www.thingiverse.com/thing:5927492 Gimbal Base Section https://www.thingiverse.com/thing:5932560 DCS Axis Controls and Button Assignments mappings: axis doorgun slew LEFT/RIGHT, axis doorgun slew UP/DOWN VR Re-center Fire Weapon Move Camera View Right Move Camera View Left Move Camera View Up, Move Camera View Down Move Camera View Forward Move Camera View Back Radio PTT List Parts (so far) : 2x M3-20mm screw (switch housing) 4x 1/4-20 x 3/4" bolt and nylock nut (mounting grips to c-bar) https://www.amazon.com/gp/product/B0BLKSYV3M/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1 1-1/4 in. x 2 ft. PVC DWV Sch. 40 Pip https://www.homedepot.com/p/Charlotte-Pipe-1-1-4-in-x-2-ft-PVC-DWV-Sch-40-Pipe-PVC-07100-0200/202018045 1x Cytron Arduino Pro Micro Compatible w/ Pre-soldered Headers (to be used with mmjoy2 to be programmed as windows controller) https://www.robotshop.com/products/cytron-arduino-pro-micro-compatible-w-pre-soldered-headers?srsltid=Ad5pg_FU8fbJVsHuWKCVgksU0nf4NqHeFxScMWDMW16LZgnUgTfwnzaJa0w if you do know how to program arduino use leo bodnar Bu0386 http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=94&products_id=204 or Leo Bodbar USB controller board http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=94&products_id=204 4x 6805-2RS Deep Groove Ball Bearings 25mm Inner Dia 37mm OD 7mm (for the potentiometer U-joint) https://www.amazon.com/gp/product/B082PYT33D/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 12mm Momentary Push Button SPST https://www.amazon.com/gp/product/B07YDGVZ9B/ref=ppx_od_dt_b_asin_title_s00?ie=UTF8&psc=1 HDPE Sheet (to make the grip brackets..) https://www.ebay.com/itm/144548391463 2x paddle switches (to adjust the VR player view) https://www.ebay.com/itm/182340027352 1x limit switch (very snappy) https://www.ebay.com/itm/372481343091 Brown filament (to print grips) https://www.amazon.com/gp/aw/d/B0B2NZM21Z?ref=ppx_pt2_mob_b_prod_image brass inserts M3, M4, M5 (you will need a solder iron to install these) https://www.amazon.com/Hilitchi-Threaded-Embedment-Assortment-Projects/dp/B07VFZWWXY 13mm Momentary Push Button https://www.amazon.com/gp/product/B08B1P43XY 65mm bearing for gimble base https://www.amazon.com/dp/B082PWXCX9?psc=1&smid=A1THAZDOWP300U&ref_=chk_typ_quicklook_titleToDp Diodes (to eliminate ghosting inputs) https://www.amazon.com/Projects-1N914-Diode-General-Purpose/dp/B08MDGGCL5 STEP ONE (PREPARE GRIP ASSEMBLY) 1) print grips and grip covers 2) use a solder iron and mount brass threaded inserts ( M5 insert for the grip covers, M3 inserts for the grip tops) 3) print switch housing, then install the temco limit switch and connect the two halves of the switch housing together. use M3 x 20mm screw to keep the housing together 4) mount brass inserts M4 size for the switch housing 5) print Front panel and trigger lever. mount M3 insert to one side of the front panel where trigger lever will go 6) add compression spring (size 9.52 x 19.05) to trigger lever and screw down to the front panel 7) install 2x 1/4-20 nylock nuts to ends of the grips on the inside, for both grips. 8 mount grips on to the C-bar ***note: grips will have a through hole on the top- purpose to channel wires through. And there are two C-bars, with different size holes at the middle, pay attention when installing the grips, if incorrect, the housing will be upside down 9 install M5 nylock nuts inside the body frame. 10 Mount body frame to the c-bars with 4x M5 x20mm screws 11 solder 4x 12mm buttons with diode and wires. Also solder diode to toggle switches. Attach buttons and toggle switches to grip. 12 run wires through holes at top of the switch. And then channel wires through housing body. Leave slack / extra wire to later connect to gimbal 13 connect pvc pipe to housing back plate with M4 screws.

I just did some fuel consumption tests over 20nm at about 100kn, results are as follows: At max throttle it consumed a bit under 300 pounds. At idle throttle it consumed a little over 200 pounds. Worth noting is that I did not refuel in between tests but I doubt it would lead to a considerable difference. Would love to know how this holds up to real world data.