FusRoPotato

@Toumal@Grimm I noticed this doesn't offer kill messages for direct instant-kill hits, such as from laser guided APKWS, but seems to work really well for splash damage from slightly missed dumb bombs. Was wondering if either of you have played around with this script since? Not sure if there might be a timing conflict between the weapon and the created blast? Or is this something where only Moose can reliably score from?

No, the problem still exists for both vikhr smoke and looking through exhaust via FLIR on the Harrier. However, I found a temporary fix by installing a mod, V19 MP version by @Taz1004. Personally, I'm not sure I'm in favor of some of the new effects, but the framerate is much better for the Vikhr. In fact, completely fixed. However, it is unchanged for the Harrier exhaust in FLIR. I suspect he didn't change IR smoke effects at all.

You guys should probably ease up on disrespecting your own members, also making misguided assumptions about matters while evidence suggest otherwise. Neither is an effective way to defend the hard work put into these modules. Some of us have been engineering aerospace systems and components for decades and know a thing or two... Why not just forward the concerns to the relative individuals and leave assumptions out of it?

It doesn't matter what frequency the VHS recorded at. If the recording shows 1-1 time scale and the HUD components shift at 30 Hz, then the HUD update rate is equal to or greater than 30. Sure it doesn't prove it's 60, but it proves 20 is wrong. Your F16 has color MFDs. Those didn't come until 1996, therefor MIL-HDBK-87213 applies.

Yea, poor Tomcat. I don't know about 4 fps though. IIRC they had a refresh rate of 30 for the screen itself and an update rate of about 8 Hz for the bearing tape, vvi, and pitch ladder. It depended on the source of data and how much load was on that source, plus they went through a series of upgraded that kept improving on that performance. Some things like bank and the data input from AIM-9's however would come in at a much higher rate, so you could have this mix of things looking both smooth and jumpy at the same time. I trialed the F-14 for a bit but never took the time to really look at the HUD and see if the game represents reality or not. Spent most of my time trying to figure out Jester's IQ, but I've seen enough complain about update rates to know they tried to recreate it to some extent.

There is no way separation will result in an instantaneous change of yaw rate. It makes absolutely no physical sense, and to hear it was intentionally designed this way from an operations manual is not a good point of defense. What you should expect is an immediate effect of wing drag and possibly turbulence across the tail during separation producing a yaw moment, not an instantaneous yaw rate. Furthermore, it will be a weak one because of how small the aspect ratio is vs its yaw inertia. Here is an example step by step of the expectation: High Angle of Attack A wing separates, let's say the left wing Left wing loses lift so it begins to roll left At the same time, a small left yaw moment is introduced, but it is weak because the ratio of AR to INy is very small. By the time it rolls 90 degrees, almost all of its original angle of attack is now sideslip, but some sideslip was lost because of the yaw moment. Now there is a strong yaw moment due to sideslip. it begins to yaw more strongly until it reaches peak yaw rate at zero side slip If allowed, yaw will oscillate and stabilize, but intervention can either allow early correction, or even greater difficulty regaining control. In the FM I saw: High Angle of Attack Instantaneous yaw rate that makes no physical sense and would probably kill a pilot if it really happened. Clearly there is a major conceptual error there, as if this reaction was scripted. This was almost the first module I ever bought, but I skipped it for this reason alone. Actually, it was the defense of it that struck me down. Of all the things that have killed Mig-21 pilots, can you guess what none of them ever died from? There were over 11,000 of these aircraft built. Should be easy to find one video of this happening IRL.

I've been noticing that the refresh rate of the HUD overall is really low. I've measured that the HMCS updates at 60 and the HUD updates at 20. I'm not sure if this is a graphical issue or not because some other modules I have show 3D object animation also playing at 20 Hz (like doors and panels opening/closing), which is strange to see when the rest of the game animates at 120. I've come across a small number of references that say the HMCS supplies a 60hz refresh rate to the pilot, so I have no quarrel there. However, the HMCS is not responsible for drawing the HUD, but it's a piece of hardware I can find specs on. While this means nothing regarding what the HUD's rate itself should be, I know for a fact something's off because one of the components of this rate has a SPEC requirement. All data sent to these devices to be displayed in numerical form are spec'd to display at an update of 4 Hz for readability per a MIL SPEC unless direction is changed, in which case it will update no later than 12ms later and the refresh rate following it is rephased. So for example, if you are holding near perfect altitude or velocity and the value bounces back and forth, you could visually see a high refresh rate "flicker" values, but in continuous decay or increase, it will only update at 4 Hz. However, in DCS, if appears like entire package updates at 20hz including bearing tape, target boxes, and VVI, components that were mandated to update visually by at least 60 Hz minimum in the mid 70's. Additionally, all numerical values are updating far more quickly than they are supposed to. I could try to measure that to be accurate, but no point really because it's obviously not 60 or 30. Examples of this can be found on any YT video of a DCS F-16 by counting frames using <> keys and I linked one at the bottom. This obviously can't be proven with YT videos of RL HUD tapes uploaded at 30 fps, but 30 is still far better than 20 and I also linked one of those below. What I can't seem to find is, what the update rate of the HUD is supposed to be. I suspect it either has to be 60 or 72 but can't find design specs exactly, but I see a lot of suggestion it was also mandated shortly after the F-14 due to performance studies, requiring it to be 60 Hz minimum. This doesn't necessarily mean the bus feeding the HUD with data had to be updated at 60 Hz, but we do know it's interpolated with the F-18's HMCS to display smooth motion at 60 Hz when receiving data at 20 Hz, similar to the F-16's HMCS. Is this something that I can fix with a graphics setting? Is it just an early development hitch? What is the HUD refresh rate supposed to be and how do you know? References METRIC (aerospacelightinginstitute.com) Using Helmet Mounted Displays to Designate and Locate Targets in the Urban Environment (tennessee.edu) MIL-STD-1553 Designer's Guide (milstd1553.com) In the above video, numerical data updates at 4 Hz, while everything else updates at 30. However, the video itself is only 30 Hz so a 60 Hz display would not be seen. I just realized the previous video was from a bit of a newer model F-16, so here's a much earlier Block 30 showing the same measurement. In the above video, some (not all) of the HMCS components update at 60 Hz but the HUD only updates at 20 Hz. Careful when measuring in this video because there are slo-mo sections that will give smaller results.

Ok, standard FOV may vary person to person, but at just a mile away, this helicopter vanishes at some FOV around 70. I don't know how to exactly measure that. At 1080p, the helicopter doesn't completely vanish, but will change from being a 20 pixel object to a 1 pixel object. At higher resolutions, it appears to go from a 30 pixel object to a zero pixel object. No form of labels, dots, or anti-aliasing being used. If it matters, I'm on a GTX1080 with a 5800X3D and 32 gigs of ram. Zooming in will make it appear again so I can make it poof in an out of existence. It's a busy week for me, but I was planning on making a test mission tonight that has all player controllable aircraft lined up in distant rows to see if this affects anything else, but I suspect only the AH-64 for now. Other helicopters/planes seem to appear fine this patch, but I know that wasn't the case in earlier versions of 2.8. I have cleared fxo and metas for testing.

Do you know if it's possible to export axis inputs from control sticks and mini sticks from the export.lua?

For example, local pitchCommand = reference to whatever stores JOY_Y or the total sum of all control inputs that affect pitch I'm playing around with exporting a lot of data to try my hand at some Arduino projects. I've been able to figure out how to get everything I need, except this. Axis inputs. I'm having a hard time figuring out via the control lua files how to reference that, especially from what the game accepts as input, not necessarily from a specific device. I want to be able to store a history of where the game thinks the stick was for graphing, but I'm not sure how to reference whatever sets those values from the controller. All I could fine was how to overwrite them: LoSetCommand(2001,0) or iCommandPlanePitch

I don't know if a track would help. It's not just a problem on the BS Shkval. It seems present on any targeting pod zoomed in with a tight FOV. It also appears present in external view when zoomed in really far. Flashing triangle like shapes where the ground and objects are slightly brighter or darker. Probably a general graphics issue that has nothing to do with this module.

Someone correct me if I'm wrong. Your INS system measures your position. It then uses your camera's angle and range finder to determine the targets location based on your INS location. SO, no matter how badly your INS is aligned, target heading hold should always work. So somehow, our targeting system is determining the true exact location we're selecting, and our autopilot is then using the misaligned INS system to turn to where it thinks our target is, which is somewhere else apparently?

It has to be a bug then, because an INS calibration issue shouldn't cause that. If you pick a target at a specific GPS location, how does your targeting system know the real GPS when your INS doesn't? That's the only way they could be misaligned, is if they have 2 separate alignment systems fighting each other; one that's correct and one that's not.

I don't think it has anything to do with INS. Shouldn't matter at all, even if your INS is off. Any offset of bearing drift in your INS will also be present in your target vector, meaning that even if your bearing is off, your target will be off by the same amount. You should still be lining up with your target vector regardless of what bearing it thinks it is. I think the actual issue is overdone yaw stability. Notice you can't fly this thing sideways at more than 10km/h without really fighting yaw. It's hardly realistic. That vertical stab barely overcomes the body frame instability and should not be yawing like that much in sideways translation. The target heading hold is probably being shoved off by wind forces during a hover because the flight model is simply too strong in this respect. At least, I've only really been noticing it on servers with wind. I've been getting the feeling this is the case for a lot of the moment coefs about this helicopter, they just seem too high in general, easily by a factor of 2. Not an uncommon mistake across a lot of DCS modules. On top of that, there's no apparent compensation for lack of FFB modeling being translated to reference neutral points. You really have to hold the stick and pedals at extreme positions despite requiring force to do so, when an appropriate compensation is to have the neutral point mapped back to center point of a stick for non-FFB PC hardware. Would probably feel a lot more natural like that, even though neutral points don't usually describe neutral moments.

I hopped in trying to find solutions to a similar problem I've been having, only it seems to only affect helicopters. I can spot ground vehicles and distant aircraft just fine (at least I think I can), but helicopters pop out of existence if they are > 1nm away and I'm not fully zoomed in. I use the Z axis of my head tracker to zoom, so I can just barely zoom in and out repeatedly and watch helicopters appear and disappear. This is a problem because 1nm of draw distance on helicopters is really bad and I don't know if it's a bug or if I can change a setting somewhere to fix it. This has only been happening since 2.8.

I still see it. Looks like two flashing triangles. Don't know if this is a ka-50 bug though because I sometimes see it on other screens on other modules. null

Seems to break when the mouse is being used to control view angles. Otherwise, it stays locked in the window just fine while the mouse controls a cursor.

The vibrations generated are small, but if they are harmonically absorbed by the tail or pylons, they could absolutely shake like crazy. The thing is, harmonic modes are dependent on RPM and the structural properties of the pylons and the weight they carry. They have to match quite closely. Any change in RPM or weight of pylons could inhibit that vibration completely. This can vary a lot between models of helicopter. If it is present on the Ka-52, it might be present on the Ka-50 for a specific loadout/RPM, but is it? It may be a very similar aircraft, but it doesn't take much difference to avoid harmonics. What I do know is that these vibrations won't only be present at slow speeds beyond zero. They will be present at most all speeds, including hover and cruise, until RPM is changed or weight is dropped. The behavior of a helicopter shaking as it comes to a stop, or starts moving from a stop, is characteristic of a single rotor due to a phase shift during transition through transverse flow. It is a roll and yaw shake that contra rotating blades cancel out and turn into a z-shake that's far less noticeable. After doing some digging into those videos you suggest, it does look like they are overloading poorly maintained aircraft.

Yes, 3 bladed contra-rotating blades have a very elegant geometry of forces that nearly cancel each other out completely, except in one mode (z-direction). I put about 8 years into wind and water tunnel research on the effects of contra-rotating blades with variable geometry and separation in extreme sideslip conditions. We've even tested configurations nearly identical to the Ka-50's, though much smaller. The inertia, gyroscopic procession, torque, phase lag shift vibration modes, and p-factors are essentially flat or canceled compared to a single rotor, so long as the rotors have 3 or more blades. The question I mostly looked into was, to what degree of diameter and collective variation patterns produce vibrations, noise, and performance/efficiency costs. The magnitude of total vibration is about 95% less in the worst cases, typically when the upper rotor has a smaller diameter than the bottom or the separation is excessive. The type of vibrations caused by those factors are usually out of phase, not completely destructive (destructive phase is good), and usually reside in the pitch direction. However, they are hard to measure because of how small they become. The vibration we are seeing in the DCS Ka-50 is what you expect from a single rotor because of the speed regimen it shows up at. It's typically jarring because the vibration is angular. In a contra-rotating configuration, those angular vibrations are destructive. On the other hand, the translational vibrations due to phase lag are small but additive. In addition to that, there are also Z-bound vibrations arriving from blade-passing. This would usually not be a problem, maybe hardly even noticeable because the lift variation to inertia ratio is ridiculously small. However, if you have some structural bending modes (tail or pylon) or wing-mounted weapon somewhere that offers a harmonic response, it could grow and become quite noticeable. It's a very small up and down vibration that is more-so continuous across a higher range of speeds. The flight model of the Ka-50 in DCS feels invented. I assume it either came without experience, or it was copy/pasted from a single rotor and roughly hacked to fit. That sounds reasonable to expect when it comes to simulators because that's just a really common thing that happens. I suspect the latter because of how the Ka-50 banks at higher speeds, or pitches when trying to make a tight yaw at speed. These again are another set of effects you'd only expect with a single rotor. I was really disappointed in the flight behaviors when I got this module. I'm hoping we will see some improvements in the BS3. Please continue modifying it to completion. A Ka-50 without a close approximation to its flight model is like a Raptor without stealth, or Hornet without a hook, or a Tomcat without a radar.

Smoke pods and fuel dump should have been hotfixed last patch, unless there's still an issue with it.

It seems like not all smoke effects are equally impacting FPS. Some of them were causing server crashes on 2.8's initial release, and some are causing major tanks in framerate. I can look through smoke of some missles, and smoke of some exhaust without any apparent problem, but looking through exhaust with FLIR is a huge performance killer. I crashed an AV8B yesterday when my TPOD looked through the tail. I was heading for a mountain and the game nearly stopped responding altogether. Next thing I know, I've made a crater.

Yeah, after a bit more digging, I found complaints of this problem more than 5 years old. I'm shocked honestly. I thought overdraw was a globally solved problem back in 2002. I wonder why it triggers with some smoke effects but not others, like smoke generators, fuel dumps, or ground signal smoke. They don't seem as impactful, if at all.

Whenever the view is filled with smoke from rockets, missiles, or plane exhaust (including looking backwards through a targeting pod with FLIR on), framerate drops massively to a point of being unable to control the aircraft. This does not appear to be the case for ground smoke. Typically I fly around with minimized graphics settings, netting between 100 and 120 fps on average. When these smoke effects come into view, or show up on the lightning pod in such a way it covers most of the view port, this framerate drops to 3-5 fps. 8700k, 1080gtx (526.47), 1080p res (min settings), 32 gigs 3600 ram.

I've been experiencing that. It keeps trying to turn off course and bank to the side a lot. When this happens, what do you see on your attitude indicator, your HSI, and RMI? I got stuff twisted in all sorts of silly directions like alignment goes bad soon after takeoff. I'm trying to read up on the alignment procedure now to see if there's something wrong with easy start, but I don't know yet. It's not any different with the basic cold start procedure.

I just got this copter from the sale, so I'm still trying to sift through all the manuals, but I can't figure out one issue that crops up often. Heading hold keeps trying to spin me in circles. I don't mean general fighting, I mean if I leave it alone, the chopper will spin in complete circles repeatedly. It does it while in a hover, or while trying to fly to a mark, but not when I have heading hold off. I've tried adding in auto turn and marking a point with the HMD, resetting the HDG HLD, the heading and track switch, the gyro switch, and the descent and route switch. Regardless it will just spin. Reslotting, rejoining, no wind, not sure. Sometimes it goes the opposite direction when I use HDG hold and auto turn at the same time. The gyros are not showing the correct headings and are off by a lot and get stuck. I figure something wrong with the gyro. Is there a fix? Is this a 2.8 thing because I can't find much discussion about it.