The more I think about it, then more I wonder whether the person who programs the clutch actually owns a manual car. In what world does a functioning car shift into neutral when the clutch is engaged and the gear lever is out of N? It's extremely frustrating because it means you can't shift quickly, and if you do shift too quickly, chances are you'll get into neutral. This is especially prominent in high powered RWD cars where you get a lot of wheel spin, and we all know that wheel spin = no shifting.
For the last time, that's not the clutch. The clutch is fine, let PD leave it as-is; the next thing to focus on is the gear-
selection code. Please stop complaining about the wrong thing; PD are bad enough at misunderstanding our requests without us misunderstanding our requests too.
Presumably, the H-pattern shifting was tacked onto the existing / "historical" sequential shifting that GT has always had. That has meant a gear can change only when one of two buttons is pressed, and it can only go one gear at a time (except when you press reverse, which is a special case, not unlike the current H-pattern handling) - that is, it's all "event based". This means that gear selection has only ever been a one-shot affair: press a button and the gear changes, and that's the only way it can change.
With H-pattern, that's not true, because now there's the chance that it'll fail certain conditions. Since the shifting code is all built around button presses and releases (events), what is the only way to re-select the gear you were trying for? The "button" in this case being the combination of micro-switches in the shifter gates.
What needs to happen now is the gear lever position needs to be "polled" at regular intervals by the game to make sure it's still where the game thinks it is, rather than invoking a bit of code only when the lever position changes (i.e. via the old, event-based code.) This is because the code can interrupt the shift if conditions aren't met, something like:
Code:
! on button press
IF h_shift
IF (clutch_in AND throttle_off)
DO direct_shift
ELSE
DO nothing
END IF
ELSE
DO sequential_shift
END IF
The
perceived effect, when you fail these extra criteria and land on "DO nothing", is that a gear has been changed (to neutral)
without input from the hardware - although in the code what really happens is the game's gear stays the same (neutral), despite the hardware having moved somewhere else. So you need two more button presses (first to neutral, then the gear you want) to get going again.
If polling is too inefficient or messy (event-based systems are very computationally efficient for busy systems and, in theory, tidy), then they should store two gear statuses. Namely: "current gear" and "requested gear". Then when the lever moves from neutral to, say, fourth, the game will register that the requested gear is fourth, and as long as the lever stays in fourth, that will not change. Then the game will attempt to shift (e.g. by simulating a button press, so as not to have to change too much code) as long as the current gear and the requested gear are different, and only update the current gear once the shift is successful - in the case above, this is only conditional on the throttle and clutch, which means you'd need only put the clutch in again and leave your foot off the throttle; ideally the last requirement wouldn't exist either. This is how I perceive iRacing and Live For Speed handle their H-pattern shifting (with a few extra checks for stuff like rev-matched clutchless changes, and load-modeling for sequential boxes), whilst other games don't even include the clutch as a condition, ever.
It's a simple thing conceptually, but it's remarkably technical when you get down to the details.
ive got to say it was ahead of its time but its showing its age now!
, but I still played it like a real car.
