Re: [Flightgear-devel] [Flightgear-commitlogs] [FlightGear] 02/02: YASim gear: Clamping of _frac replaced

[James T. <ja...@fl...>]

> On 7 Jul 2023, at 22:10, Julian Smith <ju...@op...> wrote:
> 
> But against that is the fundamental unreality of the new algorithm - it
> attempts to define behaviour for when the gear is compressed beyond its
> real-life breaking point.
> 
> Hence my preference that if we are to include the algorithm, there
> should be a way to turn it off.

I have a bit of workflow anxiety here: I agree we need to revert for the moment, because we have issues with even our default airport. But I worry that once it’s reverted we are back to basically zero with making progress on the underlying issues Jakub was attempting to solve. (And that’s quite a de-motivating situation for any contributor)

Arguably we are slightly improved, in that we now know that our scenery / ground-reaction code is partly to blame, since it generates glitchy data. (I am guessing we have some very thin cracks in the scenery, since I don’t imagine we have a 10km spike in the middle of BIKF). Interesting question for me would be, if the scenery returned plausible (filtered?) values, would the original patch still be necessary? (Ie how many different problems are we fixing here?)

I would be happy if someone can try to the ‘increasing the spring fraction as compression approaches 1.0’ alternative which you (Jules) proposed, to see if it’s any better. I’m also wondering if we could construct a unit-test for Gear.cpp which runs calcForces with some different test-data (and mock ground plane of course), so that we could work on the behaviours here in a more deterministic way.

Kind regards,
James