Economic woes

[mjhn]

I am having three issues which are making the freight economics impossible:
1)With the distance per square reduced, while the per square profits are constant, the per time profits are reduced, making earning enough money to expand the network a very slow process (In my first game I actually had trains become obselete before they had earnt more money in profit that they had cost)
2) All vehicles are costing twice the listed value, which makes the effects of problem 1 much greater
3)Earnings seem only to be based on the long side of the rectangle between hte start and finish position, not the sum of the long and short sides.

My attempts to have a fungame despite these issued consentrated on using beginner mode, but this seems to be having no effect (beginner_price factor = 1500, first_beginner = 1)

Issues 2 and 3 seem to be due to bugs, while solving issue 1 may need a change in the approach of how distance_per_tile works.

The solution to this that I would take is to also increase the game speed of vehicles so that they covered the same number of km per month independant of the distance_per_tile setting. This would results in the situation where,while the per tile costs and earnings would change with the distance_per_tile setting, the per month costs and earnings would not, making the balancing of capital costs against running costs the same for all distance_per_tile settings, instead of varying with this setting.

[jamespetts]

Mjhn,

thank you for your feedback: it is extremely useful to have a good economic analysis of the changes made to Simutrans-Experimental. I shall deal with each of the issues in turn.

Variance of timings with distance per tile

From Simutrans-Experimental 7.1 onwards, the new physics engine (written by Bernd Gabriel) does take distance_per_tile into account (precisely how I am not entirely sure, as Bernd Gabriel wrote that section). Are you finding that this is not what is happening, or are you just comparing with Simutrans-Standard revenues? It may be that this is calibrated to be slower overall than Simutrans-Standard. The fix for this would seem to be to increase the revenues globally. I have done this for Pak128.Britain-Ex 0.4. Which pakset are you using?

Vehicles twice listed value

This is indeed a bug, which has already been found and fixed; the fix will be released in the next version.

Earnings based on the long side of the rectangle only

This is not a bug that has been reported before. In Simutrans-Standard, earnings are based on the "Manhattan distance", which means that diagonal distances are overestimated compared to straight distances. In Simutrans-Experimental, the earnings are based on the Euclidian distance, which is more accurate. However, do you think that you have found a bug to the effect that, in Simutrans-Experimental, the distance calculations are, not only less than in Simutrans-Standard, but also less than the truly accurate distance? I should be interested in any such findings: can you elaborate on that, perhaps?

Thank you again very much for your feedback!

PS: I have deleted the discussion about your initial posting difficulties so as not to distract from the purpose of this thread.

[mjhn]

I have carried out some further testing.

Variance of timings with distance per tile

It is very difficult to get a direct comparison, but I opened two copied of simutrans-exp side-by-side, with two pak folders where the only difference was the setting of distance_per_tile in simuconf.tab. Using maps generated using identical setting (unfortuanlately I could not create identical maps), I set the same vehicles (Leyland cubs) on straight routes of the same length. The jouney took slightly less time on the set-up with the distance_per_tile = 100. This is the opposite of what would be needed to make the per-time profits constant and so allow for balancing being independant of distance_per_tile. A closer look showed the reason. while the maximum speed in both cases looked the same, with a distance per_tile value of 25, the number of squares needed to reach that maximum speed is around 1.5 tiles, while with distance_per_tile = 100 this is less than one tile.

Earnings based on the long side of the rectangle only
Thankyou for the explanation. I am not convinced that this is the way to go, as my costs are still based on the manhattan distance. The error in my calculations seems to have been to forget that all except the slowest goods in pak138.britain-exp have speed bonuses (my calculations were based on carts - around 1/3 of the basic speeds)

I have also had some ideas and questions about balance, but I will put these in a seperate thread.

[jamespetts]

Mjhn,

Variance of timings with distance per tile

The reason for the difference in acceleration is that the acceleration is based on the distance_per_tile setting such that it takes a constant number of kilometres to accelerate to any given speed. Anything else would be unrealistic. One cannot vary the tiles per real second when varying the distance_per_tile, since the variation is already taken into account when calculating journey and waiting times.

Earnings based on the long side of the rectangle only

The costs are not based on the Manhattan distance - in Simutrans-Experimental, the maintenance costs for vehicles and ways are also based on the Euclidian distance.

Thank again you for your feedback; I shall look forward to your balancing thoughts.

[mjhn]

Jamespetts,

Variance of timings with distance per tile
So what you are saying is that if I have a distance_per_tile setting of 25, my vehicles should take 4 times as long to pay back their puchase costs than if I use a distance_per_tile setting of 100. This makes balancing of any pakset impossible, as any pakset balanced for distance_per_tile = 25 would pay back purchase costs in very little time indeed when played with a distance_per_tile = 100, while any pakset balanced for distance_per_tile = 100 pay back purchase costs far too slowly with distance_per_tile = 25. In fact, while the current pak138. britain-exp plays quite well with distance_per_tile = 100, it is almost impossible with distance_per_tile = 25.

Earnings distances 
I have just checked: the maintinance cost of a road is per square, which means that it is manhattan distance, not euclidean distance. Vehicle costs on the other hand seem to be reduced by 33% on diagonals which means that they are approximately euclidean (Actually slightly better for a purely diagonal route). Unfortunately the lack of diagonal stations, bridges, slopes, and crossings in simutrans make long diagonals impractical.

[ӔO]

one substantial difference between the standard and experimental that I've realized is the sheer volume of goods (mainly passengers and mail) moved through the network.
While I don't think the standard is realistic in that regard, in experimental people just don't want to go anywhere even if you build up an elaborate network connecting up the entire map with the fastest vehicles available in that time period. This is with passenger factor set to 14~16 range.

many of the trains and vehicles in br128 are only profitable when they are at least 75% full pulling near maximum tonnage in standard. When these values are imported over to experimental, they simply become unprofitable because the convoy will never hit full capacity due to the new passenger calculations and also because they cannot pull the same amount of weight due to the new physics model.

Although I think it's a bit extreme, I would guess that reducing maintenance on many engine units to half the value from standard would allow many convoys to become profitable.

[jamespetts]

Variance of timings with distance per tile

The issue with repayment of purchase costs is an interesting one. However, varying speed would not work, since this would interfere with the timings and physics system. One simpler alternative that would not cause clashes is simply to reduce the purchase cost of vehicles pro rata with distance_per_tile. Does anyone have any comments on that suggestion?

Earnings distances

Thank you for pointing that out. I am trying to implement now a change in the code for 7.2 such that maintenance costs for ways are varied (divided by 1.4) if they are on a diagonal.

Edit: I should still find it very useful to see the saved game that gave rise to this post. The same applies to AEO's comment.

[ӔO]

ah, yes, I knew you would ask, and I was uploading it to filefront.
it's a bit large since it was saved under standard.

http://www.filefront.com/15575461/Small%20Britain.sve

[Dutchman on Rails]

Mjhn, I also play a lot in early times (1750-1800), and I'm a bit surprised that you trouble getting the vehicles to be profitable. While I do always have trouble getting enough profitable vehicles on the routes, I found out that for me the maintenance cost of the buildings  is the problem. After I made it a practice to lower maintenance_building to 100, I never had much trouble creating profitable routes, though I have to admit not every vehicle works for every cargo.

AEO: On passengers, I'm also a bit surprised. I generally set the passenger_factor back to 1 and still have some passengers.

If the two of you would like, it may be interesting to compare experiences. Though I have to admit that due to other problems in my games, I'm now playing Pak.German for a while (to kill time until Simutrans-Ex 7.2 is released).

[ӔO]

@dutchman

load up my save (you might need brit boats 192 patch and one way signals for rail) and you'll see what I mean. passengers absolutely overflowing the network in standard (unrealistic) and they just dry up completely in experimental)

[jamespetts]

AEO,

I've had a go with your saved game; thank you for posting it. Whilst there is a big difference between the number of passengers with Standard and with Experimental, the numbers with Experimental are still respectable. It should be noted that the numbers appear lower than they are because of the dissonance between the vast capacity of the network and the more modest number of passengers now using it. One of the things that Simutrans-Experimental was designed to encourage were larger towns (when a larger scale is used); lower passenger numbers per given size of area of town, therefore, is a corollary to that.

[wlindley]

If you can somehow adjust the computation of passengers between two points -- The United Rail Passenger Association's Adrian Herzog's research shows that the ridership factor between two points is dependent on two things:  The distance between them; and one-third the cube of the logarithm of the population. 

According to his "Matrix Theory for Passenger Trains",

"...while the ratio of population between two stops may be as much as a factor of 50,000, the actual ridership potential of the largest market is only some 40 times greater than the smallest market. To put it another way, a system made up of only seven of the smallest stations in the network not only is capable of producing but usually will produce the same ridership contribution as the largest single station in the in the network!"

Example (more on the link above):

Town with population 100... log(100) = 2; cube of log = 8; ridership factor = 2.667
City with population 5 million... log(5,000,000) = 6.669; cube of log = 300.63; ridership factor = 100

How closely can Simutrans replicate these real-world values?

[ӔO]

aha, I see what you mean James.

So from reading that it would mean it is necessary to have a larger station catchment area to offset the costs of maintenance upkeep on the network, or have the catchment area the same, but with a reduced cost to the network infrastructure for the finer convoy lines.

or simply a density issue, but the cities are just not scaled to the proper sizes required to get any decent amount of people to produce a profit.

so maybe set maintenance cost multiplier from 4 to 1?

[Dutchman on Rails]

Hi AEO,

No, I think we found common ground. Yes, my experience with Simutrans standard/any pak is that there are too many passengers to be realistic (I set passenger_factor to 1 for precisely that reason and still with a good passenger network I find it sometimes slightly too high for my taste). And no, with Simutrans-Ex/Pak.Britain-Ex, it's not my experience that the level of passengers is completely zero. It's low, especially with passenger_factor still at 1, but that's my intention of setting it so low. I think from what I read now that we meant more or less the same.

By the way, I do have a higher station catchment area (5 instead of 2). This mostly because I feel passengers are prepared to walk a few streets to a bus stop. But I suppose having a local coach service to bring the passengers to a coach or rail station for longer distances should do the trick too.

[jamespetts]

Thank you all for your interesting comments. WLindley - as to your figures, Simutrans (both Standard and Experimental) works, not by starting with the desired end-result (the mathematical function to which you referred) and working backwards from there, but starting with basic economics and working forwards. It is, in other words, a bottom-up approach to passenger flow modelling, rather than a top-down approach.

It works in this way: each building generates passengers and mail. The amount generated differs depending on the "level" of the building. They are divided between three groups according to a set formula: (1) town destinations; (2) attraction destinations; and (3) industry destinations. In Experimental, passengers may have more than one potential destination (in Pak128.Britain-Ex, the maximum number of alternative destinations is 3, meaning that passengers may have between 1 and 4 potential destinations).

For attraction and industry destinations, passengers pick their destinations from a weighted list (i.e., a list in which each item can have one or more entry depending on its own "level", and an entry is chosen at random, thus producing a weighted random outcome) of that type of destination. For industries, the list is based only on local factories. One can see which industries are served by which towns by clicking on the industry in question: it will show a list of where its workers come from.

For towns, passengers (in Experimental) have three different distance settings: short, medium and long-range. Each setting comprises a range of different distances measured in tiles, which can be set in simuconf.tab. There is a weighted preference in favour of local passengers over midrange passengers, and midrange passengers over long-distance passengers, which can be set in simuconf.tab. In the current Pak128.Britain-Ex, the distances are:

Code Select Expand


local_passengers_min_distance = 0
local_passengers_max_distance = 25
midrange_passengers_min_distance = 4
midrange_passengers_max_distance = 100
longdistance_passengers_min_distance = 50
longdistance_passengers_max_distance = 16384


(These distances are in kilometres, and are converted into tiles when the data are loaded from simuconf.tab). The weightings in Pak128.Britain-Ex are:

Code Select Expand


passenger_routing_local_chance = 43
passenger_routing_midrange_chance = 37
# passenger_routing_longdistance_chance is 100 minus the sum of the two above values,
# but not stipulated individually.


The passengers also have a journey time tolerance, which is randomly set for each passenger based on a range specified for their distance type:

Code Select Expand


min_local_tolerance = 20
max_local_tolerance = 60
min_midrange_tolerance = 45
max_midrange_tolerance = 180
min_longdistance_tolerance = 120
max_longdistance_tolerance = 720


A destination town is found from the weighted random list. If that is within the acceptable range of distances for that type of passenger, the process moves onto the next stage. If not, another entry in the weighted list is sought. The process continues either until a town within range is found, or the maximum number of iterations expires (to prevent deadlocks in cases where there are no towns with range at all). A certain proportion of "local" passengers will skip the town finding stage all together, and will automatically be set to travel to a destination in their origin town. The proportion depends on the size of their origin town as a fraction of the median starting town size.

Next, the passengers seek a specific destination within their chosen destination town. Again, a weighted list is used - this time, a weighted list of buildings, weighted by their "level". For passengers with multiple destinations, the process is repeated until the total set of destinations has been filled. Now, the passengers try to find a route to their first destination.

Firstly, they check to see whether they are in walking distance of their destination.  If they are, they walk, and do not take the player's transport. They then look to see whether there are any transport stops within walking distance (i.e., within the station catchment area specified in simuconf.tab - for Pak128.Britain-Ex, I use 3 tiles, rather than the default 2 for Pak128, partly to compensate for the increase of the scale). In Standard, they latch onto one at (sort of) random; in Experimental, they build a list of all possible origin stops. From each stop, they check all the possible routes to their destination. In Experimental, the routes are stored in the stops along with the journey times. If no route can be found where the journey time is equal to or less than their tolerance (and the passengers do not have a private car), then they repeat the process with their next destination. If they do not have a next destination, they are marked as "no route" (if there is no route at all) or "too slow" (if the route with the shortest journey time exceeds their tolerance) and do not travel. If, however, they have a private car, they use that instead, and a private car trip is generated, adding to congestion, as well as generating a little private car object in the origin town, which will drive around the roads, getting in the way of 'buses.

The passengers will, if there is more than one route to their destination, find the route with the least journey time, and use that. They will use whichever origin stop that they can reach that gives them the shortest overall journey time. Where there is a route and passengers have access to a private car, there is a further calculation (based on a number of factors, including the journey time and the congestion of the origin and destination towns, as well as a car preference factor set in simuconf.tab) to determine whether passengers use their car or the player's transport.

Whether or not this produces the results to which WLindnely referred I do not know, as I have not conducted those tests. That system, which is adapted from that used in Standard, is driven by a mix of aiming for realism and keeping system performance within acceptable bounds.

Turning to AEO's post, as mentioned above, I try to use a combination of the two factors: the station coverage ratio in Pak128.Britain-Ex is set to 3 tiles rather than 2 (anything greater tends to diminish the possibilities for interesting intra-urban transport), and station and way maintenance costs are scaled with the scale factor, such that, with a distance per tile of 250m, the station and way maintenance costs are 1/4 of such costs at 1km/tile.

The town sizes also need increasing if the scale is increased (with a corresponding reduction in passenger levels). One contributor to this problem is that the current Pak128.Britain releases lack higher density urban buildings, especially in certain eras. There is currently a concerted effort (see here) to add more urban buildings, which should alleviate this issue substantially in subsequent releases. In the next release of Pak128.Britain-Ex, I am planning substantially to increase the default median town size for this reason.

[ӔO]

@Dutchman
yes, I think we were referring to the same thing.

@james
Thanks for elaborating.

Taking a look at the public transit systems I have in my city, it would seem that density is the key factor. where downtown is near overcrowded in capacity, while the outskirts have less public transit riders and more private car commuters.

I do not know if you have this in the UK, but here we have parking lots owned by the public transit to allow multi-modal transportation because parking a private car in the downtown core is expensive with the limited space. (this might be another thread on its own)

[jamespetts]

AEO,

indeed - Simutrans-Standard already seeks to model density (higher density buildings near the centre of a town), and density is directly related to passenger generation, so this should all be modelled already.

One thing that is not modelled, because it would add vast complexity to the route-finding system and (probably) excessively inhibit performance is allowing passengers to transfer between private cars and public transport. That would vastly increase the number of possibilities through which the code has to iterate, and would be extremely difficult to implement.

[skreyola]

Perhaps park-n-ride could be emulated by having a station extension that is treated specially, given a slightly (or much) larger catchment area than the walk-to station buildings.

[jamespetts]

Skreyola,

interesting idea, although this would be only an extremely loose approximation of park-and-ride, since it would not account for the fact that only a certain proportion of the population have a car (varying with time), and that the journey to the station should be counted towards the journey time, etc.

[ӔO]

a station extension with larger catchment area might work better for bicycles.
Japanese and the Dutch have massive bike parking lots at stations just for this purpose.

Bikes normally allow a 3 fold distance increase over foot for the same amount of time for average riders.

[jamespetts]

AEO,

ahh, but then  there'd be the issue of different levels of bicycle usage over time, and adding the bicycle journey time to the standard journey time, and so forth...

[sdog]

a more proper way to simulate park and ride would be to reduce the car usage rate in a city with every park and ride station built (and served) within city limits.

to prevent park and rides being built in the city core they could be 2x2 buildings.

[ӔO]

@james
could it be simplified? Have the passenger choose between foot or bicycle. When bicycle is chosen have the passenger be able to travel 3x distance of foot where walking is denoted, but otherwise have the same code?

@sdog
I would go as far as 2x3 for park and ride parking lots for multi level and 3x3 for single level.

[jamespetts]

Sdog,

I am not quite sure what you mean. In Simutrans-Experimental, there is not a generalised "car usage" figure that can simply be reduced. The useage of private cars is a function of a precise and complicated passenger generation and routing code. Car usage can only be reduced if fewer people are given access to cars (which means fewer successful journeys overall where public transport does not provide a satisfactory route), or if public transport can more satisfactorily serve a particular demand than private cars can (and this is calculated precisely for each and every trip as part of the system that determines how many passengers appear at your stops wanting to go to particular destinations, and the route that they take to get there: there is not an overall generalised figure that can simply be adjusted). That precise system is explained in some detail in a previous post in this thread. How do you suggest that it be adjusted without losing any of its functionality or accuracy?

AEO,

even that suggestion raises many complexities; how, for example, should the ratio of foot to bicycle be determined? It would have to vary over time, as bicycles are not always available. And, surely, only some sorts of stations would have bicycle parking facilities (people do not park their bicycles at small 'bus stops, for instance)? What of the instances where a journey from stop A, within walking distance, takes 10 minutes longer than a journey from stop B, at the edge of cycling distance - which route do bicycle-enabled passengers choose? And how would the two differential coverage radii be represented in the UI? Given the relatively long to do list for Simutrans-Experimental, this seems a little marginal in its benefit compared to the relatively high complexity for both the coders and players. Thank you for the suggestion, though!

[sdog]

i thought there was a much simpler system in place to simulate car ownership, in form of a reduction by a globaly set percentage. i must have overread that post, and will search for it now.

EDIT:
here it is:

If no route can be found where the journey time is equal to or less than their tolerance (and the passengers do not have a private car), then they repeat the process with their next destination. If they do not have a next destination, they are marked as "no route" (if there is no route at all) or "too slow" (if the route with the shortest journey time exceeds their tolerance) and do not travel. If, however, they have a private car, they use that instead, and a private car trip is generated, adding to congestion, as well as generating a little private car object in the origin town, which will drive around the roads, getting in the way of 'buses.

the private car system is indeed far more complex than i expected. however this means also that increasing car ownership does not hurt the public transport (except congestion), since car owners will still take the transport with the same probability as non car owners.

this also means, i think, there's hardly any advantage for park-and-ride. with the exception of that stage:

They then look to see whether there are any transport stops within walking distance (i.e., within the station catchment area specified in simuconf.tab - for Pak128.Britain-Ex, I use 3 tiles, rather than the default 2 for Pak128, partly to compensate for the increase of the scale).

if there's no stop within walking distance, they check if they have a car. if they do they will check if a park and ride is within a set distance (for example max_local_tolerance).



ps.: i just contribute in a brainstorming fashion, if my comment is useless, just ignore it without much explanation.

[ӔO]

@james

aha, I see how complicated this can get.
Indeed, it does look to be a lot of work for so little.

[jamespetts]

Sdog,

there is a difference between the car ownership rate, which is indeed simply a percentage figure that varies over time, and the car usage rate, which is a function of the car ownership rate and many other local and specific factors, as described above. It should be noted, however, that the private car ownership rate does impact on public transport, since, where a passenger can take either player's transport or their own private car, they tend to prefer (quite strongly) to take their own private car. That preference, however, is reduced by congestion in either their origin or destination city, or if the player's transport is faster.

As to the checking whether park and ride is within a maximum tolerance area, the same issues apply for that as they do for bicycles: see the comments to AEO above.

Thank you both for your feedback, though - even ideas that don't end up changing the way that things work are much appreciated. It is always useful to have these discussions :-)

[mjhn]

jamespetts:
Is it possible to reduce the effective car ownership rate for a given passengers journey seperately based on the number of park and ride systems? For instance have a reduction of 5% when calculating short distance journeys if the city has a sufficient number of park and ride car parks? (probably actually done on a sliding scale based on number of inhabitants per park and ride).

As for the reduced proportion of earnings compared with purchase costs with low distance_per_tile, the option of reducing the vehicle purchase cost sounds nice and simple, and would at least theoretically keep the balance of different values of this option the same.

[neroden]

One thing that is not modelled, because it would add vast complexity to the route-finding system and (probably) excessively inhibit performance is allowing passengers to transfer between private cars and public transport. That would vastly increase the number of possibilities through which the code has to iterate, and would be extremely difficult to implement.

Would it?  Hmm.  How about finishing everything else you're modelling and then checking again.  Maybe computers will be faster.    It seems to me that every journey for which private car is an alternative could also be figured with park-and-ride as an alternative.  Only designated park-and-ride lots could be used for transfer and they could only be used at the 'home' end (which is close enough to accurate).  If the pathfinding code for private cars and public transport isn't completely separate, this sounds like it might be easier than you think.  Private car is simply another method of transport, which uses roads but doesn't need stations.  
Park-and-rides *can* cause people to drive to them instead of walking to the local bus stop -- making traffic worse -- so this should simply be allowed to happen.

It's still not worth doing in the next few years, of course.  "For experimental mark 2" maybe. :-)

(edit)
If we're getting into that level of realism, I'd remove catchment areas entirely and replace them with a "walking" system, where passengers walk along sidewalks to get from place to place, with the total journey time including the slow walking time.   This would enable a more realistic catchment.  Walking directly between tiles would be allowed entering and exiting start/destination buildings, and between tiles which are road, walkways (a new waytype), and/or stations.  Other goods would generally have the same rules, though preventing some from being carried along sidewalks (requiring stations directly adjacent to factories) might make sense.

The pathfinding involved would be large, so it should probably wait until computers are several times faster (Moore's Law). :-)

[jamespetts]

Neroden,

thank you for the interesting - albeit somewhat speculative - thoughts. Actually, it is rather more difficult than you suggest because, currently, there is no path-finding, as such, for private car trips: there is simply an assumption that passengers can get where they want to go by private car at a certain speed, based on a function of the speed-bonus speed for road transport that currently obtains. Pathfinding for each individual private car journey would be impractically computationally expensive. I do plan at some point, however, to introduce a system in which, each month, every town checks whether its town hall is connected to every other town hall, and checks the journey time of each such connexion (by measuring the route distance, and using a function of the average maximum speeds of all of the private cars currently available in the timeline and the maximum speed of each of the road tiles, the speed, storing the results as a ratio between number of as-the-crow-flies tiles between the two cities and the journey time in minutes), so that, for each individual private car journey, a reasonable approximation of the actual journey time can be undertaken, as well as checking whether such a journey is possible at all. Park and ride would indeed greatly complicate matters, as it would require full path-finding for each and every private car trip, which would be an enormously computationally expensive exercise.

As to the walking idea - I considered something approximately along those lines a few months ago, but decided not to pursue it on the grounds of the complexity of its implementation (and consequently the time involved therein) outweighing any benefits. One immediately apparent issue with the system that you suggest is how to represent to the player in a readily comprehensible way from which buildings that passengers can walk to get to any given stop? The catchment area does that very effectively - that would be harder if a walking algorithm was used. It would also add a phase of path finding where there was none before.

(As an aside, it should be noted that, in Simutrans-Experimental, unlike Simutrans-Standard, where passengers can walk from their origin building to their destination building, they do so, whether there is a stop nearby or not. In Simutrans-Standard, they only walk when there is a local stop).

[neroden]

Neroden,

thank you for the interesting - albeit somewhat speculative - thoughts. Actually, it is rather more difficult than you suggest because, currently, there is no path-finding, as such, for private car trips: there is simply an assumption that passengers can get where they want to go by private car at a certain speed, based on a function of the speed-bonus speed for road transport that currently obtains

Oh... interesting.  I think that's a bug.

I often build connections to remote attractions *only by train* so that they *cannot be reached by road under any circumstances*.  The private car should be at least forced to find the existence of a path; otherwise the journey needs to be cancelled.

(edit) I'm glad to hear you're planning to do something to fix that :-)

If computation time gets cheaper the extra pathfinding in the 'full walking scheme' will be worth it.  Currently it's not, certainly.

[jamespetts]

I'd consider it more of a design defect than a bug - I've been planning to fix that for some time, but finding the time is always the issue. It will make a real difference, however, when network multi-player games are possible. If nothing else, it will be fascinating to see the differing outcomes of different strategies by the public player as to whether to connect everywhere by road or not.