News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Problem Regarding Average Speed and Revenue of Long-Distance Trains

Started by dave62, July 19, 2010, 06:02:50 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

dave62

Firstly, thanks very much for all your work on Simutrans Experimental.  It really is a great improvement on Simutrans Standard.

I am having a problem with long distance rail travel.

Sometimes these trains make a very good profit , but at other times make almost no revenue at all resulting in a large loss for the line.

I understand that average speed determines the revenue of the journey but some journeys the average speed is very small or in some cases zero.

My guess is that there is a problem with journeys that take more than one month to complete, hence the zero average speed and fluctuations in income.

As this is a problem more easily shown than explained I have a save game here

    us (site down, do not visit) ]/files/get/1kxYRNPf1f/dave62.sve]http://files.[ simutrans [dot] us (site down, do not visit) ]/files/get/1kxYRNPf1f/dave62.sve

Specifically the problem routes are Chester – Norwich and Liverpool – Stoke-on-Trent, but the average speed graph of the Carlisle – Chester train also shows the same pattern, but always makes a good profit.

I hope that I have explained this well enough, but please let me know if you require any clarification.

I'm running Simutrans Experimental 8.2 and pak128.Britain Experimental 0.6 on Windows XP.

jamespetts

Dave,

thank you very much for your bug report, which, if I may say so, is a very well-written and helpful report. I have found the problem that you describe and fixed it in my development code (on the "-devel" github branch). The fix will be included in the next version when it is released.

The problem originated, as you surmised, from when vehicles took longer than a month to complete their journey: there would be a whole month when they would not call at any stations or stops, and therefore no average speed would be recorded, putting the average speed at 0. Given that the revenue is based on the previous month's average speed, this is a problem. I have fixed it by checking at the end of each month whether the previous month's average speed is zero, and, if it is, setting it by reference to the month before last's average speed. This put an end to the troublesome fluctuations in the average speed graph. Thank you very much for reporting that one!

Incidentally, your saved game was most interesting. It shows, I think, that I need to raise the passenger level (which I have already done with the next release of Pak128.Britain-Ex), and also provide more in the way of suburban rolling stock and motive power in the first half of the 20th century: that is work in progress!

Also, incidentally - welcome to the forums!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

dave62

James,

Thank you for your very kind and prompt reply.  I am glad that my report was of some use to you and that the problem will be rectified in the next version.

The save game that I uploaded for this post was started in 1830 and I began by surrounding the then much smaller cities of Preston, Swansea and Manchester with suburban rail to minimize the use of slow horse transport with it's lack of capacity.  I have, with previous games used solely horse transport in individual cities, but encountered problems with over capacity stops and congestion due to the amount of horse vehicles needed.  The above cities have industries in common and this gives passengers a reason to travel between them due to their work being in one of the other nearby cities.  I certainly did not lack for passengers.

I did not make much money until the "Jenny Lind" and later the "Terrier" tank engines became available, but after that I was able to make enough profits so that expansion became possible.  Suburban rail was not necessary later on as it was more efficient to use trams, and later motor buses.

I used a similar strategy with the more northerly cities and eventually had the finances to connect them to the existing network and then, of course, discovered the problem I had to contact you about.

It does seem that it is possible to make a reasonable profit, on a passenger only network at least, without too many problems, and this is playing fairly conservatively – the south east and some of the north west are still not connected - so I don't find play balance too much of an issue at the moment.

Anyway, I've drifted a little too far off of the original topic, so thank you for the kind welcome and I'll continue to play and enjoy this excellent game.

Best wishes
Dave Gilmour

jamespetts

Dave,

thank you for your reply: it is very useful indeed to know how people's games progress! It's especially interesting, since you've been playing for over 100 years, which is one of the longest -Experimental games that I've seen so far.

As to the passenger density - to be realistic, there should be enough capacity for you to need to have double track on all your main lines and suburban lines, and quadruple track on your very busiest lines in the largest of cities, especially where suburban and express traffic mix.

The experience that you describe with suburban rail is very gratifying for me to see, as that is exactly how things went in reality in all but the largest and most crowded cities, where trams and later trolleybuses gave suburban rail stiff competition from the beginning of the 20th century onwards.

I shall be very interested indeed to see how you get on with the next 50-100 years, and especially how your passenger network copes with the rise of car traffic (if you want to make that more of a realistic challenge, go into public player mode (CTRL + P) and build some good quality roads between all the towns, then revert to ordinary player mode again (CTRL + P again): you will hopefully see an interesting balance of competition from private cars and congestion (the latter of which encourages use of your transport)).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

dave62

Hi James,

Glad that my game report was of some use to you.  This current game is the longest Experimental game that I have played so far.  I have started a few games with previous editions of Experimental but the version 8 series game is the first that I've been able to get this far, making a reasonable profit, without resorting to the freeplay button.  That said I was able to learn much from those previous efforts, but I have got the most out of this current game in terms of enjoyment and increasing my knowledge.

As I mentioned, I have been playing this game pretty cautiously, trying not to make any huge errors,  so I've barely scratched the surface of what's possible in this game, but as I now have a decent bank balance, I'll see if I can do as you suggest to make the game more challenging, if not in this game then certainly in my next.  The replayability of Simutrans Experimental is certainly one of its strengths. The upcoming increase in passenger density certainly looks as if it will give the player much to think about.

I'll push this game on a bit more and I'll let you know how it develops in a week or two.

Thanks once again for taking such an interest.

Best wishes
Dave

fbfree

Quote from: jamespetts on July 19, 2010, 07:00:08 PM

The problem originated, as you surmised, from when vehicles took longer than a month to complete their journey: there would be a whole month when they would not call at any stations or stops, and therefore no average speed would be recorded, putting the average speed at 0. Given that the revenue is based on the previous month's average speed, this is a problem. I have fixed it by checking at the end of each month whether the previous month's average speed is zero, and, if it is, setting it by reference to the month before last's average speed. This put an end to the troublesome fluctuations in the average speed graph. Thank you very much for reporting that one!


I don't believe this is the ideal solution.  It also doesn't allow for the correction of a poorly calculated average speed in the first month of travel.  This can compound other bugs, such as http://forum.simutrans.com/index.php?topic=6894.0  It also fails to take into account when a convoy has to travel along a section with a low speed limit in the first month, or that it's having to accelerate over that month.

Would be possible to implement a solution that timestamps the convoy with the time it last departed a stop, then calculates average speed once it arrives at the next stop?