124.2/r11351: Pax insist on waiting for an nonexistent destination...

[FLN]

Hello  everybody

Playing on Prissis pak64 multiplayer map, I encountered this odd problem.
Passengers pile up on an airport, waiting for a plane to a destination which was served a while ago, but is not served anymore quite some time.. also see screenshots below.
Though passenger continue to arrive by the urban bus and expect to "catch" their flight.
I have no explanation for this.

I want to add, that the one existing air route, previously served "Wasserfeld * Airfield" but I modified this route midflight. Could this have caused this conundrum?

[prissi]

Make sure that there is not a vehicle left in a depot which holds this route in their schedule. There might be a lineless convoi.

Other than that, passengers will keep their next stop to get off while loaded to a bus. Only pax at stations get rerouted. So they should not accumulate unless there is still a connection.

[FLN]

Thank you for your promptly answer Prissi.

I checked all those points before and re-checked them just now.
None of these potential causes apply.

No vehicle in a depot nor a lineless one existed. I also thoroughly checked the existing route, to not accidently include "Wasserfeld * Airfield" as a stop, which it did not, neither the route-schedule nor the (one) individual vehicle-schadule did.

This is really mysterious to me.

Following I like to report what I did to resolve this pile up, or rather what worked and what did not.

• Did not work.
  I added the pretended stop in the existing fly plan, so pax would board the waiting plane. After sufficient pax had boarded for the plane to take off and it was midair, i eliminated "Wasserfeld * Airfield" from the route schedule. The plane immediately changed it's course ,as expected, but neither the onboard pax nor the ones piled up at the departure airport adapted their via-destination, even after i waited several minutes for them to update their routing.
• Did not work.
  I installed two fully new lines with new vehicles to replace the one already existing route and create the route, which so far only theoretically existed.
  My thought being, to eliminate the possibility of the sole previous existing route and plane to hold any unforeseen behavior.
  After the two new planes/routes took up their operation and the old one was fully removed (retired, deleted), I canceled the problematic line, expecting the 'Wasserfeld'-pax to finally change their minds -meaning routes, of course- which they still refused to.
• Did work!
  Finally, after reviving the "new-new" line again, and transporting all the stubborn pax to their desired destination, and cutting this route off again, and still new pax showing up endlessly with the same pattern, i removed the hole departure Airport of "Altentrup" and rebuilt it. This ultimately did resolve the hocus-pocus. 

My humble guess is that, originally "Wasserfeld * Airfield" stayed a "Direct routes from here"-entry at this problematic "Altentrup"-stop, when i modified the route schedule the first time.
Somehow it might have not been removed as potential destination when i did remove it from the line though.
I'll try to verify this with an previous autosave and then report my findings here.

Edit:
I was able to find an autosave with the original situation but my guess was false, see screenshot below.

[Andarix]

I think the stations in a schedule are not updated when the schedule is changed.


@prissi

See 'Altenbruck Airport' in your server game.

-> waiting passengers to 'Alvesstede Airfield'
-> 'Alvesstede Airfield' is not connect

[prissi]

As there have been recently some schedule changes, maybe there was an error when resuming updating the schedules. However, reloading a map should trigger a rerouting. I will have a look.

But I also saw once passengers at a station wating where there is no direct connection.

[prissi]

Ok, the step for all halts was messed up. r11360 fixes this

Time for a patch release with the crashes and this.

[TurfIt]

r11360,11361 is completely busted. Only ever reconnects/reroutes 1024 units in the first few halts in the list. And rebreaks Regression: passengers are not boarding.  My comment you removed  "// always iterate all halts to properly reset served halts" was there for a reason...

[prissi]

It did not iterate many halts at all. Like ever, no matter how much rerouting was started. Breakpoints that I set were never reached.

The reset halts indeed handled incorrectly missing, sorry for misunderstanding the comment. r11363 fixes this as well by taking it out of step() and into step_all(), saving a lot of function calls and switches.

[ceeac]

The automated test for transporting mail is still failing while the test for passengers seems to succeed:

Code Select Expand

00:00:40 Script: Print: [144/195] test_transport_mail_valid_route
00:00:40 Script: Error: <error>
00:00:40 Script: Error: <st>Error: [Assertion failed, '0 == 1' was not true]</st>
00:00:40 Script: Error: CALLSTACK
00:00:40 Script: Error: <em>* FUNCTION [ASSERT_EQUAL()] <br>* addons/pak/scenario/automated-tests//test_helpers.nut
00:00:40 Script: Error: * line [27]
00:00:40 Script: Error: </em>
00:00:40 Script: Error: - - LOCALS
00:00:40 Script: Error: - - - [err] INSTANCE
00:00:40 Script: Error: - - - [exp] 1
00:00:40 Script: Error: - - - [act] 0
00:00:40 Script: Error: - - - [this] TABLE (389 entries)
00:00:40 Script: Error: <em>* FUNCTION [test_transport_mail_valid_route()] <br>* addons/pak/scenario/automated-tests//tests/test_transport.nut
00:00:40 Script: Error: * line [181]
00:00:40 Script: Error: </em>
00:00:40 Script: Error: - - LOCALS
00:00:40 Script: Error: - - - [cnv] INSTANCE
00:00:40 Script: Error: - - - [to_halt] INSTANCE
00:00:40 Script: Error: - - - [from_halt] INSTANCE
00:00:40 Script: Error: - - - [depot] INSTANCE
00:00:40 Script: Error: - - - [pl] INSTANCE
00:00:40 Script: Error: - - - [this] TABLE (389 entries)
00:00:40 Script: Error: <em>* FUNCTION [run_all_tests()] <br>* addons/pak/scenario/automated-tests/scenario.nut
00:00:40 Script: Error: * line [43]
00:00:40 Script: Error: </em>
00:00:40 Script: Error: - - LOCALS
00:00:40 Script: Error: - - - [num_tests_done] 143
00:00:40 Script: Error: - - - [error_msg] NULL
00:00:40 Script: Error: - - - [num_tests] 195
00:00:40 Script: Error: - - - [func_name] "test_transport_mail_valid_route"
00:00:40 Script: Error: - - - [test_func] CLOSURE
00:00:40 Script: Error: - - - [i] 143
00:00:40 Script: Error: - - - [this] TABLE (389 entries)
00:00:40 Script: Error: <em>* FUNCTION [start()] <br>* addons/pak/scenario/automated-tests/scenario.nut
00:00:40 Script: Error: * line [95]
00:00:40 Script: Error: </em>
00:00:40 Script: Error: - - LOCALS
00:00:40 Script: Error: - - - [this] TABLE (389 entries)
00:00:40 Script: Error: </error>
Killing process (test failed)


[prissi]

Sorry, the rerouting/reconnection finished prematurely, also in my correction.

The scenario worked by luck, i.e. that the timing for mail and goods was so that reconnection was finished by not yet rerouted. A call to start_halt->recalculate_status() was missing in the goods and mail delivery part (which was implicit from pax_add_happy).

To get it timing independent, I added a function to know if the rerouting has finshed and added the missing call to the goods adding routing.

Hopefully all fixed in r11365

[Andarix]

online game prissi

The routing takes strange paths.

An airport routes via a bus stop.

[prissi]

Yes, I know the routing in the stable is broken. First, it should not add these routes at all. And second, when reconnectiong, these passengers should be rerouted. That never happens for quite some stations in the stable.

The problem is that once a wrong via_halt has been added, future pax to this destination will take that via_halt from the existing one. Usually, this is solved with the next schedule change of reloading, but the stable did not iterated over it.

I have run several debug games, but I could not catch ever adding a wrong via_halt. However, search_route suggests that under some circumstance the via_halt of return pax may be wrong.

Anyway, a normal save-load cycle or extending one stop or chaning one schedule schould solve all thos outstanding wrong routing in the nightlies.

[Andarix]

online game prissi - 124.2.1

I removed stops from a line. The people waiting have not been rerouted yet.

[FLN]

In this same multiplayer map (124.2.1) as Andarix, I just witnessed a new strange behavior.
Adding a new (airplane) route to alleviate a pile up at an airport/train-station (Altenbruck Airport), the existing waiting pax, would not split in to two "waiting groups", as expected.
Even though ~700 pax now could take a direct flight to their destinations local airport (Wasserfeld * West-Port), they hang on to their previous route. This "old" route eventually leads through this same local airport.
Basically, they loyally and patiently wait for an detour route, instead of "acknowledging" there is a new non-stop route.

Further, I'm not sure, or rather I can't tell really, if all pax generated after introducing this new line truly choose to now take the direct flight, since the pax deficit (600:40pax) between the two flight directions (2 point route) persists unchanged, since the installation of this direct route +1 year ago (And yes, I'm loosing money with this line, as it has a max waiting time at both halts).
It rather seams, that still more (=new) pax accumulate to the old, original route's waiting pile...

[prissi]

To Andarix: There seems to be a line on top of it. That counts as connection too.
The second case needs investigation; it could be that rerouting of waiting passengers is only done if there is no route.

[prissi]

Indeed, this was related to an uncomplete fix. SOmehow, I forgot to submit the second half of my corrections. r11368