tekwoj

I had a girlfriend but then I started playing DCS.

I think you're right. I tested the tf-51 and stall there seems to have normal frequency. Here's a very short track showing 1.9g on the runway before even lifting the nose jf-17-ground-g-force.trk

f1-nav bug.trk track of the issue happening on the Caucasus map.

I have it at 50. It's not about intensity, it's about the frequency. Flying corsair at 10 AoA feels like holding a vibrator.

I wonder if there was a wider change to ffb on ED side maybe. The Corsair's ffb has issues too even though it was fine on release.

Rather yes, it's present in direct input only mode, disappears when I switch to telemetry only. I've also tested in mirage f1 and F/A-18 with using the same preset and there was no shake. Something I've noticed in telemetry logs is that JF-17's gear seems to move the most of those modules when rolling on the ground, which might be the cause if the effect is calculated based off that. Moza just fixed one part of a bug in their firmware, so I'm getting a full power of the effects, but even before there was enough shake to make my head tracker go crazy.

I think the vibration during taxi and take-off might be a bit too violent. On a 9 Nm base it shakes really hard.

I'm on Moza AB9. I remember distinctly being surprised that gun vibration comes from the direct input, cause most modules in DCS didn't have it. I use only Direct Input for the corsair, no telemetry. I"m pretty sure the vibration had lower frequency because I flew it quite a bit when it came out and it was very enjoyable on ffb.

The stall buffet frequency was fine when the module released, but now it's way too high and makes the plane unflyable. Also the gun firing vibration used to be there but now it's gone. Honestly it feels like the stall is using the gun firing frequency.

T'est sur que t'as activé navigation HNS, et pas jusque INS ? Il y a des bug du pod mais il s'affichent autrement (le majeur c'est l'area track qui ne marche pas au quelques premiers activations). Mauvais coordonnes ca me semble un erreur du navigation gyro.

@uboats Bad news and good news. Bad news is that the bug? is still there. Good news is I reproduced it and have a track and mission file. It happens when the plane is cold started with heading 000, but the pilot is too lazy to enter 000 during nav align because the heading field is already set to 000. The mission file already has the 2 waypoints added so they don't have to be input by hand like I do in the tracks. The jf-17-000-heading-ok.trk shows that behavior is ok if I input the 000 heading during nav align. 17-nav-test2.mizjf-17-000-heading.trkjf-17-000-heading-ok.trk

In my experience the none option does what it says, it sets no trim and the magnetic brake remains in the center position, not in the newly set position (probably has to do with polychop's implementation of magnetic brake combined with manual trimming), so your ffb stick is centered and you can't do anything. For ffb sticks the option that works better is instant trim, the option that works best is flying with magnetic brake off.

sliders are set to 0. The final position of the stick is correct, there's just that annoying pull at button release.

Seems good, I've flown quite a bit lately and didn't see the issue repeat.

There's no need to do that on modern ffb bases or at least not on moza ab9, the force direction is correct. If I check the swap axis the stick stays in the wrong position after releasing the trimmer. I've checked the ffb gain curves - it seems to just work as a curve for input. If I set it then the neutral input is not anymore where the trimmer is. The problem remains, those few frames when old trim value is present after release is causing the base to pull to the old trim position. Either the trim has to keep moving with the stick when trimmer is depressed or the event order has to be changed - when player release trimmer the trim position is moved first and the magnetic brake is engaged after.