w.i.p 2.7.4.9632 & 2.7.4.9847 OB - wheels soapgliding and oscillations with zero input

[rogorogo]

patches 2.7.4.9632 and 2.7.4.9847 have introduced various fixes and tweaks to controls, trim and FM.

And for the most part they seem to have been very sucessfull (fe the problem with "overtrim" are far less and the sound feedback is also very helpfull).

The Shaitan-Arba is now also much more controllable at low speeds.
Especially noteworty in a positive way - VRS does no longer suddenly and fatally happen, the soundmapping for RBS, VRS, max-envelope aso is now a completely suitable indicator.

What seems to need further attention is the following though:

• the feel of weight and mass now seems reduced, and the Hind is too twitchy in various envelopes (to the point where one seems to "stir" the cyclic aka the joystick)
• while hover transitions are now far more controllable the hover itself seems to have become very twitchy even in low-weight and zero stress conditions
• the wheels now "soapglide" even more in almost all terrains, even with collective on zero, rpm throttle down, and wheel brakes locked

I have included a track from the remastered-for-hind  huey-campaign (ty for that excellent scenario to really control the Hind @Bailey) where this can be seen. I also could directly compare the asset behaviour to before the patch (as I had just flown that mission before both patches).

Twitchy hover:

• during takeoff
• at final landing at "Madrid" at the end

"soapgliding" of wheels

• at rolling landing and taxi at Senaki-Kholki
• on the pad at "Madrid", with various test of AP channels, locked wheel brakes, applied wheel brakes, idle rpm, zero collective, diverse trimstates "rudder" (tailrotor), "heading" AP channel on/off 

 

slights osciallations during flight in stable envelope with no input 

• entire flight various attitudes, crabbing
• during transition
• during speed hook or forward reduction
• notice zero control input (control input indicator up entire track)
• notice "pulse" inducing oscillation with slightest inputs as if input signal is registering on/off

 

For the problems describe above, also notice how for the most part non-pilot induced oscillations seem rock stable while any attemopt to correct them with minor cylic, minor collective or general slight(test) peripheral input seem to surge the oscialltions or the twitchy hover behaviour (especially noticeable at the end of the track, when I almost crash myself at "Madrid").

The widely reported "overtrim" or "input overshoot when pressing trim" is reduced but still noticeable.

For the passer-in-glancing, please focus on the bug behaviour, my bad flying is a given having to be seen as "baseline"  . 

Trackfile as google-drive link as filesize exceeds attachment limit:
https://drive.google.com/file/d/1u71lvSaImScYA2f3zgynpGPhEwe5roFX/view?usp=sharing

Dxdiag file attached for good measure.

DxDiag.txt

[rogorogo]

I must add something to this OP as a separate comment.

After having tested it again with a further - single player and campaign - mission there most definitely is a change to either inputs or FM that caused a bug (probably a typo or a repo-merge oversight).

• Forward facing transition to hover is now far too easy, even while almost completely staying level and at neutral angels.
• While IN hover I now constantly have to play with the collective and "stir" in the cyclic in miniscule corrections on all 3 axes (including rudder/torque pedals/tailrotor) - as I use sticktwist and "rudder trim" because of it
• the hover can far too easily twitch out.. in low speed and hover envelopes the hind suddenly does not feel like a shaitan-arba or a crocodile but a floating twitchy noclip camera (no exaggeration) where the challenge is not to hover against weight, mass  nd inertia but to keep the cylic-stir under control 
• the tailrotor now tends to lose authority far to easy in takeoff and final hover, same in ground effect and on pad/touchdown as described above
• pad-landings and hover landings in general are now far too eas, too precise and effortless for a 24-P (despite the wheels soapgliding and the tail-rotor authority loss). This was far more fidelic before
• minor collective corrections now suddenly have a massive noticeable impact in a relative short amount of time (again hinting a loss of weight, mass, inertia - maybe just a typo that commented out mass-variables?)
• arrest-curves are now trickier than forward arrests and transitions.. again 86-ing the correct behaviour for the airframe and reversing priorly present fidelity

Attached a second track showing the issue on both pad-landings.

I have yet to test this in a multiplayer scenario (if input lag changes anything) - but the Crocodile felt extremely fidelic and akin-sync in both scenarios before. 
And anyone who has even seen an Mi-24 or a 35 even in an airshow should notice that this there is something amiss here... especially to the correct and fidelic "feel" and behaviour before (where again -> getting the inertia, weight and mass under control and in transition was a correct and fidelic challenge, despite the far too-sudden-without-any-symptoms and always fatal VRS).

Especially on the final landing in the track... while before I would have crabbed in slowly I was now almost freezing and gripping on the cyclic as to not twitch out of the crab approach . while feeling weightless as a feather in player-immersion-uX that I could have just arrested and dropped straight down.

Again.. there is most definitely a bug - because if this is intended behaviour... the behavioral characteristics are now "just off"... completely and bizzarely "off".

For the passer-in-glancing, please focus on the bug behaviour, my bad flying is a given having to be seen as "baseline"  . 

Trackfile as google link as it exceeds attachment limit:
https://drive.google.com/file/d/1GW2CxWUZrzw2EZ8fcxTXsjyX6U727R1w/view?usp=sharing

 

P.S. this went so far I even dismantled my stick to check if the magnet- and srping-mods were still there and working correctly.

Edited July 24, 2021 by rogorogo

[rogorogo]

hmm.. as I had time to do some more "testing" today, I need to add a few more impressions.

Not to "bump" this thread but just because being attentive to the initial observation made me notice some things that are even somewhat in contradiction to my initial observation.

While again "testing" as in "just flying" a scenario which forced me to hover in a certain way (confined space, from higher up and limited crab approach and descent circle options) and not giving me a "way out" I felt even more of my initial observation to be true.. just in a different manner.

The "sudden and fatal VRS" is still present but as the feel of weight, mass, intertia is gone while hovering has now become too "twitchy" I have to pay more time increments glanicing positional and even less increments available to watch the VSI.

Thus if I actually have to hover down in a tight space from higher up without an open crab approach... both the hover spins out constantly with me working against the "joystick stir" instead of hovering against the airframe mass while the "VRS of doom" now manifets as before.. and maybe even more ninja-like, ESPECIALLY since now miniscule cyclic input have too much effect on the airframe where before you had to make conscious cyclic decisions with properly delayed airframe behaviour. The nose is "too light" and miniscule attitude changes because of miniscule cyclic inputs have far too much consequence even without the added current state of the collective inputs and the power output.

Especially noticeable is that compared to before now way lower collective settings have to applied to achive negative  VS/sinkrate than before -> helium ballon in gusts of wind  feeling without any weather effects present.
Even the VRS effect itself - while still sudden, no symptoms and always fatal - feels in immersion less like "a stone falling out of the sky" than before -> again helium ballon in gusts of wind feeling without any weather effects present.

 

Same for the collective input.
The hover process is also way more twitchy and inconsistent with sink rates being not as stable and controlled and the collective just being too reactive when it comes to "power output for VS".

Thus miniscule cyclic can lead to completely weightless displacement instead of an actual "hover" behaviour, with proper corrections not correcting but stiring up out-of-control like an increasing oscillation wave.

Thus the cyclic and even the collective in critical conditions feels like a QUERTZ quicktime event instead of a proactive and reactive conscious input decision.

Worse, the hover transition is now very problematic when it comes to the relation of nose attitude <-> cyclic <-> VSI/angels. Not only do you have to use far less cyclic and attitude then before while minscule changes in either or at least in cyclic have far too immediate and noticeable effects, the hover transition itself now only feels controllable in forward transistion, where the proper and fidelic speed curve or descent circle constantly twitches out of control or the tail rotor loses authority (torque authority loss) or the heading channel of the AP suddenly goes to max for zero reason (well.. for the former mentioned torque issue).
What is so disturbing about it is the the airframe twichting out of any curve and bank LEFT - the side the airframe is know for to be its "better side" and even the canopy visibility of the pilot-commander optimized for it (in a very rare instance of soviet russian consideration for any form of "ergonomics").
Moreso since this is also happening at speeds and with continuous flight intention, where the winglet effect was fomerly very noticeable while now more torque is commanded by DCS and it still suddenly twitches out without any soundmapping or any other fidelic symptom (aka the "heavy but stable in forward motion" translative feel is completely gone).
Again, this is not like the airframe behaves (not IRL, firsthand- and/or secondary-narration consumption, not in its DCS translation, not with the necessary changes to convey a flightsim experience in any potential iteration)  and not the same level of fidelity it was able to communicate within the confines of DCS in earlier patches.

And yes, this reads completely subjective and it is - but how else should one describe this when there is no objective telemtry, no QR codes, no proper logs, to submit.
I will not even attach a trackfile, or 5 actually where I tested this, as it would not contribute anything (also: trackfiles in themselves are not that reliable for replication as we all should know and its boring to watch me fly around badly long just to VRS in the very same situation just slighty different over and over).
The conditions are the same, the extra description is made as a separate comment because of me forcing me into a replicable scenario for myself.

I cannot be the only one noticing this.. and while the reason as in "source-issue" could be anything, even just weird AP or trim behaviour, typo-related-bugs, missing or not interacting variables.. this is a major impairment of the module behaviour imho.

Again... I cannot be the sole person to notice this.. I hope.

Edited July 26, 2021 by rogorogo
typos (more still there) and timeconstraints earlier

[TOMCATZ]

I bought the "mother of all badass helicopters" last Saturday. Normally I'm not that interested in helicopters, but the Mi24 is a must-have for me. 

Okay - I don't have that much real live experience. I trained in some military simulators in Bückeburg/Germany when I participated in a selection programme. Long story short: I know the maths, I understand the physics and I can fly one of these things safely. 

 

I expected a heavyweight monster helicopter when I entered the virtual cockpit. I made all the settings for my stick and was ready for my first T/O .... And that's when I was really disappointed. I thought, "This can't be happening!" , "I ""don't feel"" any weight!" I dropped the nose down, lifted it, moved it to the left and the behaviour felt more like a tiny little drone. The entire flight model acts very nervously, reacting to everything in just half a second.Even a simple vertical take-off brings you close to death, because the helicopter is too unstable due to the lack of weight and reacts to everything.  If a 10 tonne helicopter behaved like that in real life, no one would fly it. 

 

I hope the team will change the flight model, because I am still very interested in this wonderful work. (I think that the model was good and was changed with one of the updates...) 

Greetings and cheers,

Tom

[BIGNEWY]

The team will review the flight model as part of the early access process,

 

but "it dont feel right" wont cut it when it comes to reporting issues so we have to be very careful to stick to the numbers and use SME feedback. 

 

If I have some news I will pass it on. 

 

thanks

[TOMCATZ]

Hi, 

 

Oh yes: sorry for this "feeling". But how can you record "missing weight" because you have to have roll and pitch data - quite hard to do or maybe impossible just for an user. 

But the team has a lot of experience and knowledge so my hopes are very high that the module will have the best possible results and solutions.

 

Thank you very much for your quick and kind reply. That's a very good service! 

 

Cheers

TOM

 

Edited July 26, 2021 by TOMCATZ

[rogorogo]

vor einer Stunde schrieb TOMCATZ:

I bought the "mother of all badass helicopters" last Saturday. Normally I'm not that interested in helicopters, but the Mi24 is a must-have for me. 

Okay - I don't have that much real live experience. I trained in some military simulators in Bückeburg/Germany when I participated in a selection programme. Long story short: I know the maths, I understand the physics and I can fly one of these things safely. 

 

I expected a heavyweight monster helicopter when I entered the virtual cockpit. I made all the settings for my stick and was ready for my first T/O .... And that's when I was really disappointed. I thought, "This can't be happening!" , "I ""don't feel"" any weight!" I dropped the nose down, lifted it, moved it to the left and the behaviour felt more like a tiny little drone. The entire flight model acts very nervously, reacting to everything in just half a second.Even a simple vertical take-off brings you close to death, because the helicopter is too unstable due to the lack of weight and reacts to everything.  If a 10 tonne helicopter behaved like that in real life, no one would fly it. 

 

I hope the team will change the flight model, because I am still very interested in this wonderful work. (I think that the model was good and was changed with one of the updates...) 

Greetings and cheers,

Tom

Please believe me when I type at you:
"the feeling you expected as translative flightsim experience WAS THERE and EXACTLY as you described in your expectation outline". Until 2 (well 1,5) patches ago.
Something which I explicitly stated fe here and there:

 

Which is also the reason for me typing that extensively about it (including all the typos on planet Earth)
 

vor 48 Minuten schrieb BIGNEWY:

The team will review the flight model as part of the early access process,

 

but "it dont feel right" wont cut it when it comes to reporting issues so we have to be very careful to stick to the numbers and use SME feedback. 

 

If I have some news I will pass it on. 

 

thanks

Well yes, of course, absolutely.
But what else is there to feedback but a personal, subjective and as descriptive as possible impression - in the absence of any other predefined and disseminated roster or guideline to follow? 

Also to convey, to translate, to communicate the "perception", the "feel", the "module-Ux" of a 24-P within the confines of a flightsim is not a straight 1:1 conversion of tables into code and datamodels.
And the enduser, the customer is the least qualified to define the translative measures necessary to be applied.

Of course this boils down to "it felt right and even on the raod to perfect before" & "now it dont feel right" - but again, what else and how is there to raise awareness with except being as earnest, as intersubjective. as descriptive as possible?

[BIGNEWY]

1 minute ago, rogorogo said:

Well yes, of course, absolutely.
But what else is there to feedback but a personal, subjective and as descriptive as possible impression - in the absence of any other predefined and disseminated roster or guideline to follow? 

Also to convey, to translate, to communicate the "perception", the "feel", the "module-Ux" of a 24-P within the confines of a flightsim is not a straight 1:1 conversion of tables into code and datamodels.
And the enduser, the customer is the least qualified to define the translative measures necessary to be applied.

Of course this boils down to "it felt right and even on the raod to perfect before" & "now it dont feel right" - but again, what else and how is there to raise awareness with except being as earnest, as intersubjective. as descriptive as possible?

 

Hi,

That is why we have system matter experts who have real flight time in the airframes, their feedback is crucial for our work.

 

thanks

[rogorogo]

Gerade eben schrieb BIGNEWY:

 

Hi,

That is why we have system matter experts who have real flight time in the airframes, their feedback is crucial for our work.

 

thanks

Also well yes, of course, and I am VERY much aware of that.
Which is why I constantly and extensively typed that this sudden and violent Ux and behavioural change cannot have been intentional, it just reeks (no other term) of a systemic behavioural downflow and outflow bug that must have a potentially singular source issue, a true "source bug" (that might be weird or an oversight, or a qa-re-merge nonetheless). 

The various "changes" in submodules, keylogs, components, systems however you internally call them are just too much all over the place, just not "in sync" with each other, not systemic enough.
And yes, both the airframe experts, the system experts (devs) and the mergepersons know that way better... but there is no other way to bugreport this.
To try to pinpoint the issue, and map out the symptoms - and the earnest impression of a technical bug, not a design change.

And again, apologies for "it dont feel right" - but again "it damn done feel right before" .
And thank you for taking the time to react publicly and acknowledge the escalation into proper channels.

[BIGNEWY]

No problem, thanks for posting. 

[BIGNEWY]

I will close this report for now, we are reviewing the flight model during early access and when we are ready we will let you all know, then you can bring any evidence of an issue in a new thread. 

 

Thanks