AI passengers do not adjust the state of the folding passenger windows.
The dynamic scheduled stop departure delay tends to be lower. Furthermore, the probability of departing prior to the front door having fully closed tends to be higher.
The probability of permanently leaving the front door open at scheduled stop departure time tends to be higher.
Identified causes and resolution progress
OMSI does not communicate seat (passengercabin.cfg[passpos]) occupation status (obtained via GetHumanCountOnSeat callback) to unfocused vehicles, with the potential exception of seats having been occupied at an earlier time, when the vehicle used to be user-focused. Passenger movement (evaluated via GetHumanCountOnPathLink) also doesn't work in such vehicles.
For passenger-conducted window adjustment in unfocused vehicles, a possible, although not really effective workaround might be to rely solely on humans_count in unfocused vehicles, which, unlike the aforementioned callbacks, appears to always remain "in-sync" with the current number of passengers on board. Due to the refactoring cost far outweighing the benefits, however, such a workaround is unlikely to be implemented in a future version.
Likewise, for the affected stop work-flow delays (door closure, departure), and open front door departure probability, the weight of humans_count as a contributing factor could be increased in unfocused vehicles. This is rather simple to implement and is thus a likely candidate for inclusion in a future version.
Symptoms
In unfocused AI vehicles:
Identified causes and resolution progress
OMSI does not communicate seat (
passengercabin.cfg
[passpos]
) occupation status (obtained viaGetHumanCountOnSeat
callback) to unfocused vehicles, with the potential exception of seats having been occupied at an earlier time, when the vehicle used to be user-focused. Passenger movement (evaluated viaGetHumanCountOnPathLink
) also doesn't work in such vehicles.For passenger-conducted window adjustment in unfocused vehicles, a possible, although not really effective workaround might be to rely solely on
humans_count
in unfocused vehicles, which, unlike the aforementioned callbacks, appears to always remain "in-sync" with the current number of passengers on board. Due to the refactoring cost far outweighing the benefits, however, such a workaround is unlikely to be implemented in a future version.Likewise, for the affected stop work-flow delays (door closure, departure), and open front door departure probability, the weight of
humans_count
as a contributing factor could be increased in unfocused vehicles. This is rather simple to implement and is thus a likely candidate for inclusion in a future version.User-level workarounds
None available.