[11.18] Journey Time Calculation

[Sarlock]

The problem with a new online game is all of the new issues (or "features") that we discover

I connected a cross-map passenger service between Monkington @617,612 and Upingpike @6347,1607.  When I made the connection, it calculated the travel time to be 26:00 minutes, which of course is way, way too low.  The distance between the stations is 767km.  It should be about 50 hours.



I waited until a ship made the cross-map journey, which takes about 8-9 months, thinking that it would recalculate on arrival.  It did not.  This line has been running for about one game year now.  Further, the revenue was much lower than expected, only about 9,000 for a half full ship.  The same journey to a city 6 game hours away yields about 15,000 for the same trip/load.  I would expect more around 100,000 revenue for the trip.  Is revenue based off of this number?

I connected two even more distant cities with a passenger service, Feathervale @6786,1144 and Harhall 473,566 and came up with another odd journey time of 7:43:06.  At 818km this is a 9 month (60 hour) journey.



And then I started looking at long distance freight connections:



This one is impacting my ability to load much on the route as the in transit calculation limits me to one partly loaded ship per round trip.

But then this one is fine:



The inconsistency is odd.  I'll keep researching it to try and hone down the cause but if you have any insight at this point it would be helpful.

[jamespetts]

Thank you very much for the report - any more insight that you can give into what is distinct about the circumstances in which this does and does not occur would be most welcome.

[Sarlock]

The passenger line finally recalculated, after over 12 months and 5 completed round-trip journies.  And revenue has been increased proportionally.

When does it generally do its recalculation?  Perhaps it's the initial calculation that seems to be incorrect.  Will research further.

[jamespetts]

It will calculate the journey time initially based on the convoy's average speed, or, if that is unavailable (if I recall correctly) half its maximum speed. When journeys are completed, the pathfinding system will use the actual recorded journey times, but only when it next refreshes the routes. This should happen every month at the least. What you are describing is not intended behaviour, so any more insight into the circumstances in which it does and does not arise would be welcome.

[Sarlock]

Update:

Did some testing on a blank map and I think there's an overflow error happening on initial journey time calculations:




I have also included a copy of the save game to take a look.  I think it's just a simple overflow of the variable used to do the calculation.  It probably only cropped up now due to the sheer length of the map we're using.

[jamespetts]

Thank you very much for that - that is most helpful. I will look into this when I get a chance and see if I can fix it.

[zook2]

This may or may not be connected with this bug:

For locomotive trials I set up a race track with three identical and parallel lines, no curves, a few slopes, no stops between start and finish, length 49 km. One train took 1:23 hours for the total trip (including one reversing at the finish stop), another 1:17, but the third had 3:20 hours recorded, despite being the second fastest. Trip times were recorded within (game) minutes from each other. I watched them come in, so the recorded time is definitely off in this one case.

I'll run the tests again to see if it can be reproduced.

[jamespetts]

If you can reproduce this, I should be very interested to see a saved game for this configuration to run my own tests.

[jamespetts]

I have managed to track down the fault in Sarlock's saved game - it was indeed an integer overflow on calculating the initial journey times before point to point data are accumulated. Fixing the overflow, however, means capping recorded journey times at a maximum of just over 109 hours even if the actual journey time is higher. Changing this would require moving to a 32 bit model for storing journey times, which would take quite a lot of work, and would only be sensible to do in conjunction with a major release.

I should be interested to know how likely it is that journey times of significantly over 109 hours are likely to be encountered.

[zook2]

Here's my current racing track, at the southern map edge:
http://freakshare.com/files/0toc6lth/Racing.sve.html

The wrong count I mentioned above was due to Average Trip Time being recorded at the beginning of a new month, even in mid-trip when there was no complete trip made yet: But it only happened to one out of three racing lines.

[Sarlock]

I think a cap at 109 hours is probably just fine.  Journey times of that length will only occur in the early game with slower vehicles and you'd only be using long distance shipping for this distance, either the East Indiaman or the Brig, which both have a speed of 15km/h.  I think we're safe to assume that no player will attempt a 6,000 tile road journey in 1750.

The example I gave, of a journey distance of 992km (7,936 tiles), gives us a total estimated transit time of 141 hours.  Once the journey is complete, however, that will revise itself to ~66 hours as the ship will be moving at 15km/h for the entire journey except for a small change in speed at departure and arrival.

Capping it at 109 hours will work fine overall as the readjusted speed will be well below the limit and be fine.  It may become a factor on maps over 12,000 wide but that's a pretty limited application.  And even then, a cap of 109 hours will favour the player slightly on such a map as passengers may be willing to take a 109 hour journey that is 15,000 tiles wide because it implies a journey time of just over 15km/h.

Does the recalculated journey time (once we have real data from a completed journey) require the 109 hour cap as well?

[jamespetts]

That is a helpful analysis - thank you.

The cap of 109 hours applies both to the measured and estimated time, as the journey time data are all stored as 16 bit integers with a maximum value of 65,335, and the units are tenths of minutes (and 65,335 tenths of minutes is about 109 hours).