Search the Community

File under interesting, anal retentive modeling, less than top priority... Video: Luxembourg helicopter trims tree. Before takeoff, rotor clearly fully spun up, near complete absence of dusting and then sudden heavy dusting accompanied by audio change (collective pull?). This real life example may or may not be extreme: Again, almost complete absence of dust cloud until collective pull. Makes sense, only with collective does the heavy down wash starts. All helicopters obviously. Connect dust cloud graphics intensity to collective pull. Checked of course, landed on grass, in DCS ground dust cloud identical whatever collective setting. Update: Observed: Dust cloud graphics is gradual and proportional to (only?) rotor rpm. Fix: Make dust cloud proportional to BOTH rotor rpm AND collective setting. Ie max dust cloud at max rpm with max collective raise. But also max rpm with zero collective would result in minimal to no dust cloud as in video. Video deleted. Same video, cut for time(?) but still shows the point, no collective = no dust, collective = dust. https://today.rtl.lu/news/luxembourg/a/2306561.html

Sensing the gravity ie... Flown gliders in real life. Flying "fast" G load shifts are instantly and powerfully felt with even minute stick movements. I imagine feeling the G shifts operating the collective could be equally distinct useful input, especially while landing. Like sitting on an adjustable height chair and moving the lever. One continuously, subconsciously, feel and balance the G while approaching ground? Akin to riding a bicycle or flying planes, once trained, muscle memory replaces thinking actively about every move. On second thought this probably applies to cyclic as well (though not as much), while hovering if nothing else. A helicopter, in ways a plane doesn't, can quickly change direction in all 3 axis and the pilot "feels" the inertia.

В этой одиночной миссии вы, как пилот ЛА, выполняйте случайные задания авиационного полка выбрав любой имеющейся у вас в DCS ВС, не надо открывать конструктор и менять свой самолёт или вертолёт на желаемый. Особенности миссии: · Атмосферная озвучка: почти каждое действие пилота озвучено, что создает ощущение полного погружения в атмосферу работы авиаполка и серьезности происходящего. Детали: – На аэродроме вылета присутствует техника, живая сила союзника, суда взлетают и садятся, он живет своей жизнью. - Используйте БПЛА для подсветки войск противника. - 200 аудиофайлов: подлинные переговоры пилотов, инструкции по выполнению задач, голос работы диспетчеров, оперативного штаба, авиационного крыла поддержки. Только 30% из них были озвучены с помощью искусственного интеллекта, но с использованием высококачественных и реалистичных голосов. Остальные же были записаны реальными пилотами и другими специалистами, имеющие непосредственное отношение к ВКС. - Задания можно получить на стоянке ЛА аэродрома Нальчик, там же есть возможность их изменить. - Присутствуют, несколько видов заданий: «ОВО» – общевойсковые операции, «СЗ» – специальные задания, «БГЗ» – боевые задачи в горной местности. - Каждое задание уникально, повторений и похожих нет. - Что-то пришлось упростить, но только для полного понимания игрока игрового процесса. Правила игры: Чтобы воспользоваться радио меню, нажмите «/» на клавиатуре. В меню выберите пункт F10 Другое… и далее: - «ВЗЯТЬ ЗАДАНИЕ» — для замены или получения полётной задачи; - «Текущее задание» — для просмотра выбранной задачи; - «Запустить БПЛА» — для управления дроном откройте карту местности, кнопка F10, наведите на дрон и задавайте ему маршрут, техника противника будет маркироваться дымом красного цвета, код лазера 1113. - После выполнения задания вернитесь на аэродром базирования Нальчик. Чтобы пополнить боекомплект, воспользуйтесь ВП или любым аэродромом. - Вы можете сменить летательный аппарат через меню миссии, нажав «esc». При этом ваши достижения в выполнении задач останутся прежними. · Слушайте радиопереговоры и следуйте указаниям. · Отвлекитесь от суеты и погрузитесь в атмосферу событий. · Миссия считается завершенной после завершения задачи и посадки на стоянку ЛА Нальчик, взять следующую необходимо так же на стоянке ЛА Нальчика, остановив ваш «пепелац». От автора: Миссия идеально подойдёт для освоения выбранного Вами ЛА, сверх сложных, невыполнимых задач нет. Приятной игры и отличного настроения! В этих миссиях вы не будете чувствовать себя одиноким, всё двигается, кто-то общается, есть юмор есть и трагедия. Будучи внимательным и зорким, при выполнении заданий есть подсказки, например: найти автоколонну движущейся по шассе, по протяженности участка дороги по которой едет предполагаемый противник поставлены статические здания, объекты инструкторы … По всем вопросам, предложениям и пожеланиям пишите в комментариях. Я буду рад ответить вам, прочитать вашу критику или идеи. Эта миссия была разработана с особой тщательностью, и потрачено огромное количество времени, чтобы создать для вас, истинных ценителей нашего лучшего симулятора, настоящий праздник!

Who could share with me the UH-1H checklist for cockpit procedures and interesting tutorial videos to learn?

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!

Video 12/09/2024 = Talking a little about the project. Hello community, I present to you the first test of the UH-1H Huey cockpit. In this particular case, it is for you to observe and help me correct proportions and general shapes. Much of the work is based on photographs, and while I try to be as precise as possible, perhaps someone with real experience with the aircraft might notice things that need correction. Don't expect anything usable, just a white structure of the larger components of the cockpit. In the file, you will find a .jpg image with the steps to follow for installation (it may break the integrity check, meaning multiplayer mode might not work). Please remember to back up your files, and I am not responsible if you need to clean up the installation after use. You can leave comments here on the forum (but please quote me so that I get notifications). Thank you very much for your time. Best regards! ###################################################################################################### Hello community! Today, I want to introduce you to a project I started a few days ago. I'd love to hear your opinions and perspectives on it. About the Project: The main idea of the project is to update our beloved but somewhat outdated UH-1H Huey. As a 3D artist, my primary focus will be on updating the module's graphical aspects with new 3D models and textures (we’ll discuss the scope of these changes and their implications later). However, I don't rule out the possibility that, with the community's help, the changes could be more comprehensive. Considering that the Huey's flight model is excellent, and its systems are quite complete, any improvements beyond aesthetics would likely involve adding new weapons or features. Images (WIP): Progress So Far: Currently, I have partially modeled the Huey's cockpit. There’s still a lot of work to be done, but so far, I think it's looking pretty good. I've attached images of the work in progress. I managed to run some tests in the simulator with the new cockpit added to the old model, and it looks quite promising. I still need to figure out how to make the file changes through the "saved games" folder to avoid breaking the Integrity Check (IC), which I currently have no idea how to do. If anyone is willing to help in this area, your contribution would be more than welcome. -- We need to replace the file located at: "C:\Program Files\Eagle Dynamics\DCS World OpenBeta\Mods\aircraft\Uh-1H\Cockpit\Shape" named "Cockpit_UH-1H.edm" with a new file of the same name placed in the "saved games" folder. Project Scope: Regarding the project's scope, I envision several possible options. Over the past few days, I've conducted a series of surveys to gauge the community's reaction to the project. For now, the goal is the following: A completely free mod for the community that updates the cockpit with new 3D models, textures, and animations. There would be no new functionalities. We would need to find a way to include it as a mod that doesn’t break the Integrity Check. If that’s not possible, based on the survey responses, there would be little community interest in the mod (and therefore, not much reason to continue its development). For those who have installed the mod, the helicopter will function as usual, but with a significantly enhanced level of detail in the cockpit. For the moment, both the exterior model and the interior cargo area of the helicopter would remain as they are currently. Improves on those parts would cost lots of time for a free proyect. The Reason for the Project: Essentially, I usually do things out of pure enjoyment or whim. The Huey is one of my favorite modules; it’s easy to use, fun to fly, not too complex, yet you can spend quite a bit of time mastering it. Despite this, its graphics, especially the interior, are quite outdated. Therefore, a few months ago, I started thinking about updating its textures to the PBR format. This led to multiple challenges due to the way its UVs were created, preventing the proper use of an AO pass. So, I decided to start modeling the interior in 3D from scratch. Estimated Timeframe: There’s no ETA; this is a project I’ll be working on in my spare time. Other Possible Versions: For now, I would focus on the version we currently have. I’d love to be able to choose whether to add or remove the radar altimeter and the flare dispenser at will, to make it closer to versions used in earlier periods of the Huey’s history. I’d also love to add the option for side-mounted M60s without the external hardpoints, as used by Hueys in Vietnam. If I were to develop other versions, I would be interested in a "C" version with various weapon systems used during Vietnam. I’m not a big fan of glass cockpits, so I’m not interested in modeling more modern versions of the Huey. However, these ideas are more like "dreams" rather than concrete goals, and they would largely depend on community support (since beyond 3D art, aspects that require programming are not my strong suit). Conclusion: For now, this is all. I hope the project interests you, and that together we can build this improvement. I look forward to your feedback! Best regards!

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

Only happens ,AFAIK, in the Huey. Track provided. Playing "I Love This Job 4.1", (Which is totally awesome BTW!!!!!!). Doesn't always happen, but twice in a row just now. Not sure if it happens if I press "LShft+R", (Will test that), but it definitely happens when exiting the mission and click "FLY AGAIN"! I've seen someone else mention this problem, but I couldn't find that, so apologies if this is has been reported before. I've tinkered with the idea, that it is the "Autopilot" , so I tried to take back control, that didn't work though. https://1drv.ms/u/c/cd091d76c15ef0f6/EeXxh0JHh5lIuJCvFdiXrEUBVn4i287D50sLea5oWZl-sg?e=k5kNwx EDIT: Does not happen when you press "LShft+R", so my guess it's some sort of track "replay" going on.

Operation Mountain Gate by DCS Indonesia - Garuda Virtual Air Wing Dear @everyone We are excited to present *Operation Mountain Gate, a dynamic campaign designed for DCS enthusiasts. Set in the Caucasus map, this campaign focuses on *capturing objectives such as airbases, FOBs, logistics hubs, and key towns. Join forces with fellow virtual pilots to achieve victory in each mission! This campaign was meticulously crafted by our community and we would like to hear your feedback and comments! It was intended as a place for intermediate players to enjoy an engaging Dynamic Campaign experience on a light map (hopefully delivering an optimized experience). Features Include: Dynamic Campaign based on airbase capture and supply area capture, demanding coordinated Strike, CAS, SEAD and CAP efforts. CTLD helicopter transport system and ground units insertion. Points-based deployable AI air and ground units. CARRIER FLEET IMPLEMENTATION, with naval airframes available for Carrier Ops. <-- TRY THIS # Server Information: Theater: Caucasus Server Name: *Op Mountain Gate [PVP] | Dynamic Campaign by DCS Indonesia - GVAW * Server IP: *213.239.205.197:10302* Simple Radio Standalone IP: *213.239.205.197:5002* Mission Running: *24 Hours* Restart Time (UTC): *06:00 | 12:00 | 18:00 | 00:00* For more details on *Operation Mountain Gate*, visit our web https://gvaw.web.id/operation-mountain-gate-omg/ If you have any questions, find the complete information here https://discord.com/channels/312940365504184331/1302072262731497532 Join now and prove your skills in this dynamic battlefield!

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.

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!

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.

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.

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

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.

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?

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/

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

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

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?

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.

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.