SMH

Found one more issue, the Torque gauge will go over the red line which I believe is supposed to be impossible (because the sprag clutch is designed to slip at the maximum torque to protect the rest of the powertrain). Also note the full speed run I do out towards the ocean, which is about 130 knots, my stick is 100% forward. Couldn't nose-down if I wanted to! I perform the autorotation in this one a little bit better and it seems to verify my suspicion that the engine RPM needle won't ever go lower than the lowest speed the rotor RPM reaches after the throttle is chopped. Note how the engine RPM is higher during the autorotation in this one than in the previous one. (I'll try to do one more with no needle split at all... I'm flying without trim here to keep things simplified so I'm a bit wobbly. And of course my muscle memory no longer applies.) (All of these effects are explainable by way too much power and torque from the main rotors now. The pedals can barely counteract it, and the stabilator can barely keep the tail down at full speed even with full forward cyclic deflection.) Super_Huey_Test_02_100Fuel130knotsEngineRPMDuringAuto.trk

I couldn't get it to climb in hover fully loaded but with 100% fuel (7747 lbs), standard day, sea level she'll climb at 2000 FPM easy with both Torque and EGT at the top of the safe-range. Also note the extreme amount of left pedal required to counteract the Super Huey's extreme torque, over 66% of the pedal range! (Should be more like 25%, ask any Huey pilot or even just watch their feet in a video.) The needles also do split this time but not nearly enough. (There must have been an undocumented change since the Aug 2 update because every time the Changelog mentions a Huey FM change I reenable the new engine model and re-test it. EDIT: Or it might be that I did a poor job of entering autorotation and I had to get the rotor RPM back up with airspeed and the engine RPM remained where it had dropped to before the needle split, I'll try that again not in a hover and not concentrating on my controls display and instruments so much.) So, better than the last time I tried it but still way beyond plausibility. Caucasus_Super_Huey_Test_02_100Fuel.miz Super_Huey_Test_02_100Fuel2000FPM.trk

The "modding" feature is your own creation. We're not at fault for employing it. (If we weren't supposed to change it it would break Integrity Check, right? But it doesn't.) And you do realize that we are paying customers, right? I have never seen a business with such clear contempt for its revenue stream providers. Working on your track file of something everyone can clearly see just by simply bothering to try it...

Being critical is not unconstructive. Just the opposite. I haven't been rude here at all and I've contributed significant time to the testing and reporting of my formerly favorite module. You should thank me, not scold me.

I can't come up with any condition or regime where it won't hover so I'm not sure what you mean by "underperforming". You can either hover or you can't. I'll find a video that shows what's wrong, I saw some on YT recently but forget where exactly. [EDIT: Can't seem to find it now, I'll make a track file.]

So a fully loaded (indeed, overweight) Huey can take off straight up with zero translational lift and climb at 2000 FPM? I don't think so! Ground effect is gone (or we have too much power to notice it). VRS can be easily powered out of with no other action required. And the needles STILL don't split when the throttle is chopped! This is no longer a realistic module. It was my favorite! You've literally had months. And are you implying this won't even be addressed in the coming 2.9 big update? Unacceptable! Their newest helicopter model (the Apache) is their worst, and progressively getting even worse with every update. I fear they've recently lost some talent in that department. PLEASE just roll the Huey code back to what it was! (Same as what editing the lua does but remove the ability to cheat by having "Super Huey" mode enabled.)

Ditto! And nobody can whine "Early Access" at us this time! Yes it does but it's still a bit overpowered. But it's not just about the aircraft you're flying. People are expected to fly AGAINST the "Super Huey" too! Wrong is wrong and it doesn't belong in our supposedly high-realism sim.

Ping?

I've verified it doesn't happen with OBS, just with NVidia's recorder. (Any other video recording/streaming products that it happens with?) And yeah, it's happening in Wags' videos so you'd think it would be a priority for them. Makes it very hard to follow the tutorial when you can't see what he's pointing at!

Yeah I hate that, they can't just pick a convention and stick to it. Lots of toggle switches in lots of aircraft go in random directions too.

You can see through the fuselage sides towards the rear of the open bomb bay.

Ha!

Hardly needs a track. I see the need for that for complex and difficult to reproduce issues, but a track file shouldn't be demanded for a simple issue that anyone can see simply by getting in the plane and looking. (If others aren't seeing it as well then, sure. But, c'mon, you are.) Anyway, thanks!

That I'm depressing the right rudder far enough that it's disappeared behind the wall entirely. (Both shots aren't from the exact same timestamp in the track file - there being no way to accurately achieve such a thing, at least not without tediously going through frames in slow motion.) Watch the track file. (Or just get in a Sabre and move the pedals and look at them.)

And just in case anyone wants to blame that black cockpit panel skin I'm using... null

F-86_Footwell_Wall_SMH1.trk

Interesting, it seems to behave differently depending on whether you smash the nosewheel off on the runway or blow it up into the wheel well in the air. I also noticed a half-way down state of the nosewheel in this one that I haven't seen before. Though it eventually gets blown up into the gear well entirely, it feels like maybe the collision model is keeping it half extended. (Though in that case I wouldn't expect to see the sparks effect. Or I should say... the GLOW from the sparks effect, there's no actual spark particles thrown off.) Bonus bug: At the very start you'll see me moving the rudder pedals through their full range. They end up disappearing into this new black wall that seems to be in the footwells now. (I'll make a new topic for that.) F-86_Nosewheel_Collision_Bug_SMH1.trk

Overspeed the gear to get the nosewheel stuck in the retracted position, then land. Your nose will never completely hit the ground. In this shot you can see the orange glow from the sparks effect despite the nose not contacting the runway. I'm not holding it up with elevator, that's the same attitude it'll come to a stop in.

You realize they could make any module they wanted super-effective UFOs that defy the laws of physics, right? This is a simulator, not reality. But the goal is to simulate reality, not sci-fi. Would the Mustang be more effective if it went Mach 2? Sure. Would that be what I fly a high realism-sim for? Nope!

Then why did you patch it with work that clearly wasn't ready? Please just put it back to how it was at the start of the year. This isn't an Early Access module, we shouldn't be having it removed from usefulness for major portions of a year.

I'd be all for maintaining the SnapView system so you can define different zoom levels in different aircraft (though I disagree with your strategy, you're making apparent size of objects different in different aircraft - but yes, you should be allowed to do that but not expected to do that). There should be somewhere we can set the value that aircraft spawn with, instead of whatever is determining it now (I assumed it was hard-coded in but I see from posts here that different systems get different values - perhaps it's affected by screen pixel dimensions? I can't see why it would be but I can believe anything at this point). And no, it's not a matter of seconds to edit the SnapViews.lua (which is already a power-user move that many users won't feel comfortable doing). Before you can edit it you need to create a record for the given aircraft. That means spawning into every aircraft you own (taking several minutes each time), making sure you don't move your head position (so, remembering to disable your head-tracker before you do it) and then saving the SnapViews with RAlt+Num0, THEN going into the SnapViews.lua file and finding the default zoom records for the pilot positions (and you can't easily use a global replace because they won't all be the same and there's also default zoom records for other positions as well) and editing each one to the particular zoom value you want. That's exactly what I did do, but I wouldn't call it "a matter of seconds". Anyway, leave all that capability as-is. It would just be nice if that currently uncontrollable zoom value at spawn-in time could be defined somewhere by the user and is then only overridden by the SnapViews if that record exists. (So then you can still use NumEnter to get back to normal zoom at any time, even without having to define all the zooms in the SnapViews.) Make sense?

While we're at it, how about getting rid of the need to hit NumEnter at spawn-time entirely? (And, even better, a single default zoom setting that applies to all aircraft. I wouldn't even touch the SnapViews system if only we had that. We already have an option for defining external view default zoom. Interior should be the same. Why would we want different focal-length eyes in different aircraft?)

Everybody has always had issues with the initial view because it's never automatically spawned with the desired default zoom value without needing to hit NumEnter first to recall the value saved in the SnapViews.lua. Most of us have learned to hit NumEnter reflexively on spawning in as of course that's the zoom value we want. That was annoying, but tolerable and, again, we're all used to having to do it at this point. But now, not even that works unless you use one of the work-arounds described above. (RCtrl+Num0 twice to go into and back out of panel view. Then it will work as before. Or switching seats in multi-position aircraft will allow it to work as well when you return to the main pilot seat.) Everyone has been very clear about this in this thread. If you have trouble understanding English then someone else should be communicating with the customers because you don't seem to be understanding, and your responses are near indecipherable to us as well and seem to be placing blame on the customers.

Single display, 1920x1080. How can you not acknowledge this is happening? Don't gaslight us, we're not stupid.

Odd then that we have air pressure before the engine even starts. Prop sync makes sense, thanks!