When AI takeover occurs at non-zero velocity, and the wheelchair ramp has been dragged open by the user, the AI is unable to reset it back to its closed position.
Identified causes and resolution progress
The logic relied on for handling the case of non-zero velocity takeover coincides (out of reasons of practicality) with that of "post-hibernation adjustment" – when an AI vehicle, that had previously gotten "frozen" by the game due to having exited the observing user's loaded tiles, gets re-spawned. In both cases the vehicle has to adjust its state as fast as possible, to avoid blocking traffic or generally appearing weird / out of place. Unfortunately this also translates to there not being enough time for ramp adjustment to be successfully conducted: The second door, even if open, gets immediately closed, without allocating any delay "buffer" necessary for dragging the ramp closed first.
The solution is to enable the closure condition for the second door to tell the difference – takeover vs. post-hibernation – such that the exhibited behavior is the same as exhibited in the case where AI takeover occurs at standstill, i.e., opening the second door if closed, then closing the ramp, then closing the second door. There are however certain subtle implications:
The expectation of becoming departure-ready instantly (within a single frame) would be broken. Lots of code depends on that expectation.
The vehicle would have to stop in order to be able to open the second door (and preferably activate the hazard indicator mode). Would following AI traffic tolerate that?
Due to the number of changes that would be required, the entire stop / door / stop brake work-flow would have to be thoroughly retested.
Alternatively, the wheelchair ramp could be closed "automagically". While not quite realistic, this could prove being a reasonable course of action, given that a) the aforementioned realistic workaround would probably still feel contrived, b) the aforementioned realistic workaround's cost-to-benefit ratio is high, and c) it is after all the user's fault – the problem can simply not occur unless the user provokes it.
User-level workarounds
Either a) close the ramp before assigning your vehicle to the AI, or b) stop the vehicle before assigning it to the AI, for the AI to close the ramp for you.
Symptoms
When AI takeover occurs at non-zero velocity, and the wheelchair ramp has been dragged open by the user, the AI is unable to reset it back to its closed position.
Identified causes and resolution progress
The logic relied on for handling the case of non-zero velocity takeover coincides (out of reasons of practicality) with that of "post-hibernation adjustment" – when an AI vehicle, that had previously gotten "frozen" by the game due to having exited the observing user's loaded tiles, gets re-spawned. In both cases the vehicle has to adjust its state as fast as possible, to avoid blocking traffic or generally appearing weird / out of place. Unfortunately this also translates to there not being enough time for ramp adjustment to be successfully conducted: The second door, even if open, gets immediately closed, without allocating any delay "buffer" necessary for dragging the ramp closed first.
The solution is to enable the closure condition for the second door to tell the difference – takeover vs. post-hibernation – such that the exhibited behavior is the same as exhibited in the case where AI takeover occurs at standstill, i.e., opening the second door if closed, then closing the ramp, then closing the second door. There are however certain subtle implications:
Alternatively, the wheelchair ramp could be closed "automagically". While not quite realistic, this could prove being a reasonable course of action, given that a) the aforementioned realistic workaround would probably still feel contrived, b) the aforementioned realistic workaround's cost-to-benefit ratio is high, and c) it is after all the user's fault – the problem can simply not occur unless the user provokes it.
User-level workarounds
Either a) close the ramp before assigning your vehicle to the AI, or b) stop the vehicle before assigning it to the AI, for the AI to close the ramp for you.