SMH

Sorry. If you're arguing that we should be punished because other people aren't that bright, I'm not with you.

No fix for this in today's hotfix update? It's kind of a major issue. (Yes, we have a work-around, but most customers won't be aware of it.)

Found a partial work-around but it only works in aircraft with multiple crew positions. Once you switch to a crew position other than pilot the "Zoom normal" keybind will work again, then when you switch back to the pilot position "Zoom normal" will work there as well. Of course this doesn't help most aircraft as they only have the one pilot seat. Verified the SnapViews.lua file is still intact and untouched since the last change you saved to it. It's just not reading it from the keybind (which, as I requested above, you really shouldn't have to press every time you spawn into a plane, it should just assume you want the default zoom). I'm also no longer sure the hard-coded zoom level is different in different aircraft. The FoV at spawn seems to be 100.1 degrees in every plane I've tried so far. (Is this in a lua file somewhere? Really I wouldn't mess with the SnapViews at all if I could just set one common zoom level to use for all aircraft.)

Wow, what a mess! When we're getting this fixed, could we also make it so planes spawn already at their default view angle instead of the (seemingly random across different aircraft) value that's hard-coded into the aircraft module?

For some time now the mouse cursor has appeared black in video recordings instead of the yellow cursor we see in the game. I know it's not just me as I see the black cursor in Wags' videos as well. Particularly for tutorial videos this makes it really hard for the viewer to see what you're clicking on. I'm video capturing with the NVidia GeForce Experience app (what used to be called Shadow Play). I haven't tried any others yet but I'm going to give OBS a try right now. Also I fly on a regular display, not VR. Example...

This is a feature not a bug. The cursor disappears a few seconds after you stop moving the mouse. (You mean on a regular display, not in VR, right?) Also note the LAlt+C function which changes the mouse between looking around mode (where you will see no cursor even when moving the mouse, but your head will pan/tilt) and clicking on the cockpit mode (where you will of course see the cursor when you move the mouse). Might either of these explain it or is it something else?

It could just be you've drained your battery. If you're at an airfield try asking ground crew for power. Otherwise, minimize power consumers that you turn on before getting your engine and inverter running. Save any lights, radios, countermeasures, weapons activation for after you're running.

After several updates with no Huey changes it's starting to feel like this effort has been abandoned. If so, could we please just roll it back to how it was before the DCS 2.8.5.40170 Open Beta - 18.05.2023 update? Again, it was FINE before, the ONLY issue was the RPM needles didn't split. (But it behaved as if they were split. It seems to be an instrumentation error only.)

No it's a work in progress and currently way off. See above for how to put it back to how it was, at least somewhat. Oh, maybe you're right. I fly the OB so not sure. Could have sworn it was though, sorry.

They already promoted this Huey work to the Stable version. Worse, it's from a version before they fixed the throttle-skids connection.

This is my entire point. 1. It's all fake so don't expect the rules of reality to apply. 2. There was clearly a connection between being on the ground and the behavior of the throttle/governor. (And I maintain it was throttle because you couldn't chop the throttle once in flight. The governor only ever gives you LESS power than the throttle setting will allow, not more.) And the whole reason I brought that up again (as it's already been fixed in the new engine model) is just to illustrate point #1. I wish they'd just put it back to as it was. The only thing that was wrong before was the RPM needles didn't split when the throttle was chopped (but there was no corresponding drag effect on the rotor as far as I could tell, so it was merely a visual/instrumentation bug). This behavior is still happening in both versions of the engine-model, so I'm not sure what they even fixed or why. It was excellent and plausible before.

Just because they call it the "engine model", I wouldn't necessarily believe it only covers the engine. For example, before the last update the throttle was behaving differently whether you were on the ground or in the air, so it clearly had some connection to an imaginary "weight on skids" switch (the real Huey certainly has no such feature). Why they would have anything be different on the ground vs. in the air I can't imagine, but there's clearly some weird stuff going on in there. (Remember, this is all fake, not reality.)

Yes, I've noticed the same thing, ground effect doesn't work as it should now. It's "bouncy", with the normally easy to find "cushion effect" not there at all, making you either crash skids into the ground or shoot straight up far too quickly. Makes doing hover-checks impossible (and pointless as we just seem to have way too much power/torque/EGT available now). You can roll back to the old engine model by making this lua edit: (It passes IC.) Regardless of which engine-model I use, I find it's too powerful/fast now too. Even heavy with weapons she'll do over 125 knots now, level. I used to have trouble getting much over 90 before when rockets and external gun pods were on it.

Why wouldn't you give this static mesh a series of LODs just like any other static object gets? This was a major selling point for this map, promoted by ED in the news letters and product page. I'm disappointed.

Ground effect seems strange now. The "cushion" that keeps you from hitting the ground too hard seems to be gone or greatly reduced now. Hovering just above the ground now feels like almost as much work as hovering at a high and consistent altitude. You either put in too much collective and shoot up, or too little and come crashing down (even when well within half a rotor diameter of the ground). I also noticed this in the 2nd Huey engine model update from last weel. I now have that disabled in the Huey's FMOptions.lua file and the issue cleared up, but there's no equivalent setting in the MI-8's FMOptions.lua though and I haven't seen anything in the Changelog about changes to Mi-8 FM recently. Did something change? Maybe on the terrain side if not the plane side?

My problem with that shot is there's a clear "dent" in the UV mapping on the glass that needs to be fixed. Quite a few canopies have issues like this now, particularly around the canopy bow. Also not convinced the angle of the sun glint is correct given the position of the sun. But there should be glint somewhere.

Glare on glass is realistic. It's a factor in fighting. I absolutely want it in our sim!

Do you mean reflections? They're a must! Scratches too. Dirt I don't care for unless its accumulated during the mission. Real aircraft have carefully maintained glass.

It's not though. Take a look. Push the cyclic forward and the swash plate tilts forward. (I realize that's just the visual representation and not necessarily what the flight model is modeling. But might point towards some confusion somewhere.)

At the swashplate with a non-running engine. Use LCtrl+F11 to fly right up to the rotor head and look down at the swashplate. The swashplate tilts in the same direction the cyclic is pushed in.

I was always taught this as well but when I look at the rigging of the Huey it doesn't seem to be the case. Push forward on the cyclic and the pitch at the 6:00 position increases, etc. Is this incorrect as I've always suspected?

100% correct. One thing I'd add... while there's no rule you have to do it this way, I'd say that bigger displays should be used to give you a wider FoV, not to unrealistically magnify the scene (though, yes, we can always zoom in when we need to). I go to some effort to standardize the FoVs in all my DCS aircraft (a major pain as you have to edit the SnapViews.lua to do it) and set them to a value so that apparent size matches the apparent size you'd see in reality. (A good quick/rough check for this is hold your fist out in front of you like you're holding a stick. Does it roughly match the size of the virtual pilot's fist? If so you're close. But a bit of measuring and simple trigonometry should get you there as well.)

Oh okay. Yeah, it shouldn't do that.

Not off, ON! 4X if your system can handle it.

Is anti-aliasing (MSAA) turned on?