Well my wheel may have been a bad example. As I have posted elsewhere,
I'm getting rid of it. But the thing I think is critical for setting
latency is by how the car handles, not by running over curbs as some
people recommend. If a person bought an FF wheel for GPL I would think
they most likely bought it for the purpose of being able to feel the
aligning torque of the front tires. That's what gives you useful
feedback on the handling of the car. As such you should set the latency
so that you are feeling the aligning torque timed correctly. Aligning
torque has nothing to do with hitting bumps. As it says in the GPL
readme file, the correct way to set the latency is to weave back and
forth going down a straight, and increase the latency until the torque
on the wheel is in phase with the wheel motions. That's why they ended
up with 85 ms as the default, based on the MSFF wheel. I had to use 100
ms with my POS LWFFGP. I have seen LWFF users set it as high as 125 ms
using a similar method. And yes that much correction does cause other
problems, that's an unfortunate weakness of the way Papy does it. You
can make that same behavior happen in N4 by using similar FF settings
and driving one of the road courses with the "<fast>" setup. MGI
figured out a way around this in NASCAR Heat. They use a centering
spring at zero steering angle, and use the aligning torque model at
non-zero angles, with the two blended together linearly in between.
Unfortunately that just means more variables to tweak, but it's not bad
if you get it set up right.
> > It works but unfortunately with latency set to 0 you will never be
> > feeling the forces at the correct time. This not only makes it
nearly
> > impossible to use the wheel to tell when you are on the edge of the
> > traction circle, it also makes it more difficult to recover from a
spin
> > since the forces can get 180 degrees out of phase with your
corrections.
> This very much depends on how big the delay is to begin with.
> And even when the delay is known (it would be _very_ interresting
> to see some hard figures on this), the game can only predict
> forces from known state, so the prediction is never able to
> compute exactly the correct forces anyway.
> I have always used very small delay values (less than 50 ms) since
> a to large value will be just as bad as a small one regarding
> getting the forces 'on time' and on top of that it will add
> those artifacts resulting from the prediction being wrong.
> About the MOMO wheel and GPL, I have noted three kinds bad forces:
> 1/ the good old 'bad predictions': nothing to do with the MOMO,
> fixed by reducing delay in core.ini (don't bother tweaking it
> into the microseconds, we are talking about delay compensation
> in a simulation with a ~3 millisecond time step here, I doubt
> any value less than that is ever possible to distinguish from
> a plain 0.0 value)
> 2/ severe spiking when moving the wheel: fixed by the beta drivers
> 2/ constant weak spiking/oscillations: fixed by reducing damping
> to 50% or less in the game controller setups (the damping force
> seems to be sensitive for noise in the potentiometer readings)
> _
> Mats Lofkvist GPLrank -10 and proud of it, Tom ;-)
