Wingflexer derf/wings literally falling off model in time acceleration

[IskenderWang]

I don't even know how this is possible and to what extent it's related to Wingflexer/JSBsim as opposed to the model itself or any other factor, but yeah... should you accelerate the time to at least 4x (becomes even more severe on 8x) Wingflexer begins to crap out and cause all sorts of fuckery with the wing model until eventually, if you let it continue unchecked (I had, naively assuming it would return to normal eventually) it apparently can lead to whatever tf this is supposed to be:

[C-FWES]

Happens with the A359 too when you speed up the time the wings go bananas so it could be an issue with the default wingflexer code

[Marsdolphin]

Things go wrong in time speed... The autopilot become unstable too

[C-FWES]

Never had issues with IT-AUTOFLIGHT in speed up time

[C-FWES]

Also may be related to a low frame rate, as frame rate drops when time is sped up. And I also spawned in KBOS which is HEAVY on frames and my wings started flapping like heck. So the wingflexer core code probably does not handle low frame rates

[MarcinListkowski]

Hello @IskenderWang, I had a look and:

1. All 787 models I've seen have this issue and use the same approach of property-rule taken from Aircraft/Generic/wingflexer.xml: https://github.com/IskenderWang/787-family/blob/6a7f7da8aaf8dd1d77664bbc1ba50350c1ebe8d3/787-common.xml#L37-L40
2. This wingflexer logic used in this way is unstable on startup and with irregular time intervals (e.g. accelerated time). Debugging shows that the sim/systems/wingflexer/z-m property goes well out of range or reaches not-a-number values. As this is used for wingflex bending animation, excessive wings flapping or disappearance thereof occur. I've found an e-mail from Thorsten on the flightgear-devel mailing list which seems pretty related:

   Yep - changing it from a property rule to an AP makes it nice and stable
   and for me changes it from craziness to sanity. ... Note: Never ever run differential equation solvers as property rule! That's a completely mis-guided notion of saving computation time. https://sourceforge.net/p/flightgear/mailman/message/35730689/

3. The fix Thorsten is referring to is in this commit: https://github.com/FGMEMBERS/Citation/commit/0ffc7bc6dea146aaaa8d967cdaf2dc010a72e6f6
4. ...which leads to a conclusion that changing property-rule to autopilot should help. Honestly, I'm not sure I'll be able to try it out myself and create a PR anytime soon, so I thought to just drop my research here for now.

[D-ECHO]

Hi @MarcinListkowski, thanks for pointing to this tip by Thorsten. I tried it on my own aircraft and it easily fixes the problems, will now apply this patch to all of them.

Best Regards

[IskenderWang]

@MarcinListkowski Hello my friend! Thank you SO much for bringing this to my attention!! Just as D-ECHO reported above, I implemented that one super easy tweak you showed us and it fixed this bug completely. Incredibly (not sure if it's just me) it seems that the performance of the wingflex as a whole has improved as well, it appears to now behave more smoothly and realistically than before, so I suppose this has been the way to get the most out of the algorithm after all. Or more so, the property-rule method was just a totally wrong way to go about it, and it should have always been like this from the start. I never thought it could ever be such a simple fix!

That's quite a relief, I must say – and if not for you and Thorsten this major problem probably would have gone unsolved for a long while. This glitch was totally beyond me and ultimately I had just assumed it was an issue with the core wingflexer code, but apparently (& thankfully) that's not the case. Big up chieftain! I'll be pushing and closing the issue shortly.

[IskenderWang]

Fixed by 32e5384e8135919571064262713c8c7d8f48c5e7