If the user assigns their vehicle to the AI while at the same time still having triggered certain "toggle-able" controls – pretty much any mouse or keyboard event mapped to a trigger having both an "on" and an "off" counterpart – the AI work-flow may get stuck in curious ways. If, for instance, a door button is already pushed-down at takeover time, it will remain pushed indefinitely under AI control, consequently causing the wings of the door "wired" to that button to perpetually cycle (open a bit, close a bit, and so on and so forth).
Identified causes and resolution progress
The AI falsely assumes that for each trigger:xxx_on previously invoked by the user, the game will automatically invoke the corresponding trigger:xxx_off at AI initialization time. This is apparently not the case, hence the AI initialization logic should emulate these triggers itself.
The following is a list of obvious triggers to start off of (although there are likely more):
[ ] Door buttons
[ ] Driver window switch
[ ] Sun blinds
[ ] Driver cubicle door
[ ] Wheelchair ramp
[ ] "School bus driver" hazard indicator mode switch
[ ] Heating / cooling side panel switches
[ ] Indicator lever-integrated wiper turn-switch and wash button
[ ] Transmission buttons
[ ] Ignition key (rotate back to position 2 if at 3)
[ ] Speedometer-integrated digital display mode
[ ] VDV display toggle-able buttons
[ ] Any toggle-able IBIS functions
[ ] Cash desk buttons
[ ] Horn
Part of this logic (resetting of toggle-ables) is already present in ai_pre_cockpit.osc albeit for different reasons (resetting when a) "master" malfunction AI fail-safe triggered; and b) when vehicle taken over by user). It should be refactored into a single macro to reduce duplication.
While we're at it: Readme §2.15 states that "Interfering with the AI work-flow [...] should be impossible.". This is obviously not quite truthful, and should be rephrased to something along the lines of "We try to make the AI fault-tolerant to accidental user interference; this doesn't imply the user can't «break» the AI if they really want to".
User-level workarounds
Release any toggle-able controls before assigning your vehicle to the AI.
Symptoms
If the user assigns their vehicle to the AI while at the same time still having triggered certain "toggle-able" controls – pretty much any mouse or keyboard event mapped to a trigger having both an "on" and an "off" counterpart – the AI work-flow may get stuck in curious ways. If, for instance, a door button is already pushed-down at takeover time, it will remain pushed indefinitely under AI control, consequently causing the wings of the door "wired" to that button to perpetually cycle (open a bit, close a bit, and so on and so forth).
Identified causes and resolution progress
The AI falsely assumes that for each
trigger:xxx_on
previously invoked by the user, the game will automatically invoke the correspondingtrigger:xxx_off
at AI initialization time. This is apparently not the case, hence the AI initialization logic should emulate these triggers itself.The following is a list of obvious triggers to start off of (although there are likely more):
Part of this logic (resetting of toggle-ables) is already present in
ai_pre_cockpit.osc
albeit for different reasons (resetting when a) "master" malfunction AI fail-safe triggered; and b) when vehicle taken over by user). It should be refactored into a single macro to reduce duplication.While we're at it: Readme §2.15 states that "Interfering with the AI work-flow [...] should be impossible.". This is obviously not quite truthful, and should be rephrased to something along the lines of "We try to make the AI fault-tolerant to accidental user interference; this doesn't imply the user can't «break» the AI if they really want to".
User-level workarounds
Release any toggle-able controls before assigning your vehicle to the AI.