Topic: Routing bug likely caused by deleted bus stop

[Jando]

I see wrong routings in a game. The bug is likely caused by deleting bus stops and then creating new stops elsewhere. It seems that it's possible that a new stop kinda "inherits" the routings to the old, now deleted, stop. I vaguely seem to remember that I had and reported this bug a few years ago too. Can't remember whether it was considered solved back then, thus I thought to report the new occurrence as well.

The bug can be observed in this saved game: https://www.jschuh.eu/Shared/Routingbug.sve

Here a horse omnibus brings passengers from Monking station to a town a few hundred kms away to the football ground in Monking instead.

[jamespetts]

Thank you for the report. Can I ask whether the vehicles use the wrong routing consistently or only on each individual vehicle's first run to the new stop?

[Jando]

Consistently, so far 12 vehicles with passengers to another destination arrived at that football ground. Only 2 vehicles on that line so far, 6 arrivals by each vehicle.

[Jando]

It seems the wrong routing goes away on it's own at or soon after the beginning of the next game day-month.

[ACarlotti]

I think this is known behaviour - the passenger store some portion of their route using stop ids. If a stop is deleted and a new stop is created, the new stop might reuse the old stop's id without the passengers realising.

[jamespetts]

Can I clarify - do you mean the routings of vehicles or the routings of passengers/mail/goods?

[prissi]

This and the previous bug can be mended if the quickstone_tpl just continue to count on and only fills holes after reaching the maximum handle number (which is never for 32 bit). Then invalid handles will stay invalid for long times. LOnger than a month and longer than the next runway reservation ...

[Jando]

Can I clarify - do you mean the routings of vehicles or the routings of passengers/mail/goods?

In case this was directed at me: routing of passengers/mail (no cargo on that map). Passengers with destination A are being brought to destination B because destination B has inherited some information from a deleted stop that was close to destination A. Destinations A and B may be hundreds of kms apart but somehow are treated as being close to each other, I call it a wormhole.

[ACarlotti]

I think there are probably a couple of issues that are limiting the effectiveness of quickstone_tpl.

Firstly, if the number of objects stored is not much less than the size of the array (which is a power of two that starts at 1024), then when an object is deleted, it's id is likely to be reused fairly soon. This is only likely to be an issue on larger maps (e.g. Bridgewater Brunel, where the highest convoy id is 8191, which looks like it was probably purchased just before convoy 1)

Secondly, I think 'next' is currently reset to 1 whenever a save is loaded. This could easily result in small stop ids being reused in any size of game.

I think the simplest improvements will be to save and load 'next' (which I think can be done at any point in the save/load routine), and to implement your suggestion of cycling through all 65535 possible values instead of looping over a smaller array (this might mean slightly more space is needed in memory, but it's at most 1.5MB total on a 64 bit system, and it shouldn't increase the save size).