News:

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

11.9007 feedback and small bug

Started by Michael Hauber, June 28, 2013, 12:24:56 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Michael Hauber

After compiling 11.9007 of the ncn devel branch I have a working passenger network with no obvious bugs.  Save game is uploaded at http://simutrans-germany.com/files/upload/Keep_going.sve

The small bug is a failure of one city out of many to expand its city limits despite no obvious obstacles to its expansion.  This is Duckingham.

I have built a railway network roughly in a grid pattern with supporting bus services.  The game is almost exactly at break even - I started at a loss, and with 250m credits, and played until growth got me to break even point.  Infrastructure maintenance is still a large portion of my overall costs at 71% of last month's revenue, so I'd expect with further growth profit levels will eventually get quite high.

The map is 512x512, which is 64km square, and has a population of 337k.  The year is 1955.  Although much more realistic than previously, it still seems a bit excessive to be able to run 7 railway lines in such a region, with service frequencies ranging from 20 to 40 minutes.  I could not see this happening in the real world today in Australia without a population of at least 1 million, but perhaps in 1950, and in England this may be reasonable? 

The 'too slow' factor now dominates passenger statistics.  The network is quite well connected, and mostly running below capacity so there is little loss of passengers due to overcrowding, or no route.  Nearly all my buses are the smallest and fastest bus, and my trains are all 3 cars of the fastest emu to increase service frequency and reduce waiting times, but most stations are losing more passengers due to 'too slow' than are being reported as happy.  It is hard to see how I could travel traffic times significantly without running at a huge loss.  It may be realistic to have lots of potential passengers that don't want to travel as the time is 'too slow' even on a well set up network (I like to think I did a good job here), but it is a little frustrating as a player to see more passengers reporting 'too slow' than happy.

Perhaps if I try again and see how well a primarily bus driven network could do.  This could achieve very high frequencies, but in 1950 buses are limited to 64k/h vs the 120k/h that an emu can do.  The fact that I am faced with such a conundrum does make this version more interesting to play than previous versions.  Pak balancing may need to be reconsidered to give players more incentive to use larger vehicles with higher capacities.

neroden

Quote from: Michael Hauber on June 28, 2013, 12:24:56 AM
After compiling 11.9007 of the ncn devel branch I have a working passenger network with no obvious bugs.  Save game is uploaded at http://simutrans-germany.com/files/upload/Keep_going.sve

The small bug is a failure of one city out of many to expand its city limits despite no obvious obstacles to its expansion.  This is Duckingham.
This could be related to the minimum_building_density requirement which can have some bad effects.

QuoteI have built a railway network roughly in a grid pattern with supporting bus services.  The game is almost exactly at break even - I started at a loss, and with 250m credits, and played until growth got me to break even point.  Infrastructure maintenance is still a large portion of my overall costs at 71% of last month's revenue, so I'd expect with further growth profit levels will eventually get quite high.

The map is 512x512, which is 64km square, and has a population of 337k.  The year is 1955.  Although much more realistic than previously, it still seems a bit excessive to be able to run 7 railway lines in such a region, with service frequencies ranging from 20 to 40 minutes.  I could not see this happening in the real world today in Australia without a population of at least 1 million, but perhaps in 1950, and in England this may be reasonable? 

The 'too slow' factor now dominates passenger statistics.

I'm seeing this in a more extreme way in an earlier time period. We could try loosening the journey time tolerance configuration parameters, however, since I don't think those have been changed recently.  (Those are in simuconf.tab.)

The current version for pak128.britain is:
min_local_tolerance = 2
max_local_tolerance = 150
min_midrange_tolerance = 12
max_midrange_tolerance = 270
min_longdistance_tolerance = 30
max_longdistance_tolerance = 5400

These are specified in minutes.  I think the minimum tolerances are too low.  The maximum tolerances may be too low as well.

After we adjust that, there should still be quite a lot of "too slow", but not *as* much.

QuoteThe network is quite well connected, and mostly running below capacity so there is little loss of passengers due to overcrowding, or no route.  Nearly all my buses are the smallest and fastest bus, and my trains are all 3 cars of the fastest emu to increase service frequency and reduce waiting times, but most stations are losing more passengers due to 'too slow' than are being reported as happy.  It is hard to see how I could travel traffic times significantly without running at a huge loss.  It may be realistic to have lots of potential passengers that don't want to travel as the time is 'too slow' even on a well set up network (I like to think I did a good job here), but it is a little frustrating as a player to see more passengers reporting 'too slow' than happy.

Perhaps if I try again and see how well a primarily bus driven network could do.  This could achieve very high frequencies, but in 1950 buses are limited to 64k/h vs the 120k/h that an emu can do.  The fact that I am faced with such a conundrum does make this version more interesting to play than previous versions.  Pak balancing may need to be reconsidered to give players more incentive to use larger vehicles with higher capacities.

Junna

I can't download your save. The file seems removed(?)

jamespetts

Thank you very much for the feedback - that is very helpful. It is not a sign that anything is going wrong that you have a good number of passengers marked "Too slow" despite an efficient network: in reality, there are many journeys that people could make but do not because the journey takes too long to be worthwhile. If your favourite museum/art gallery/restaurant/shopping centre/etc. was a two minute walk away, would you go there more often?

I am planning some enhancement of the system relating to generating passenger journeys, which will include abolishing the three distance categories and replacing them with commuting and non-commuting journeys, the former of which will have a narrower range of journey time tolerances than the latter. This will hopefully result in even more realistic behaviour.

As to the total number of passengers, competition from private cars is very important here: the early 1950s was a time when far fewer people had access to cars than they do now. Have a look at the "Car ownership" graph in the city statistics window to see what proportion of the population have access to a private car for any given journey.
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.

Junna

Quote from: jamespetts on June 29, 2013, 09:49:17 PM
As to the total number of passengers, competition from private cars is very important here: the early 1950s was a time when far fewer people had access to cars than they do now. Have a look at the "Car ownership" graph in the city statistics window to see what proportion of the population have access to a private car for any given journey.

What sort of impact is there currently from what sort of roads exist? If there's a lack of speedy roads, does this affect private auto use at all?

jamespetts

Yes, unless you have "always_assume_everywhere_connected_by_road" set, the quality of roads between places should affect private car usage.
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.

neroden

Quote from: jamespetts on June 29, 2013, 09:49:17 PM
Thank you very much for the feedback - that is very helpful. It is not a sign that anything is going wrong that you have a good number of passengers marked "Too slow" despite an efficient network: in reality, there are many journeys that people could make but do not because the journey takes too long to be worthwhile. If your favourite museum/art gallery/restaurant/shopping centre/etc. was a two minute walk away, would you go there more often?
I still think the minimums should be bumped up a bit, though I'm not sure how much difference it will make.

5 minutes would be a reasonable minimum; I don't think I know anyone who distinguishes between a 2-minute trip and a 5-minute trip, unless they are insistent on walking.  Transport (whether car nor public) simply doesn't have a chance for trips under 5 minutes and we don't really need to simulate lots of people walking next door who will not use transport under any circumstances.

Similarly, the long-distance minimum should probably be raised to 1 hour, and the medium distance minimum to 15 minutes.

QuoteI am planning some enhancement of the system relating to generating passenger journeys, which will include abolishing the three distance categories and replacing them with commuting and non-commuting journeys, the former of which will have a narrower range of journey time tolerances than the latter. This will hopefully result in even more realistic behaviour.
I wouldn't abolish the categories entirely.  Within the category of non-commuting journeys, there is a distinct difference between "local everyday errands and visits", "day trips" and "serious *destination* long-distance trips".

jamespetts

#7
Ahh, except we do want to simulate people who will only travel if they can walk to their destination: this will be important when town growth is based on the number of successful journeys: it will create more growth where buildings are very close to other major buildings, and so encourage realistic clustering of high density structures.

As to categorisation by distance, I think that the best approach here is to have this as an emergent property of journey time tolerance and a revised version of the alternative destinations feature: for any given journey, passengers will have a type of destination in mind (commuting or non-commuting) and a journey time tolerance (which will be on a very wide range for non-commuting journeys, but heavily weighted towards the shorter end). They will then attempt a weighted random number of journeys to see whether the destinations are within their tolerance. If they run out of attempts before finding one, they will not travel; if they find one within their tolerance before running out of attempts, they will. The number of attempts and the journey time tolerance range and weighting will be calibrated such that, on a realistic map, a realistic proportion of people make journeys of any given length.
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.

Michael Hauber

I've continued on the map and updated to the latest release candidate.  I've noticed that managing overcrowding at bus stops is a significant issue, as an individual bus stop can have a much larger catchment.  Once things get busy with buses and passengers arriving in bursts (even with decent convoy spacing) I find I need as many as 3 or 4 bus stops to get enough capacity to avoid overcrowding even on stops that have no route transfers.  If I have a transfer stop between two significant bus routes, I put in a tube station building.  More of a pak issue than an engine issue, however it would seem likely that any pak would need more bus stop capacity in the experimental version than the standard version.  I am using a self compiled version of the britain 0.90 exp pak.

On the too slow issue, the current system results in significantly more people making journeys in the year 1990 than in 1750.  I would think that just as many people would need to go to work, or would have time off and make a leisure trip in 1750 as 1990, just that with transport options limited the travel would much more likely be walking over a short distance in 1750 as opposed to a 20k trip by higher speed transport in 1990.  Even in the modern era I have found from personal experience that in a small regional town people will consider 30 minutes 'too far' to go for a job, whereas in a large urban area they will think little of travelling over an hour.

Perhaps journey time tolerances could be dynamically adjusted according to the number of passengers that are too slow.  This would mean that the too slow factor would impact local transport success rates and development patterns, but would not impact global transport success rates.

jamespetts

I should be interested if you could upload your map in which you have 'bus stop overcrowding for me to look into that.

It is realistic, is it not, that significantly more people travel in 1990 than 1750? In 1750, many people lived and worked in the same place (farm, shop, etc.) or lived a short walk from where they worked, and had far fewer leisure trips than now. Do not forget: any given passenger journey is not necessarily a journey to work - leisure and miscellaneous journeys are also included (shopping trips, etc.). The plan is in future to separate these two types of journey and make the demand far more elastic for the non-commuting journeys than the commuting journeys, but that is not implemented yet. As to your example of small versus large towns and commuting distances, this will be dealt with by the system proposed for the future in which the decision to build or upgrade residential buildings will be based on the success rates of passengers from that or neighbouring buildings in making commuting trips.

As to dynamic adjustment of journey time tolerances, I do not quite understand what feature of reality that this would be simulating...?
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.

Michael Hauber

Save game is here:

http://simutrans-germany.com/files/upload/Crowded_stop.sve

An example bus stop is Coatford Town Hall.  This is on two bus routes, one which connects with the local rail station, and another which links with two nearby towns.  The current capacity is 215 passengers, and generally the bus stop has less than 50 passengers waiting.  If the stop is watched for a couple months there are occasional periods when the number of passengers waiting can build up substantially, and even exceed the capacity.  If you look at history the current month has lost over 700 passengers to unhappy after a big build up, so this effect can have a noticeable effect on passenger levels.  The previous two months lost very few passengers, and prior to this the stop had been losing nearly half its passengers to overcrowding, while at a capacity of 75 passengers.  When the stop becomes crowded I can usually find a clump of buses gathered together somewhere which has obviously contributed to this, perhaps putting in more than one convoy spacing stop per line may help.  The maintenance cost of a tube building is 144 c/m, and the revenue per passengers on the lines serving this stop is about 1c and 3c respectively, so the several hundred passengers a month this tube station appears to be saving me should easily be paying this cost.

On too slow, at least one researcher has concluded that we travel about the same amount of time today as for the last few thousand years, and it is only the total distance travelled that has increased as the speed of travel has increased, and obviously several hundred years ago the majority of travel would be walking rather than by wheels or horse.  I'm not sure how too slow currently interacts with walking and private car usage, and whether walkers or private car drivers are counted in 'too slow' statistics or not.

https://en.wikipedia.org/wiki/Marchetti%27s_constant

In tracking journey success rates by building, I'd think this should include walkers and drivers as a success, as in real life locations that are easy walking distance to desirable destinations, or have good access by private car to freeways etc tend to develop well.

jamespetts

Thank you for uploading that. I'd say that the main reason that your stop is overcrowded is because you do not have sufficient 'bus stops for such a densely populated area, and you are only using a few small 'buses to serve the route. The waiting time to the railway station is nearly 20 minutes! The solution to crowded stops in towns is not to increase the capacity, but to improve the service. If you had to wait nearly twenty minutes to board your local 'bus because the first four or five services that came were too full for anyone to get on, what would make you more likely to use the service in the future: an increase in the size of your local 'bus stop so that you could wait in a comfortable building, or a more frequent service so that you didn't have to wait as long?

Remember, passengers count the time walking to the stop as part of their journey time for tolerance purposes. The walking time to any given stop can be seen by clicking on any city building. Passengers to the east of Coatford have walking times of up to 30 minutes to their nearest 'bus stop, plus 19 minutes 42 seconds of waiting for the 'bus to the railway station, plus a five minute six second journey to the station before they can even begin to wait for the train. This is probably why you are getting so many passengers registering as "too slow".

The link to the article on the Marchetti constant is very interesting, as this is the basic principle on which Experimental's journey time tolerance works, albeit I had not heard of this research before. This is potentially very useful information in calibrating the journey time tolerances.

Incidentally, buildings' success rates already count any means of passengers getting to their destination as a success, including walking and private car transport. The success rate is not yet used for development, but this is planned in the future.
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.

Michael Hauber

Ok, I tested the three improvements against each other:

1) building a tube station increasing waiting capacity at the station from 75 to 215.  This costs 144c/month.  This gives a significant improvement in performance, with the worst month losing about 800 to unhappy, compared to losses as high as 5700 in a month prior to the improvement (2nd worse month 2800 loss).
2)replacing all buses with the next bigger bus.  This doubles the capacity, from 26(0) to 36(27), and only costs about 5% extra (1.27c/km vs 1.20c/km).  At about 4k running costs for both lines this is about 200c/month.  Many bus capacity upgrades are much more expensive than double capacity for 5% extra though.  Again a significant improvement in performance, with worse month losing about 1300 to unhappy.
3)adding an extra bus to the line to the local station, and 2 extra buses to the line serving the neighbouring towns.  These buses are also the higher capacity with 36(27) as the current bus is now out of date.  These extra buses cost about 500c/month.  Again significant improvement in performance, but losing as much as 1700 to unhappy in a single month.

Each case ran for six months, and with the large month to month variation its hard to know for sure if 2 and 3 were significantly worse than 1, or whether this was just a random variation.  However upgrading the capacity of the stop is certainly a very competitive option for upgrading the performance of passengers through that stop.

I'm not sure why the waiting time to the nearby station is reported as 20 minutes, the services are currently at just over 2 minute frequency, and although some passengers are having to wait for more than one bus to get on, I can't see how the average could be 10 buses.  After the upgrade the max waiting que is 215 passengers = 8 buses (some of which are on the other line), and nearly all passengers are getting through with a que substantially less than this maximum.  And prior to the upgrade the bus service is still the same, its just that the que was getting trimmed by passengers not turning up to wait when the que got to 75 instead of at 215.

I agree that spacing stops closer together is worth looking at and would probably help with this type of situation.  I have just started another game where I intend to test developing a more bus intensive passenger network with an aim to maximise service frequency and coverage.

neroden

Quote from: jamespetts on June 30, 2013, 11:18:24 AM
Ahh, except we do want to simulate people who will only travel if they can walk to their destination: this will be important when town growth is based on the number of successful journeys:
Not if you mean what I think you mean... maybe I'm not clear on what you mean.
Quoteit will create more growth where buildings are very close to other major buildings, and so encourage realistic clustering of high density structures.

We need a system where the location of construction *within a town* is determined by the *percentage* (not number) of successful journeys from nearby locations.  This wouldn't actually be that hard to write, now that I think about it...

QuoteAs to categorisation by distance, I think that the best approach here is to have this as an emergent property of journey time tolerance and a revised version of the alternative destinations feature: for any given journey, passengers will have a type of destination in mind (commuting or non-commuting) and a journey time tolerance (which will be on a very wide range for non-commuting journeys, but heavily weighted towards the shorter end).
That's a good idea, to have passengers have different *time tolerances* rather than *distance tolerances*.

You still need more than two categories.
(1) Commuting.
(2) Non-commuting local.
(3) Non-commuting trip involving overnight or more-than-overnight stay.

#2 and #3 are really, really different.  There is a sharp dropoff in demand between #2 and #3, but #3 suddenly has a *much* longer time tolerance.


jamespetts

Thank you both for your responses. Having multiple 'bus stops in any given area with a more frequent service each is, of course, equivalent to increasing stop capacity, as each 'bus stop has its own capacity, and its own local catchment area, and all the 'bus lines needed to serve those multiple stops will also of necessity increase frequency.

As to your waiting time, if anyone has waited beyond their waiting time limit, they will record a very high waiting time on being discarded, which might have skewed the times; either way, something is going wrong in your network if transport is regularly leaving a stop completely full and leaving passengers behind.  In any event, I should be interested to see the results of your frequency testing.

Nathaneal - what do you think that I mean? I'm not sure that I know what I think that you think that I think that I mean - I think. As to the percentage of successful journeys - that is what is planned: if you click on a building, it is the percentage success that you will see (although that figure is not used yet).

As to the difference between categories no. 2 and 3 - can this effect not be achieved by having a non-linear (bell curve) algorithm for the likelihood of any given journey time tolerance? This can be calibrated using the "Marchetti constant" data to which Michael refers in his previous post.
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.