Odd routing in Exp 11.12

[ekhmuel]

Hello, a small problem has been noticed.




I have a factory in London (L), and two shops to which it is linked, one in Glasgow (G) and another in Inverness. (I)


A ship (A) goes back and forth between L and G and another (B) sits in London until full then goes to I. (This is best as there are multiple factories and farms near L all producing goods to be shipped down to I and it's environs).


There is no way to get from G to I directly. In fact ship A  is the only vehicle to call at G. So there are no 'alternative routes'.


Great. The goods (Hardware in this case from Ironworks) will be produced then sent to their valid destinations.


What actually happens is that the Hardware is produced in L then shipped to G in ship A.


Then shipped back to L in A. (Sometimes it unloads then loads back up, sometimes it unloads, goes away and picks it back up on the next trip).


Then put on ship B to finally get sent to I.


So it goes L -> G -> L -> I !!!!




I've tried moving the docks and everything, but it keeps happening.


Ekhmuel

[ekhmuel]

Extra bit:

This happens to at least one place/combo somewhere in every game I've played on 11.12.

[jamespetts]

Thank you for your report. Two things: the latest version is 11.13 - have you tried it in that version to see whether it is still an issue there? Secondly, can you upload a saved game in which this occurs so that I can investigate? Thank you!

[Jando]

Just a wild guess from me: do you have long waiting times for piece goods between L and I in your stations' details screen? Most of the strange routings I've seen (in Exp 11.13) seemed related to long waiting times.

[ekhmuel]

I'll try 11.13 first (simplest solution)

Also with waiting times:

I did wonder if it was a new feature whose development I didn't notice (until now).

It is 'common' (sorry for a purely qualitative description) that these occur about overcrowded docks (which I use as 'central loading depots'). I wondered at first if it was an attempt to 'dump' excess goods in a nearby depot to remove the overcrowding. So I went to buy a dozen extra L - > I ships to get plenty of capacity in the line. Which rather disproved the notion as all these (yet to load) ships simply sat in dock (waiting for the stuff to come back from Glasgow).

It is difficult to tell exactly, but London Docks has somewhat large waiting time - 5 hours compared to typically 2 1/2 but another (without any problems) has 12 hours.

Will let you know.

[ekhmuel]

https://www.nortonzone.com/pickup/90883?key=OXYN5JqWrfCLC7tMo3KL4s5d_TTV1quFoGDR2iF6GGEjkeSZaKQGCUZY7qJK8Nxr&src=url


It should be zipped up.



Hello: This is a slightly different one to the situation described, but is quicker to show you through. It's the same problem though. I've removed all the non-concerned stations, etc. (The original one I said would ahve taken days to 'strip it down')


If you look at Basingstoke Docks you will see that the Hardware collected is going to Newcastle (Campbell's Hardware) via Walpole Cross Keys. Meanwhile, What is already sitting at Walpole Cross keys is now coming back the other way awaiting collection to go back to basingstoke. The Final destination is near the bottom of the map at Truro Red Road Hardware.


PS I actually name the sites themselves, not just the stations.


Paul

[ekhmuel]

As an extra note: The Wrought Iron (for example) from the Ironworks at Basingstoke (which was to go to Oldham and Tonbridge - you can see the remains of some canals running from the coastlines near these towns) didn't experience these problems - i.e. it didn't send it all to one or the other then back again. It only seems to happen for some lines and destination combinations.

[jamespetts]

Thank you very much for that saved game. I am investigating now. The problem is very odd: what appears to be happening is that hardware bound for Truro originating in Basingstoke is sometimes being routed via Walpole, from where the only route to Truro is back to Basingstoke. However, this does not happen consistently: most of the time, the hardware is routed directly to Truro. This is odd, as the system is such that there is only one next transfer at any given intermediate stop for any given destination: this is stored in a hashtable and set whenever goods are added to a stop. A general problem with the routing would simply set all the goods to the wrong destination, but this is not what is happening here. I am not even sure how some goods are ending up with a different next transfer to the others. I am testing at present, but the conditional breakpoint that I am using is making it run exceedingly slowly, so it might be a while before I make any progress.

[jamespetts]

Hmm - I could not get the breakpoint in question, which was supposed to catch the moment when hardware destined for Truro was loaded on the ship headed for Walpole, to trigger. Further, after running the game for a long time (it is now December 1750, which is a long time given your 51-hour months), the issue (and the mis-routed goods) seems to have disappeared and will not reappear. It is possible that this is an issue that involved mis-routed goods left over from having been generated in 11.12 which are not generated afresh in 11.13. Was this map originally created in 11.12?

Edit: Actually, the problem did not disappear on its own: I had fixed it without realising it because my testing of an earlier attempt at a fix had not tested the correct condition and I had assumed that the change had no effect. I have now pushed a fix to the 11.x branch on Github.

The issue was caused by an integer overflow in the path explorer (routing system). Because the journey from Basingstoke to Truro by going to Walpole and back again first takes longer than 65,335 tenths of minutes, the number storing this value wrapped around to zero when it got past 65,335, producing an artificially low number, lower than the correct route of going directly from Basingstoke to Truro.

I have fixed this by changing a single temporary variable from 16 to 32 bits. However, this is not a complete fix. It works only when (as here) the only routes that are longer than 63,335 tenths of minutes are reject routes because there are shorter routes available. The problem will still occur (in probably a different form) if the shortest route somewhere to somewhere else is longer than 65,335 tenths of minutes. Fixing this would require totally changing the system for storing journey times from 16-bit to 32-bit, which would be quite a bit of work. I did make a start on that, but rescinded it when I realised that it would require substantial changes to a part of the code to which I have made substantial changes on my passenger-generation branch, which would require duplicating the work.

One question which remains is whether, especially in early eras, a genuine shortest journey which, including waiting times, is longer than 65,335 tenths of minutes is likely to arise. If it is, the full re-casting of the journey time system into 32 bit will have to be done at some point.

[jamespetts]

This should now be fixed in 11.14.