Open unorthodox-paradox opened 5 years ago
This is an idea for resolving a sub-case of the general problem, specifically concerning boarding attempts of late-arriving passengers and the AI's inability to successfully / timely / realistically accommodate them. It is attached for informational purposes.
Consider the following sequence of events:
Naturally when this happens it appears quite unrealistic. While the AI has good intentions (saving time and appearing "smart"), its "enhanced" behavior turns out actually costing it more time and realism than the default "dumb" behavior (lazily leaving all doors open until departure time) would have.
As discussed in the general problem statement, there is to our knowledge no robust solution that works in general. The particular case, however – passengers intending to board walking back and forth between doors – could be addressed by flagging the front [entry]
s {withbutton}
, effectively preventing passengers having already arrived there from undertaking any further wasteful detours.
So why not do just that? Well, first and foremost, it would limit user experience. When themselves controlling the vehicle, the user might for instance purposely prefer that passengers board from the rear door (e.g. due to the front door tending to suffer from blocking malfunctions); but that would no longer be possible after passenger arrival at the front door. Secondarily – and noteworthy particularly in AI mode – passengers still walking towards the vehicle would still be prone to approach the rear door, when disembarking had previously taken place, potentially in vain.
1 A 2-door vehicle is assumed for the purposes of this example. The main idea would hold for 3-/4-door vehicles as well, however.
2 The front door is always the default [entry]
(as per the passengercabin.cfg
).
3 As per door_xxx.osc
, the rear door is only made available for boarding when nobody is currently disembarking, to prevent "messy" concurrent boarding and disembarking.
There's a certain naiveté in how the AI currently handles lazy opening and eager closing of doors to accommodate passenger flow (boarding and disembarking):
Due to the AI (the scripts) having neither access to the editor-assigned trip profile entry corresponding to the current stop, nor knowledge about passengers that will ultimately attempt to board (until they actually arrive at its doors), there is no solution that will work in general. At any given regular (non-prolonged) stop, the AI simply has no idea why it has been told to stop. It could be due to the stop having been marked as "mandatory" (("always +) await scheduled departure time"), or due to there being passengers wishing to board. And to make matters worse, OMSI "likes" spawning passengers just before, or after already having instructed departure – of course without ever explicitly letting the vehicle know. All the AI can tell beforehand is whether there are going to be disembarking passengers. Besides that, all it can do is guess. And while in certain cases (delayed arrival + non-prolonged stop + no disembarking passengers) it could do so with increased chances of success, it would fail rather miserably in the general case.
The sole workaround employed at present is to not eagerly close doors (provided the environmental conditions are favorable) at prolonged stops, since the likelihood of further boarding passengers is greater there.