Rifter

Yes - no undervolting or overclocking can solve that typical DCS problem. What I had in mind were those strange VR performance issues which are not explainable from being CPU bound or having too ambitious graphics settings. Should have been more precisely here. Thanks a lot for your contribution anyway!

The community member speed-of-heat as a neatly worked out guide for VR users. https://forums.eagle.ru/topic/257819-my-3090-settings-for-my-g2-271/ Coincidentally he has the same GPU model as I (EVGA 3090 XC3). He uses an overclocking curve to keep his card over 2 GHz @ 993mV when I interpret his curve correctly. Being around 1V is definitely not the sweet spot for any 3090 out there - that is actually pushing the pedal to the metal. I his case it seems to work so nothing wrong with it. However when I overclock my card to 2 MHz my system sporadically creates frame rate spikes due to small variances in GPU clock speed which again seems to influence the VR frame rate. What I did instead: I keep my GPU around the sweet spot (in my case 837 mV @ 1830 MHz). As a result I lose around 200 MHz of possible clock speed but also gain absolutely constant frame times. No more erratic stutters in VR. I could not find any disadvantages because of not having the max clock speed possible on my GPU. As a side note: The graphics engine of DCS does not create a huge wattage draw in VR - it’s only around 220W in my case. Now for your question: I use MSI Afterburner as undervolting tool. It can be used with any GPU brand. You can easily choose a specific voltage point in the curve editor and fix your clock rate to that voltage. As a conservative starting point for a 3090 you can use 875 mV @ 1845 MHz. Lots of guides out there for the usage of afterburner. The curve editor of Afterburner is not very intuitive because of it’s poor UI but it only takes a couple of seconds to set up a specific curve. When you are familiar with CPU overclocking in the BIOS then that will be a piece of cake for you - much more easier than CPU overclocking. The final result depends on the specific binning of your GPU aka silicon lottery. Mine is only mediocre so YMMV. It seems that a lot of people are overestimating the benefit of maxing out FPS on their cards. Especially in the case of the top tier nVidia Ampere cards. And for VR it is not primarily about FPS - it’s more about frame times as well as frame time variance. Hunting for FPS is only a thing when you don’t have any overhead for your required minimum frame rate. But then it’s probably better to reduce settings before you max out the GPU.

I have been testing a 3090 and a 6900xt in the last weeks on my rig - was running a water cooled 1080ti before (the system itself is an Asus Z390 Maximus Gene with an overclocked 9900K and 32GB kit of DDR4-3600 with very tight timings). I tested both a Rift S and a Reverb G2. During my testing I made the following observation: Either letting the GPUs doing their job in the out-of-the-box configuration or alternatively overclocking the GPU manually created in both cases a tendency towards stuttering and very pronounced frame time spiking for both vendors though the green team doing significantly better here. This was very surprising for me since I used the identical graphics settings I had for my 1080ti which didn’t show any stuttering. I expected those settings to be a piece of cake for the flag ships cards of team green and red. So I started to play around. Fixing the clock rate by a defined voltage (aka undervolting) on the 3090 eliminated all frame time spiking and stutters. On the 6900xt it helped a lot to prevent the GPU from using the out-of-the-box efficiency behaviour (which is very aggressive on RDNA 2) by forcing it to stay within a defined clock rate speed (when the CPU struggles with filling the draw call pipeline Big Navy seems to drop into a short power saving sleep). The difference to the out-of-the-box behaviour is basically one thing: The GPU doesn’t boost anymore. And the boosting process itself seems to be counterproductive in DCS VR. Looking back to my old GPU this somehow confirms my observation: My 1080ti had several manually optimised voltage curves which I made for specific applications and saved as profiles in afterburner. One curve was exclusively for DCS and it definitely never let the GPU go into boost. Since I don’t want to generalise my experience I would like to hear some more voices here. Anybody here with a similar experience? Since heavily overclocked and maxed out GPUs are not uncommon for VR users - anybody with stutters in VR (and an overclocked GPU) willing to try an undervolting approach and report his results?

All theory about Vulcan induced advantages of an AMD GPU is destroyed on the practical VR side at the moment - actually by AMD itself with lots of help of their own AMD LiquidVR™ technology. I’ve tested a 6900xt and a 3090 on my machine with a Rift S and a Reverb G2. The 6900xt cannot implement it’s full pancake-power in the VR-world at the moment, especially not in DCS. It’s not that there would be a big difference in pure FPS, but AMD GPUs are extremely prone to frame drops because of high frame time variance and a bad ratio of low and high frame times. That is poison for VR. As a remark for 6800 or 6900 owners struggling with stuttering in VR: I used the MorePowerTool to deactivate DS_GFXCLK, DS_SOCCLK, DS_FCLK, DS_LCLK, DS_DCEFCLK and DS_UCLK and raised the minimum voltage for GFX and SoC by 25mV. This helps a lot with the technical disadvantage of the AMD hardware scheduler when the CPU struggles with filling the draw call pipeline which sends the GPU into a short sleep. By the way - that other flight simulator which switched to Vulcan some time ago cannot shine on the 6900xt on my side. The 3090 is superior here too. As a member of team green for many years a would have loved to switch to the 6900xt because it’s really a great card. I tested the reference design - it’s well build and running on an unbelievable low noise level when maxed out. The 3090 I could get my hands on is an EVGA XC3 and it’s loud and power hungry and 2 x 8 pin only power design. Honestly not the best choice for a 3090 variant. Believe it or not: I was able to run the 6900xt out of the box with a Seasonic 600W fanless PSU! But there is still a lot of headroom for undervolting since the GPUs of the 6900xt are binned. Efficiency is the strong point of AMD GPUs. I managed to undervolt the 3090 to a level that it could also run with a 600W PSU. But then it’s definitely downgraded to the level of a 3080. The advantage over the 6900xt remains on the frame time and frame time variance side. Technically it’s a 3080 with 24GB video memory now. I will keep the 3090 and will water-cool it.

Keith "Okie" Nance once said, the F-5 could easily be beaten by a Piper Cup or a F-172…but he did admit it was a fun jet to fly. He especially highlighted the easy and effortless operation of the F-5.

There is a very old script done by MBot: Though being from 2013 - it still works: Infantry stops returning fire for a certain amount of time after being fired at by for example the door gunner of the huey. It can be included in every existing mission by simply calling it up once at mission start. Does not scare off infantry by flying close over their heads of course...but at least you can scare them by firing at them. Which as I understand is the deeper meaning of fire suppression...

Since the thread was bumped: My workaround from above does not work anymore since ED now prevents manipulations on the Huey module of the kind I used here. I did it wrong anyway, since the elevator movement on the real Huey counteracts the cyclic pitch movement rather than supporting it (what I mistakenly did with my workaround). As further observation from my side: In multiplayer the tilting elevators are still visible on the Hueys of other players - though not on the players own chopper when viewed from the outside - as already stated above by Heimz.

Exactly! And also the fact that the input devices feel different from their counterparts in the real thing. There is more to building a simulator than just hitting the correct point on the mathematical/physics side of your driving or flight model. In the transportation industry the basic situation for simulating accelerations is the following: The perception of accelerations is done primarily in the inner ear, the equilibrium organ (in contrast to the perception of speed which is primarily accomplished on the basis of visual and acoustic information). Because of the way the equilibrium organ works it is very good in sensoring the initial impulse of an acceleration. Whereas it is not very good in perceiving ongoing constant accelerations. In experiments pilots where seated as blindfolded passengers in an aircraft. The aircraft then flew different manoeuvres and the blindfolded pilots where asked to identify those manoeuvers. They where very good in recognizing the initial manoeuvres (like entering a dive or climb or roll). But they usually failed when for example the aircraft went into a sustained turn because their brains missed a certain rate of change of the acceleration. Here the visual information is crucial to actually identify the flight manoeuvre. For driving and/or flight simulators that means it is more important to have the initial impulse of an acceleration (synchronized with the visual information) than the level of acceleration itself. This is the reason why motion platforms are doing an amazing job towards immersion even when they don’t reach the G-force level of the real vehicle. Of course when the level of acceleration becomes part of the challenge itself (which obviously is the case for a fighter aircraft) you will have hard times in finding a substitute or surrogate for the real thing. Advanced research in this area goes towards putting simulated pressure onto the body with for example pneumatic cushions and blowing air into the ears with sophisticated methods to create a fake impression of acceleration. For the transportation industry there is lot of cost reduction potential for simulators in the future (cars, trucks, airliners) when it comes to minimize the technical effort by tricking the human brain rather than creating a technical/mechanical overkill by fully blown 6-DOF-platforms, especially in conjunction with VR-technology. Though for simulating fighter jets I’m rather sceptical - the technology to get rid of the pilots themselves will probably advance faster than the technology to simulate fast jets in a way you could not tell the difference to the real thing...

According to the English Wikipedia entry for the Mi-24 the Iraqi Army developed new gunship tactics for their Mi-25 because of the lack of anti-tank capabilities. With the help of East German advisors the Mi-25s would form hunter-killer teams with Aérospatiale Gazelles. The Mi-25s would lead the attack and use their massive firepower to suppress Iranian air defenses, and the Gazelles used their HOT missiles to engage armoured fighting vehicles. For further reference So all we would need is a Gazelle module in DCS to become a little creative with the MI-24 to overcome some of its possible disadvantages! Uh, uhm - wait…

I really like what you write there. Seasoned professional for numerical simulation methods in the automotive industry here. What you say reflects perfectly my own experience. Multi-million-euro car simulators are usually far below sim-racers for the PC when it comes to the driving dynamics side. But the goal of a ‘professional’ car simulator is mostly just to create a certain workload on the brain of the test driver while he is testing new control elements or driving assist systems. It is usually not meant for an accurate representation of driving dynamics behaviour of a car. Fun fact: The so called multi body approach for sim-racers is very similar to the driving dynamics simulation tools in the automotive industry - in sim-racers they are just optimised towards performance because there you need real time performance. The base for car simulators in the automotive industry is usually a ‘spread sheet’ simulation or in other words not more than a collection of look-up tables. For professional flight simulators it is similar. Civil aircraft (airliners) for example are never intentionally stalled - not for training and surely not for fun. Only test pilots do that during development. Usually stall does also not take place in professional simulators. Pilots just get the warning signs recalled as a training (warning horn, stick shake). Professional flight simulators which are capable of handling a so called upset recovery of an aircraft are at their very beginning: https://trimis.ec.europa.eu/project/simulation-upset-recovery-aviation Out-of-the-envelope behaviour of an aircraft in a simulation is the holy grail - it is yet to be developed. At the moment outside-the-envelope behaviour is usually just 'scripted' or modelled as a rough approximation. For the point of the “right-feeling" you mentioned: Imagine taking a real car or a real plane and equip it with a remote control system and some cameras. Show the camera pictures on pc-screens and add a gaming steering wheel or a gaming yoke or hotas. Take test persons (professional test drivers and test pilots). Tell them what they see is a simulator. Ask them how good it is. They will most probably say something like: It’s not bad but it’s clearly just a simulation. Does not feel like the real thing...:smilewink:

Just to ‘hype’ this thread a little bit more for all you rotorheads: Nibbylot not only created the foundation for an OH-6 flight model. It is also a blueprint for at least any other helo which is included in the test data of the NASA document. That means the flight model could also be used as a starting point for a AH-1G since all the data for that bird is also included in the NASA document. A question for nibbylot: The aerodynamics data of the NASA document is so to say the data backbone of your flight model. You transferred the table data of the NASA document (page 26 and following) one-to-one into the file AH6AeroData.h. DCS has the particularity of swapped axes in it’s coordinate system (y and z are swapped compared to the ‘official’ definition in the aerospace industry). From my understanding that means that transferring data from an original source with the official x,y,z-scheme has to be adapted to the DCS coordinate system. CptSmiley did that in his F16 flight model too. He swapped the y and z axis data compared to the original source which he used as input. For example he did not just takeover the moments of inertia values as they can be found in the original source but he swapped the values of y and z against each other. In the file API_Declare.h the coordinate system is defined according to the DCS notation. Body coordinate system system is always X - positive forward, Y - positive up, Z - positive to right. Does that mean your flight model handles the axis swap ‘internally’ so input data of an original source can be used without axis swap? Could say some clarifying words on that topic? Thanks a lot!

On page 24 of the NASA-document which nibbylot has listed there is a table for the moments of inertia of the OH-6A. You can find the NASA document here: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19800002851.pdf Two weight configurations are displayed there: Nominal weight and light weight and their corresponding Ix, Iy, Iz and Ixz values. What’s missing in the NASA document are the moments of inertia for the max weight configuration. Besides the OH-6A the NASA document also contains the test reports for: BO-105C AH-1G UH-1H CH-53D I found similar NASA documents for the UH-1B and the UH-1C also. Usually moments of inertia values for vehicles (no matter if airborne or ground) are really hard to come by. @stromridersp: Sorry - haven’t found any AH-64 data yet.

There's a second video of that sequence from a front view where it says it's for a Xmen film.

Could someone please recreate this MI-8 footage within DCS… …and tell us how it ended up? :music_whistling:

Thank you BIGNEWY for your attention! Here is a workaround for the elevator movement until the final patch by ED. (For those everything-works-like-the-real-thing-nerds like me :)) Since the elevators are accessible by argument 15 in the model, the elevators can be coupled with the pitch movement by a simple script. Everything for the workaround takes place in the ../DCS World/Mods/aircraft/Uh-1H/Cockpit/Scripts directory. Make a backup of devices.lua and device_init.lua and place the new versions of them into the directory. Then create a new directory within /Scripts called SYSTEM. There you copy the files init.lua and ext_sys.lua. The changes to the original files are documented by comments 'workaround device for synchronized elevators on tail boom' for those who are curious. Now the elevators move synchronized with the pitch. Not sure about the deflection on the real huey. But you can increase the deflection by multiplication of the pitch value in the ext_sys.lua file for example by 2: set_aircraft_draw_argument_value(15, pitch*2) Not tested in MP for integrity check. Not tested in beta 2.5.6. devices.lua device_init.lua init.lua ext_sys.lua

According to Wikipedia the conversion of the Gazelle was done by Cinema Air in Carlsbad, California. That is just partially true. They only organized the creation of the helicopters. The actual conversion from the Gazelle to ‘Blue Thunder’ was done by Hughes Helicopters. In that way the air worthiness could be fully maintained. Two flyable models were made. Both ended after their movie career in the aviation salvage business being scrapped and sold for parts. Non flyable mockups and parts of mockups survived over the years, some in the hands of enthusiasts. Stating that the Blue Thunder helicopter ’could barely get off the ground’ is not exactly true according to the pilots who flew it for the film. Being a bit nose heavy it created some pitch moment. Besides of that it was very well flyable. Which was absolutely necessary since the special thing about the movie is the fact, that a lot of real helicopter flying was done. In contrast to the F-16 scenes which were rather poor since they only had radio-controlled models for that.

When doors are closed the retractable seat armor rests in different positions for left and right pilot. Left pilot has fully extended armor, whilst right pilot has only half extended. Very prominent when switching places left and right and looking out of the door window. Is that intentionally? Very dangerous for right pilot when being shot at... :huh:

Actually they are not synchronized to anything - they don't move at all. Has been broken at least since 2.5.3 maybe even in all 2.5.x versions. Was working perfectly in 1.5.8 though... Looking into the UH-1 model in ModelViewer shows that argument 500 (cyclic pitch) is not connected to elevators. Elevators have argument 15 and can be rotated manually in ModelViewer. Originally they moved together with the 500-slider. https://www.digitalcombatsimulator.com/en/products/huey/?SHOWALL_1=1 Flight control system The flight control system is a hydraulically-assisted positive mechanical type, actuated by conventional helicopter controls. Complete controls are provided for both pilot and copilot. The system includes a cyclic system, collective control system, tail rotor system, force trim system, synchronized elevator, and a stabilizer bar.

Some mods just take something generic as data base, others are explicitly modded towards the specific aircraft. Main problem is mostly getting your hands on real data for the simulated aircraft. You can for sure create feasible behaving SFM mods as the creators of the A-4 or the the MB339 have proved. I usually compare the SFM data of a mod with the SFM-database of DCS which is a nice collection of all in-game planes (also AI-only planes) and replace the data with that when the mod is just generic. For example Heatblur made a SFM model for their F-14 - it’s in the CoreMods directory. Still the differences in flight behaviour are sometimes more placebo than real. The SFM approach is very simplified after all. One quite sensitive data input are the moments of inertia - you usually find them in the config.lua file in the FM directory. Playing around with these has noticeable effect on flight behaviour. They influence wether your aircraft feels light weighted or more heavy. Play around with all values and see for yourself.

When you downloaded moduls for testing you perhaps noticed the latest DCS Updater 2.9.16.18 - it encrypts the DLL-Files. All of your Mods which make use of for example FC3 content are useless now. They still work in OpenBeta though… Say thank you to those who carelessly spread Mods including the IP of ED. I remember times when the Mod user had to copy the needed DCS files from his own installation which was usually tolerated by ED. The good news are: Mods which have their own stuff (flight models, cockpits, …) will still work.

Ok, finally this seems to be the thread where I can talk about it... I realised a variation of the oscillation depending on the DCS version on my side. Also a crowded scenery (other aircraft and helicopters) seems to influence the oscillation. To me it feels like a kind of input latency which seems to be related to the code side of DCS when a lot of calculations are going on (for example because of a complex scenery around you). I never dared to ask about this in the forum - because of the forks and torches ebabil mentioned…:D When 2.5.4 arrived, no subversion of the 2.5.4 branch worked for me. So I went back to the last 2.5.3. version. It was the only version in which I could pick up the Huey smooth and nearly without oscillations. It is actually possible to hold the helo without movement in the cyclic - just as it should be. A huge difference which is definitely not pilot or joystick related! Fun fact: I never updated since then because I was so happy with it. I’m fearing the day I have to update and lose that smooth Huey behaviour…

:doh: I should have thought of it myself! Thanks a lot for the clarification!

According to the NASA document the CG is somewhere around WL50. If the model centre lays at WL 83, there should be an offset of 33” downwards. 33” are around 0.84 meters, which means the line for center_of_mass in the entry.lua should be: center_of_mass = {0,-0.84,0}, Furthermore - since the y and z axes are swapped in DCS, the moment_of_intertia in entry.lua should probably be: moment_of_inertia = {446, 979, 1219, 50}, (CptSmiley also did that in his F16 FM compared to the original source). As a hint for all testers of this bird: The given moments of inertia do not represent the max load out of the chopper. For the little bird that would be 3,100 lb or 1,406 kg. The given values are for 2570 lb or 1157 kg. Besides of that: The OH-6 is a great Mod and I really hope it gets some attention from the community in terms of suggestions and improvements. Thanks, nibbylot. Appreciate your work!

I’m a bit confused by the ‘0,0,0’ for the centre of mass. If your model centre is in the rotor centre, and there is no offset to to centre of mass, the moment of inertia values would be about the axes through the centre of the rotor?

Was instantly able to pick up the bird and bring it into a stable hover. No curves for my controls - I use a Microsoft Sidewinder FFB as cyclic stick and a Hotas for collective. The bird is quite sensitive to pilot induced oscillations. It feels and flies like a nimble helicopter and shows a believable behaviour. Was instantly having a lot of fun with it flying through open hangars and curving between buildings. I hope the upcoming OH-58 will feel like that. Good job! Thumbs up - finally we have a basic helicopter flight model. This could be the start of a community project. Next steps could be adding an accented ground effect and some non-linear dampening around the axes to break up the ‘pure’ mathematical flight model into something more lifelike. In the entry.lua there are following lines: local FM = { [1] = self_ID, [2] = "AH6", -- name of dll center_of_mass = {0,0,0}, -- center of mass position relative to object 3d model center for empty aircraft moment_of_inertia = {446, 1219, 979, 50}, -- moment of inertia of empty (Ixx,Iyy,Izz,Ixz) in kgm^2 --128 } Questions: Can you give us a picture of the model with the position of the center? Is moment of inertia taken as input for your flight model? What else can a user change in your flight model by just editing a file without compiling a DLL?