[Feature request] Washout Recovery Control and Center-Locking Logic

[GrupoWebex]

Description:
Improve washout behavior by allowing users to define a threshold (in degrees or %) where washout does not activate.
Also, add the option to lock washout recovery at center (0°) to prevent overshooting or inverting the direction of motion.

Problem scenario:
Washout currently moves the rig gradually back to center before the actual game physics have finished their transition.
So when the game sends a recovery motion (e.g. from +3° to 0°), and the simulator is already at 0°, this results in a false motion from 0° to -3°, causing unrealistic movement inversion.

Why this matters:

• This behavior breaks immersion and realism, especially in oval circuits or sustained G-force situations.
• If washout could hold within a configurable dead zone and compress the recovery without crossing the center, it would:
  • Preserve the physical simulation of G-forces more accurately
  • Avoid artificial rebounds or reversed motion
  • Enhance the natural feel during long, progressive transitions

[SHWotever]

Hi ! 0 centered resets , or locking would create weird "velocities" changes. Overall in a simple example : inversion roll from -3 to +3 with a static roll velocity. that would mean it would not show much movement when approaching to 0 then once crossed 0 it would "release" the washout and then suddenly start to compensate. The overshooting is indeed something induced by washout. But platform uneven/unexplainable velocities changes false cues are way worse than a temporary wrong orientation. I think the strongness of the washout recovery could be increased based on the distance from its current position. This would not remove any overshoots but always react stronger during fast movements making the washout correction too far away from the new position last shorter preserving the contrast and reducing overshoots. Let's imagine that this strategy we could have a 0.5° overshoot instead of 2° in the previous examples (The values are just a rough guess, but that's just to illustrate the idea.

[GrupoWebex]

Sure, Its a great idea. Sure you have oportunity to test any changes, so your initial/pro opinion is really good. It will be better for sure.

To clarify the threshold idea with better detail and logic:

Let’s say we define a washout threshold of ±5°. This means:

• The washout should not activate at all while the telemetry remains within ±5°.
• Once the telemetry exceeds that threshold (e.g., moves to +6° or -6°), the washout begins to act — but only recovers back to the edge of the threshold (e.g., back to ±5°), never forcing it all the way to center (0°).

Even if the telemetry continues to oscillate beyond the threshold (e.g., between +5° and +10°), the motion platform would follow the movement within the safe zone, reflecting changes as best as possible while staying limited to ±5°.

• This prevents the washout from overriding the motion with a full return to 0°
• Maybe minimizing some false or reversed movement when telemetry move on return.
• Maybe if range continue between +5° and +10°, do a reverse washout to +5°until telemetry go below

Other option could be great if this threshold behavior could be progressive:

• When just beyond the threshold (e.g., 5°), washout acts slowly or gently
• When much farther out (e.g., 10° or more), washout acts more strongly

Thanks again for considering edge-case tuning options like this — it would really help refine setups with more control and smoother motion blending.