Leaderboard

Мы не будем упрощать ни F/A-18, ни F-16, чтобы они "соответствовали" Су-33 и МиГ-29. Поддержка же упрощённой авионики отнимала слишком много сил от других задач, а с учётом того, что сильной и главной стороной DCS World как раз является точность и подробность моделирования, мы и решили от неё (упрощённой авионики) отказаться.

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.

@MAESTR0 Firstly, let me say thankyou for all your teams efforts - the general layouts of the airfields look pretty good and I can see the effort that has been invested to make the airfields less sterile. After a more detailed review, I do, however, have some concerns. 1. Many of your RAF fields have too many control towers. One was the norm. In some cases there were two where the airfield topography required it because of blindspots, or where one originally built was not up to the capacity required as the airfield expanded (which they often did as the war progressed). However, they were the exception, not the rule. From the screenshots provided, Tangmere, Ford and West Malling immediately jump out as being examples of where we have a surplus number of unprototypically placed Control Towers. If you would like information on where to accurately place control towers please PM me or @Fred901 as between us we have the data to help you get it right. 2. There should be no foliage (shrubs, bushes trees) within the perimeter track. This is an instruction laid down in Air Ministry Standards long before the war. It's just not a feature of Allied wartime airfields as they present a hazard to aircraft. Please omit them from Gravesend, Ford, Farnborough and Funtington. 3. There should be no concrete block paving on the runways/taxiways. Whilst large aircraft pans were certainly paved with large concrete blocks, taxiways and runways were not. Please adjust the runway/taxiway textures to reflect this at Tangmere and Farnborough. 4. There is a lack of dispersal points and blast pens on some of the large airfields. Tangmere and Ford had provision by 1944 to support 9-12 squadrons each of 18-20 aircraft - this needed a LOT of real estate dedicated towards parking spots for aircraft. These could be as simple as a small poured concrete circle, many of which were in evidence at these two airfields but are missing in your reproductions. So too the blast pens, these dating from pre-1940 and a very distinctive feature on many RAF airfields of the time. Please conside adding some of these in. All the above can be summarised in these annotated drawings of Ford and Tangmere respectively: The layout is 75% correct regards runways and taxiways but the areas where the hangars are is wrong by some margin. Also note the foliage and compared to period plans there's a dearth of places to park aircraft. Tangmere best displays the over-abundance of Control Towers and again, the lack of aircarft parking spots. 5. Incorrect hangar types. Please see my original post on this matter here. I do see a change has been made to the large hangar type being used throughout the RAF airfields from this: to this: But even this generic hangar looks little like any example on any British airfield. In addition, it's uselessly too tall! The only reason you'd have a hangar that high is because you were expecting to put a tricycle undercarriaged bomber sized aircraft with a very tall single tail in it, yet that framed glass full width transom window prevents any aircraft from utilising the height within - it doesn't make much sense. Please, please, PLEASE consider making an accurate 3D model of a single bay Belfast Truss instead; a 2 bay version is shown below: This would be FAR more prototypical for all the airfields shown and I wouldn't grumble if it appeared on other airfields in lieu of their actual hangar because at least it was of a period prototypical pattern.

wow someone at ED should really do something about this

Mosquito FB.VI Generic skin with full invasion stripes and variable bort numbers. You can edit the letters in the mission editor or the rearming window. Custom roughmets, accurate colors and markings. This should be useful on the Normandy map. https://www.digitalcombatsimulator.com/en/files/3329266/ Mosquito FB.VI 487 Sqn RNZAF flown by Group Captain Percy Charles Picard EG-F, who was killed in action near Amiens during Operation Jericho, when a FW-190 hit his aircraft and the tail section broke off. Custom roughmets, accurate colors and markings. https://www.digitalcombatsimulator.com/en/files/3329265/

I've added the Monolit-B surface radar for the K-300P.

Я не могу ничего констатировать - я тестер и работаю в рамках своих задач, хотя иногда и принимаю участие в выработке решений по игровому процессу. Если Вам интересно моё личное (подчёркиваю - личное) мнение по данному вопросу - то да, я как игрок-пользователь DCS World за исключение опции упрощённой авионики. Ну не наш это путь, не наш. Снимать проверку текстур террейна нельзя - тогда кто угодно сделает себе гладкую контрастную землю и будет расстреливать наземку. Ищите другой сервер.

De Havilland Mosquito FB.VI Night Fighter of 418 Sqn RCAF, TH-U named "Moonbeam McSwine" https://www.digitalcombatsimulator.com/en/files/3329264/

WIP of the DCS F-15Es avionics bays open: By Metal2Mesh (Twitter)

Salute, Having only recently started playing with the tanks in the Combined Arms module I discovered that I did not have any vehicle engine sounds in a large number of vehicles eg, the Abrams MBT, WW2 Sherman Firefly. So, I set about finding the cause. It turns out that this issue is caused by installation of certain mod planes and the sound file structure they use. The A4-E, Bronco and UH60 Blackhawk helicopter are three so far that been identified as culprits but there may be others. Planes such as the T-45 Goshawk and Phantom mods use a different method and they do not seem to be a cause. Ships also do not seem to be a conflict. If you discover an aircraft that is not included below, check the file structure and if it is the same as what I describe below, this same fix hopefully should work. When I set about finding the solution to this issue I contacted the development teams of the A4-E and the Bronco and a big shout out to 08jne01 Joshua Nelson from A4-E dev team who responded quite quickly with a fix. It was through this fix that I was able to work out how to transport the fix to other aircraft. I would also like to give a shout out to my squad mate DD_Sid who also assisted in getting this solution together. The fixes are very simple but do involve the renaming of one file and the editing of one file per aircraft (I used NotePad - other editors are available) so you may want to do a quick back up if you feel uncertain about editing the files. Please find below the steps required, as I say, if you have any other installed mod aircraft and still do not have vehicle sounds after completing these steps, check out the files and you should be able to replicate the changes I describe here on those. Please add a post if you do find another aircraft that this change works for. The fixes have been tested on 3 individual set-ups plus a server where the A4-E and Bronco are mandatory mods on our server (www.dangerdogz.com why not come and check us out, we are a fun group with no set rules about flying. We play DCS on Monday and Thursdays in the evening UK time from about 19:30 until 23:00 approx). We also fly GBS on Sundays and Tuesdays. Please Note I am not some coding guru so can not answer any questions other than what I have described below. These fixes were worked out via a desire to resolve the issue and a curious mind. Use the steps below for each applicable aircraft. I reiterate, this fix only applies to aircraft that use files within the "Sounders" folder. If you have an aircraft that does not use the files listed below and can fully prove that the plane still causes an issue for you, please let the community know. Testing Notes DD_Sid when testing has reported back that the engines sounds when flying the Bronco do not now seem as loud as before the fix and also lack sound bass resonance. If anyone reading this knows more about this (anyone from the Bronco devs perhaps?) and can contribute I am sure the community would be grateful. EDIT: Please see following post for solution to this issue. Fix Navigate to your DCS "Saved Games" folder. The default location will be on the "C:" drive under users and your name. You may have moved yours. When there, open the "DCS" folder. Open the "Mods" folder. Open the "aircraft" folder. Within this folder will be all the folders for your installed mods. You may also have some folders that relate to saved custom views for example. When these fixes were being tested on one of our squad mates he had a Spitfire folder and that was because he had saved his cockpit view. A4-E Open the "A-4E-C" folder. Open the "Sounds" folder. Open the "Sounders" folder. Rename the "Tools.lua" to be "A4Tools.lua" Open the "Aircraft" folder. Open the "Engines" folder". Edit the file called "J52P8.lua" with notepad or similar. Edit the first line which says dofile("Tools.lua") to read dofile("A4Tools.lua") Add a second line that says dofile("Curve.lua") Save and close the file. Bronco Open the "BRONCO V1.08" folder Open the "Sounds" folder Open the "Sounders" folder Rename the "Tools.lua" to be "OV-10ATools.lua" Open the "Aircraft" folder Open the "Engines" folder" Edit the file called "T76.lua" with notepad or similar Edit the first line which says dofile("Tools.lua") to read dofile("OV-10ATools.lua") Add a second line that says dofile("Curve.lua") Save and close the file. Blackhawk Open the "UH-60L" folder Open the "Sounds" folder Open the "Sounders" folder Rename the "Tools.lua" to be "uh60l_Tools.lua" (this reads uh'sixty' lower case L) Open the "Aircraft" folder Open the "Engines" folder" Edit the file called "uh60l_engine.lua" with notepad or similar Edit the first line which says dofile("Tools.lua") to read dofile("uh60l_Tools.lua") Add a second line that says dofile("Curve.lua") Save and close the file. Start up your game and hopefully enjoy the magnificent tank engine sounds!

As in the title. In the light of upcoming F-4 Phantom I kindly ask for EC-121D Warning Star (College Eye 1967 Mod) as AI I think these asset will be crucial. (As Well as TPQ-10 radar). Those planes served as AWACS (before these name even came to life) from 1954 to 1978 in USAF (and to 1982 in USN).

First, you're referencing an outdated version of the huey's manual, yours only has changes 1-18, afaik 1-20 is the most recent, granted I've only found one with 1-19. Second, I didn't use the operating speeds chart as a reference, I refuted it as a viable reference for the reasons you stated. It tells you the fastest you're ALLOWED to go, but not the fastest the machine can physically push itself. It cannot be used as a reference for the actual performance of the machine. Third, you're measuring against the nose pitot IAS, our huey has the pitot on the roof, so the inner scale is the correct one, not the outer one. So it should actually read 100knots at sea level, if not 101. Fourth, add more weight, at 9500lbs in a 100knot sea level 15C cruise, as per YOUR chart, you should be at about 29psi You won't be Fifth, "The shaft horespower equation, which good for approximating things, doesn't take into account all the various other factors that effect performance of the aircraft, so i'd be careful in it's use. It can definitely get you in the ballpark, but it's typically off by a fair amount." If the aviation engineers figuring this out by hand so that they can properly profile the load placed on the drive system say it's good enough. It's good enough.

Normandy 2.0 appears on last A-10C-2 Tank Killer video by Wags

This is our "cruise video" for the year long multiplayer campaign we just ended on the Syria map. Hope you enjoy!

Everyone keeps assuming this is the case, but as ED says below, they are not going to be combining these maps at any point in the near future. Modders don't have access to map making tools, so they obviously aren't going to be able to it either. The map is L-shaped so ED can continue selling their Channel map going forward. That is the only reason, because like you said, why would anyone buy the channel if Ugra did model it in their newer map. Once this new Normandy map comes out, we will basically have not one, not two, but now three separate terrain products, confusingly all focused on the exact same area that isn't relevant to the assets that exist in the game. I'm glad that work is being done on WW2, but I think people's frustrations with the general direction are mostly justified.

Okay, thanks for the reports. We're going to check the total FOV of the sight, in case there's a problem there.

Avionics Bay Open

More Modeling progress, started adding rear section parts to the canopy and cockpit, back plating, piping and mechanical.

I’m not offended the least bit, I didn’t start all this

Честно сказать, в случае ПВП сервера я лучше буду на F-18 в ливрее с красными звездами летать против таких же но с белыми, т.к. ГС3 vs кликаблы находятся в совершенно неравных условиях. Удалять ничего не надо, надо советские дорабатывать.

With the new F-15E + Mirage F1 + Apache + F-16 + F-14, the natural candidate is a Desert Storm/Desert Shield map.

Most likely!

I'll see your C-5 puking up a J-8 and raise you a J-8 over, presumably, California.

Can you notice the changes? Do you like this ? Multiple mfd monitors get useful now

We need this!

Wip

It's literally where the Strike Eagle made a name for itself. Looking forward to an Iran campaign, but there inevitable needs to be a Desert Storm campaign and also a no-fly zone campaign. Always loved the "Iraq '93" campaign from MicroProse's F-15 Strike Eagle III. Also, if Israeli variants are going to be released, would like the Syria map to be expanded to southern Israel/Gaza also.

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.

Please support me:

I posted this up on hoggit a few days back, figured I'd slap it up here for anyone fortunate enough to not use social media. This is a bruteforce method that will reduce the draw distance of all planes / ground vehicles etc, so keep that trade-off in mind. Open your graphics.lua file in the DCS config folder, find the line with all the values for your current view distance setting (low, medium, high etc), these values start on line 177. Find the "objects = {3000, 80000}" line for your current view distance setting, and alter the second value down from 80000 to your desired distance. I'd suggest starting at 60000 and see how it goes. This sets the distance in metres at which all ground/air vehicles start getting calculcations done for them, in the direction you're facing in a wide arc. Hence why looking in certain directions on busy servers can tank your frames despite nothing apparant being visible, as the CPU is choking on all those distant objects. Changing in-game settings never alters this value, so you have to do it in the .lua and probably re-apply it after each patch. You can drop it a lot more aggressively if you're doing rotor gameplay or you have a particularly old CPU, drop it far enough and spotting can become a problem however. If you're on VR or generally struggle with shadows performance currently, you may see a greater improvement.

Credit where credit's due, a lot of effort went into this report. Even after 7 years, It is important to challenge the developers work and not to take everything we see at face value. In the end it makes for better products and benefit us and ED. So Im intrigued about this report, but let the helicopter experts discuss. Hopefully someone from former BST can chime in.

We would need more turboprop civilian aircraft (ATRs, EMBs, De Havillands...) as they are operated by military agencies as well (United Nations, Coast Guards, Customs etc.)

1940's WWII detailed landscape is far different from the modern data that Orbx and FS use for their maps...

После Акулы топовые спецы по системам и коду набросились на Чинук и процесс разработки вышел на максимал. Когда будут новости не знаю. По приобретению железа важно не дождаться ухудшения курса или какой еще неприятности. Будущее малопредсказуемо.

I didin't know about this site! Thank you!

I have -7.5 both eyes and switched from Quest 2 to pico 4 and I had to buy again the prescription lenses. My advice is buy prescription inserts lenses and you will not regret it. In my opinion all VR headsets combined with wearing glasses inside them is horrible experience. I almost returned my Pico 4 to Amazon having the old Quest 2 still with me and being able to keep it in case Pico4 was bad. IT WAS HORRIBLE! And here is why: The glasses I wear and many others wear are square in shape and the lens does not fit over the headset lenses well. Basically the field of view is totally destroyed as everything around my glasses is not seen or not seen properly not only because of myopia but because there is no useful light path for anything around the glasses in the headset to reach the eyes. So everything that is around my glasses is gone. Also the glasses refraction plane is not aligned with the headsets lenses and screen as it is impossible to have the glasses placed inside perfectly even and symmetrically. And finally the cherry on top of this bad cake is that the glasses have a more or less IPD adjusted for your eyes... note on more or less... if you always felt you need to adjust to the new glasses for few days... this is one of the reasons besides the new changed dioptric numbers. So you have a natural IPD of your eyes in front of them you have a little different IPD of your glasses to which you are now adapted (and in these glasses don't stay aligned perfectly not even just on our noses without headset, inside headset is even worse) and in front o the glasses you have the lenses of Pico4 with the IPD adjusted either for your eyes or for your glasses or something in-between. The resulted light path is a total utter mess! So my whole hearted advice is buy lens inserts no mater you need to change them. You can even delay changing them if you happen to change glasses every year or so... I bought my inserts for Pico 4 from HONSVR. They were the cheapest (still are I think) and I received them extremely well made and packed. If the box was white and not grey I would have thought they are from Apple. This is where you can order them and I can tell you for me it was godsent as I kept my Pico4 and sold the Quest 2. https://honsvr.com/product/pico-4-prescription-lenses/ there is a picture with mypico4 and quest 2 lens inserts. Totally worththe expenses. Quest 2 were 100€ (from vroptician.com) and Pico4 50€ (from honsvr.com)

IMO, we need specifically a 90s Iraq for ODS scenarios. I do hope spherical Earth map will be able to alter specific landmarks based on date, but even then, Google Maps only launched in 2005. They probably have the images stored somewhere, which should make it possible to make a mid-2000s world, at least, to fit our modern aircraft selection. That could work for the 2003 invasion, but during ODS the region looked quite different.

Я за 15 лет ни разу не пользовался ни упрощённой динамикой, ни упрощённой авионикой. Это безобразие было в лок оне ещё. Для статистики.

Я ведь постом выше объяснил, почему. Вас лично может не устраивать этот ответ, но это именно так. Решение же на упрощённые режимы полёта и некоторые упрощения в кабине принимают соответствующие менеджеры проектов и эти опции будут видны в конкретных настройках каждого модуля (закладка SPECIAL). Вы ничего не "должны". Вы покупаете те модули, какие считаете нужным и интересным для себя и летаете-воюете в тех условиях, которые Вам предлагаются оффлайн и на публичных серверах.

That's comforting ... somewhat. I think. You'll excuse me for being a little jaded, though. If they sell, they'll lose the ability to fulfill that promise. "Even ardent supporters of the company were immediately skeptical that Facebook’s business model could rot the foundation of Oculus’ VR ambitions with invasive user-tracking and ad serving. To assuage such fears, Facebook, on behalf of Oculus’ founder, Palmer Luckey, promised in no uncertain terms that users would never be required to log-in with Facebook to Oculus headsets, nor would developers need to do so to develop content for those headsets. It was the day of the announcement of Oculus’ acquisition that Luckey took to the Oculus community on Reddit to offer explanations to angry supporters. “I guarantee that you won’t need to log into your Facebook account every time you wanna use the Oculus Rift,” he said in response to a Redditor asking if he could at least promise that much. Yesterday the company demolished that promise when it announced that it would begin requiring all new users of Oculus headsets to log-in with a Facebook account starting in October, and that existing users would also be required to log-in by the end of 2022 if they wanted to retain full use of their headsets. "

The only exception to the “no-foliage” rule would be the ALGs which by their nature were temporary and thus the surrounding terrain was not extensively cleared. St Pierre Du Mont for example has many aircraft dispersals in the surrounding hedgerows.

There is not even a proper manual and you are talking about a campaign... (and no, chuck's guide does not count)

nobody can answer that question here..

Time to share my execution. I used the Seeed Studio XIAO nRF52840 board with 4x tactile 6mm buttons, slider on/off switch and lipo battery 50mAh (21x8x4mm). The 6mm buttons are sufficiently perceptible under the thumb, they do not confuse when using. Rings are 3D designed and printed by me. All run on CircuitPython connected by Bluetooth. In my opinion Rings change the sense of using Leap Motion. Without Rings, I wasn't able to use the hand measure sensibly, it doesn't work with enough accuracy and sensitivity. Using the Fingers program sort of removes one of the degrees of freedom, and thanks to this sensitivity is no longer important, and the cursor positioning accuracy is sufficient. In addition, I made 6 buttons, this time on a simpler Seeed Studio XIAO SAMD21 board. They are connected via a USB cable and visible in DCS as an additional controller with 6 buttons. They can be programmed directly in the DCS, and using Modifiers greatly increases the programming possibilities. The whole thing is also programmed in CircuitPython.

I vote for a Gulf War map!