Bug: Nonsense travel times

[DrSuperGood]

Attached is an image of a long distance point-to-point route from the server. This includes an example of the convoy taking the route, the two destinations listing travel time to each other and the schedule of the line.

Some of them clearly are not right.

Yerington is ~@3565,2739
Cagbury is ~@4977,2378

Using Euclidian distance this gives a length of ~1457 tiles or assuming 8 tiles per km 182 km. This agrees somewhat with the schedule displayed distance 195 km so we know that is vaguely right.

Now the ships used are only capable of traveling 15 km/h. Using the computed value above of 182 km and highschool physics formula this means that they will need to travel at least 12 hours.

Yerington says they travel ~4.5 hours to Cagbury.
Cagbury says they travel ~9 hours to Yerington.
Not only are both extremely inconsistent despite the route being mirrored, both are well below the minimum as crow flys time the convoy can possibly take to make the journey.

Now this is not the only oddity I have had with that line. When I first started it and no convoys had completed the journey the travel time was listed at over 22 hours long, which it clearly is not as the line might not be perfectly straight but it is still mostly straight. This is the same/similar travel time bug that was on the old experimental server years ago.

Why is this a problem? Well the first massively too long listing of 22 hours meant practically no one would bother to take the line as it seemed extremely slow for the distance travelled (9 km/h). Now the new massively too short listings mean that far too many people are taking the line as it appears extremely fast for the distance travelled (43 km/h and 22 km/h). The traffic is also extremely asymmetric because it seems twice as fast to go in one direction than the other.

[jamespetts]

Thank you for the report. I am about to go away for Christmas, and will not be able to do any proper debugging until I get back in a few weeks' time. I wonder whether this might be caused by the heap corruption issue? It is more likely to be a logic bug, but the heap corruption issue remains a possibility. I am afraid that all of my debugging time recently has been consumed by that, and is likely to continue to be consumed by that when I return until it is fixed. This might take a long time.

[DrSuperGood]

I have run the server at least 2 months since the last nightly and this bug does not appear to be fixed. On the server game the test line is "BUG: More departures than scheduled" of "Far East Company".

The line is set to make 3 trips per month in mirror mode between 2 destinations with 2 navigating waypoints between.

The Scheduled graph correctly shows the 6 time slots (waits at 2 stops). The Departures graph shows anywhere between 11 and 12 every month.

Additionally the reported journey times are still nonsense. Using the new "Times History" feature it is reporting...
Cagbury -> Yerington = 9:05:18
Yerington -> Cagbury = 4:22:06
Which is identical to before.

Real journey time uses the same maths as before. It should take at least 12 hours to travel as it is ~200km each direction and the ships only move at a maximum of 15 km/h.

My theory is that the 2 navigational waypoints are the cause of the problem. I cannot remove them from this specific line to test the theory because they are required to bypass the limitations of the water path finder. However there is some logic backing up this theory.

The distances reported in the line editor between the waypoints are...
Cagbury -> WP1 = 63.8km = ~4.25hours
WP1 -> WP2 = 49.1km = ~3.27hours
WP2 -> Yerington = 85.6km = ~5.71hours
total = 198.5km = ~13.23hours

For going forward, if we get {total} and subtract {Cagbury -> WP1} we get ~8.98hours, which is near enough the reported time for {Cagbury -> Yerington} of ~9.08hours.
8.98 ~ 9.08

For going reverse, if we get {Cagbury -> WP1} and compare it to the time for {Yerington -> Cagbury} or ~4.37hours one notices they are also pretty close
4.25 ~ 4.37

Further more both appear to have a similar error of ~0.11 of an hour. Hence there is strong evidence that timing is being incorrectly reset when passing certain waypoints in a schedule. It is also possible this ties into the incorrect Departures graph since each time it passes the waypoint and resets its timer it also registers a departure.

Could it possibly be the waypoint entries have somehow got hidden time tabling state attached to them? Or maybe its just a bug with the schedule progression logic when processing waypoints.

[suitougreentea]

In fact, I fixed some of odd behavior related to time measurement with waypoints, in addition to implementing Times History window.
The reason of it is that the departure data are stored in one slot before arrival station, even though it is a waypoint.
However, I should apologize that I do not confirm all of these have been fixed. I suppose that some of unfixed parts are causing the issue you mentioned.

[jamespetts]

Dr. Supergood - can you confirm whether these problems occurred in a build after the line time measurement feature was implemented?

[DrSuperGood]

No I cannot as I have no idea what feature you are talking about...

It has been like this since I made the line on 20/12/2017 and is still like this on 09/01/2018. Server game so using nightlyies. I have purposely refrained from modifying the line so this can be fixed.

[jamespetts]

Thank you for confirming. I think that I have now fixed this. Would you be able to re-test with to-morrow's nightly build? I should note that it will take a fair while for correct travel times to propagate.

[DrSuperGood]

It took considerable time for the changes to propagate but the line now shows the following times...
Cagbury -> Yerington = 13:41:00
Yerington -> Cagbury = 13:22:24
Also the Departures is much more reasonable, being 5-6 a month out of 6.

Why it is faster for a convoy in one direction of a mirrored water route than the other I do not know and that is likely another bug. However the times are now pretty reasonable unlike before. Hence I would say this problem has been fixed.

[jamespetts]

Excellent, thank you for confirming.