You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Analog brake seems to be always after the digital brake (another example supports this theory). So when you have the same button bound on both analog and digital brakes, the "leaving" state is always gonna be from analog - this should maybe stay as it is, even if the digital brake looks nicer, up to debate. The same could potentially happen with Acceleration and other inputs, so it shouldn't be applied specifically to brake. The transition also isn't considered with AdjustToFPS set to true, which should be the primary focus to resolve.
Here, the brake is pressed, also visually shows on the ghost, but is a 0-tick event? I don't know how to visualize that one. Perhaps always taking just the first event of the tick and ignoring the rest, like currently happening at the start of the run.
Generally speaking, it would be best to rewrite the input logic to know how to deal with same-tick inputs and such. Updates will be shared under this issue, everything should happen on a separate branch (to be made).
The text was updated successfully, but these errors were encountered:
Maybe just discard invalid values of within the same tick (negative in AccelerateReal and BrakeReal)? Because if same tick logic would be applied here, only Steer would apply.
Let's say analog button is bound to both digital and analog brake. This input set can be taken as an example:
Analog brake seems to be always after the digital brake (another example supports this theory). So when you have the same button bound on both analog and digital brakes, the "leaving" state is always gonna be from analog - this should maybe stay as it is, even if the digital brake looks nicer, up to debate. The same could potentially happen with Acceleration and other inputs, so it shouldn't be applied specifically to brake. The transition also isn't considered with
AdjustToFPS
set totrue
, which should be the primary focus to resolve.Another example what can happen:
Here, the brake is pressed, also visually shows on the ghost, but is a 0-tick event? I don't know how to visualize that one. Perhaps always taking just the first event of the tick and ignoring the rest, like currently happening at the start of the run.
Generally speaking, it would be best to rewrite the input logic to know how to deal with same-tick inputs and such. Updates will be shared under this issue, everything should happen on a separate branch (to be made).
The text was updated successfully, but these errors were encountered: