Whisper

looks like a mission specific communication, it's on the right side

Taking off and going for hard left turn is a sure sign of taking off wayyyyyy too early. Trim -1 before take off run, wait for tailwheel to go up by ittself, let the plane run some more, then pull. Not before.

That's not the point I was making, but please keep getting fixated on this and let's resolve this most important and absolutely shameful issue. People are making reports on other, normal flight envelop issues, but the one most talked about is the extreme ecample of something nobody would do anyway, like fixing this would make the chopper perfect. No, fixing normal behavior is more important imho

If you do, then head over Belsimtek forums, because from the same pilot tale, the UH1 behavior is not responding correctly for more than 20% of the flight envelop. Our simulations are far farther from real than you seem to think, I'd say.

I can do impossible things in many DCS (and any sim for that matter) aircraft. I don't see the logic in trying to fix things outside of normal flight enveloppe, that will not help the actual FM. If Poly do like BST did, ie make the chopper break in some way, before reaching the odd behavior, what do we get? The SAME FM, with conditions hidden behind barrier that hide you the issues. Will you stop complaining? Obviously, since you can't test. But.... that's the same FM (just a physics change that make something break). We glorify BST, but maybe they also have hidden some hideous FM issues by making the blades go away on UH1 when you test the FM too much.... If I have to point out a problem in Gaz FM, I'd point out the extra stability when not touching the cyclic (though the fact that we play with perfect centered non moving, ie, unreal, cyclic, certainly doesn't help the chopper depart from stability). I'd point out the complete lack of backblowing torque effect. Is that real? I'd point out the very little, if not absent, effect of 1 axis on the other 2 (at least, zero effect on cyclic) like I've read EVERY helicopter book outline. I'll point out the VRS. Maintaining long negative G ? It's impressive, it looks bad, but I don't care much, if that get fixed, that won't make the FM any better to me. We need to look, first, at the issues of the FM inside the normal flight envelop. And you gotta admit that the Gaz is pretty damn good in this, apart from a few points that I (and I may have missed some, ofc, I don't pretend to be an expert at all) listed above, and that makes the gaz feel too on rails to me. Though, I tend to not see the cyclic stability on takeoff as much important, because I play with a VERY loose stick that will not stay stable on takeoff anyway. That issue may be more visible for Warthog users, for example.

Actually, no. From reports outside of devs I got (for example, on french CheckSix forums), directly from pilots, that "good shape" of Gazelle FM seems confirmed and the issues shown here blown out of proportion, though I'm pretty sure they do exist. Just on this relatively recent topic for example, 2 gaz pilots posting in it : http://www.checksix-forums.com/viewtopic.php?f=465&t=196343 What do they say? That the gaz' FM is responding like real in 80% of the flight enveloppe, that it doesn't seem to be the case for every other helos in DCS (he pointed out the UH1, that he also flew, that seems too assisted for him). They find the Gaz FM bashing way too hot.

So now we're fixated on an fm abuse way outside the normal flight enveloppe that has no applicable use? Great, the gaz fm will be top notch when it won't fly inverted for too long! Thank you, forum experts!

That's the problem, people are bashing so insanely hard that you'd think the thing is 100% broken. It's not. I'm sorry if that offends some here, but to me, the fact that every single return from actual Gaz pilots are saying that it's very near the real thing is showing that, despite its obvious flaws, the DCS Gaz is getting it. Some choose to focus on the flaws. When you don't, the chopper behaves (mostly, I agree there are little missing things) like it should. OTOH some response from Polychop portraying an ideal FM that does not need a single change, is indeed worrying. That said, I don't know myself what I'd like to see best, multicrew fixes, or FM...

From what I understand, no, there isn't much communication, not of this sort, at least. For example, Poly discovered the new network engine (which broke their multicrew) AFTER it was released and the Gazelle was unusable by then. Everybody is hitting on Poly, but everything isn't that black & white.

If max roll rate is achieved without pushing the stick to the limit, it's probably a good idea to lower the saturation of the axis.

Isn't that pixel only apparent when the chat window is enabled? I think I remember seeing it disappear when I disable the chat window

I think the AP gauges (bottom right) with the white lines will be seen moving when AP engaged

Honestly, your hardware can make things go completely wrong even if it seems fine. Different hardware (using different axis for brakes, changing curves.. ) setups gave me completely opposite results in the spit. A very little detail can change anything. So I would not blame the pilot so much after this number of attempts. This may well be a controller problem. Did you experiment with curves? Try changing them for rudder, roll & pitch. Also try different placement of the brake axis. I guess the way it was setup in real spit made everything smooth and natural. It's not the case for us in DCS. After several hours of training (phase which you already got through), then controller setup experiments, it suddenly completely kicked in for me. And like you I couldn't possibly blame my hardware, it's a MFG Crosswind and x55, you can't say it's because of bad controller with THAT hardware [emoji4] . When I point at controller, it's not to say that your hardware is bad or badly suited, but that the axis setup doesn't fit what the spit needs, and what you need so that it feels natural.

This. The ease of access and precision of the axis used for wheel braking makes all the difference. If your axis is not too easy to access or manipulate, anticipating the 15% brake before touchdown is kind of valid since you cannot do what would be done IRL. But, at least with my hardware (X55 + MFG Crosswind rudder), since I moved the brake axis from a rotary under my thumb on the throttle to both toe brakes on my rudder, I can manage landing without engaging brakes beforehand, with 100% success and far more easily. The trick is to find a natural movement for the braking, and at least on the MFG, when I push the rudder one side and toe brake with the other foot, it makes the movement perfectly natural and easy.

For stick extension , look here : https://forums.eagle.ru/showthread.php?t=166174 In this very same thread, I think there are people who would also be very interested in your crank over mod, they are talking about something like that by the end of the thread

Same, I was just pointing out that people were saying to use the toebrake on the foot pushing the rudder, I'd advise to do the opposite : use the toebrake on the foot NOT pushing the rudder.

Pretty interested for sure! Did you also add an extension to the stick?

I'm contemplating doing the very same thing with my X55, but that's quite some work. In the meantime, I've discovered a very neat way of handling braking in spitfire, using the same MFG as yours. I was avoiding toebrakes because like you said, Spitfire is not built that way and feets tend to slide of pedals when you push the rudder and the toebrake at the same time. BUT if you push the rudder one side, and use your OTHER foot (the one going back) for toe braking, this develops in a very natural movement (akin to walking) which works perfectly.

I concur with Art-J as currently, only some stick forces implementation at high speed are mentionned to be missing. If one feels that taxiing isn't realistically modelled, he better talk now cause I don't foresee much changes in that department.

that would explain a little the wobbly nature So she needs to be handled very gently. Thanks for clarifying.

Imho of a noobish dogfighter, the current main issues for me would be : * Problem with stick forces or feedback of these forces (to be confirmed by devs) on Spitfire, making it too prone to blackouts or wings failure. Though honestly, I have not suffered from any of these for a loooong time now, once you know how to be progressive in your inputs, it's fine. OTOH it may hampers my actual reaction (ie I don't pull back on the stick as hard as I could for precaution reasons) * Undergunned P51D. I don't know if that is a realistic depiction of actual P51D armament, but having to unload that much to kill makes it a nightmare for P51, compared to the other 3. On most of my engagement with spitfire so far, now I know the engine limitations and flight limitations, even though yes I can't keep up with Axies, the mobility allows for easy avoidance of incoming ennemies. It's a matter of SA and knowing when to react. The only thing that I simply cannot cope with are pilots with very good aim. These kind of people can hit even with the big deflection angle I present them, where the majority of pilot can't (or rely on luck to do so). As far as I can tell, this is actually rather accurate, one of the major component separating normal from exceptional pilots during WWII was their ability to aim. I really don't find the situation that gloomy, tbh. Not denying an "underpowered" aspect in Allies aircraft, but far from "it's over, ditch your aircraft you have no chance" that I read far too often.

Poor Allies aircraft have absolutely zero chance in winning anything, it's a slaughter and the end is near, that's what it's supposed to mean ....

I quickly did these test comparisons last January : https://docs.google.com/spreadsheets/d/1CJBvekYA9qW38hxM5GKPsvqiBjTqsABOU3bCQkzikpE/edit?usp=sharing Speed in kph, alt in feets. Tests were rather quick so prone to a certain margin of error. That gives a rough idea, though. Max speed was determined as "max sustainable speed", ie, slight dive until reaching target altitude, then record at which speed the plane stabilize at intended regime.

Am I the only one, on the latest Open Beta (1.5.6.1648.240) updated (there has been an update going along the 2.0 update of last friday), that find that another change was made to distant visibility? The pixels for objects in 5-15km distance are now FAR more visible than before, without label activated

Pre or post installation of tail wheel lock on the 109? Take off / landing without locking the tail wheel is a whole other story in the 109