unorthodox-paradox / omsi_2_csb_ai_enhancements

AI enhancements for CSB vehicles
1 stars 0 forks source link

AI may open doors for boarding too late, and close them too early #17

Open unorthodox-paradox opened 5 years ago

unorthodox-paradox commented 5 years ago

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.

unorthodox-paradox commented 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:

  1. A vehicle is close to a scheduled stop. m of its passengers wish to disembark. At the stop there are some passengers, n < m that wish to board.
  2. Vehicle arrives and opens both1 doors. Boarding and disembarking begins.
  3. Boarding concludes while disembarking is still in progress, so the AI decides to eagerly close the front door "to save time". At about the same time, OMSI decides to spawn, at a certain distance, some extra passengers intending to board. Those newly-spawned people begin sloooowly approaching the vehicle's now closed front2 door.
  4. Just before the newly-spawned passengers manage to arrive at the front door, disembarking completes. Witnessing the rear door as now open3, they change course towards it.
  5. Before the passengers make it to the rear door, the AI, thinking it's no longer needed open, eagerly closes it; so the passengers, yet again, turn around to return to the default entry, the front door.
  6. Passengers arrive at the front door for the second time, AI opens it, they board, and the vehicle can finally depart.

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.