Topic: Citycars, aircrafts and passenger routing.

[dantedarkstar]

Playing the experimental simutrans, the following things occured to me:

1.Citycars - maybe I'm not good at handling them, but at some point, on the traffic density 6 (perfectly manageable on Standard) the thing got a little out of hand. The cities were PACKED with them. But the worst thing was, the intercity roads quickly filled up with cars too ! About half intercity roads were one long queues of cars. The other half had only screen-sized queues on them. Deadlocks in cities started to get very common, and deadlocks that were not simply because cars got in some stupid want-to-go-around-the-monument deadlock, but because the cities were completely full of them. The problem is, I get the feeling that for each city house there were at least one or two cars out there (there were no "no route" passengers on stops, or at most trace amounts). That means each city produced more cars than there were roads inside the city. This gets unrealistic - normally you can fit more than one car in 1km of road
My proposal is to completely remove "random" city cars, and only spawn cars with destinations. I don't know how much it would help, but it should decrease the traffic a bit AND make it more believable. Do citycars with destinations disappear upon arrival at the destination ? If not, then it should be the case. I think the problem is not too high car generation, but the fact that the cars accumulate like crazy. Do the game keep track how many passengers actually are in cars and therefore can't appear again with another car ? Also, I'm not sure if passengers without access to cars generate them anyway if there is "no route". If it is so, then they shouldn't. Just too bad for them.

2.Aircrafts. I stumbled upon a "problem" of sort. The speed of the aircrafts mean that their travel times are really short. Which make them really most preferred transport type with current routing algorithms. Like instead of taking train from Paris to Berlin, we will take plane... through Moscow. Because passengers don't pay for moving them away form their destination, they are quite happy to fly to Moscow and then to Berlin instead taking train that goes 1 hour longer. The problem is : they choose any route they want, but pay only for when they get closer. I want that too ! I would go from Amsterdam to Rotterdam through Shanghai, Los Angeles, Chicago and Paris ! What a trip... for almost free !
Well, enough problem exagarrating. I have a question : are loading times incorporated into "travel time" or "waiting time" ? If so, then I guess making most aircrafts extremely long-loading would cut the problem of them going there and back (a little ?). Alternatively, you could either put aircraft flight time modifier into simuconf file. The routing algorithm would consider all flight times this many longer for routing purposes only.
Also, in long term it might be especially good for experimental to have paksets with first-class and second-class passengers (or however you call them). And there might be no planes for second-class passengers. Anyway, the issue is that good airplane network would steal all passenger traffic at the moment.

3.Passenger routing - I know that passengers wait for specific line with best travel time to get them to destination, ignoring other lines that directly link them to destination. This is sensible, but I would add a tweak - compare not pure traveltimes, but
traveltime of currently considered line   versus   traveltime + averagewaittime of the "best" line
This way passengers would be less fixated upon taking specific line and if better option would suddenly present itself they would jump at it !

[tick tock]

Regarding citycars:

James, I probably just imagined this, but didn't you (in an earlier version of Experimental) actually have the program delete individual citycars to maintain the visual level of congestion with the numerical level?  Maybe I'm crazy, but I thought you did, though I see that doesn't actually occur now. Anyway, is it possible to delete individual citycars in a given city when the number of visually represented cars exceeds the amount that should be present with respect to the congestion value, or would that require too much processing time?  From what I've seen, it looks like citycars are created monthly to proportionally match the congestion level(?), but none are ever removed, so they just keep accumulating.  It seems like they are created in the cities, gradually make their way out onto the intercity roads, so more are created within the city next month, so on and so forth, until the whole map is finally teeming with them - despite low numerical levels of congestion in each city.

BTW I lowered the traffic density setting to 1 after this happened, but it didn't seem to lessen the number of cars I could see (even over several months).  Perhaps it can't be changed midgame?

[jamespetts]

Dante and Tick Tock,

thank you very much for your feedback - most helpful :-) I shall address the points using Dante's numbers.

1. Traffic

Following the reports of excess traffic, I looked carefully into the code, and found a bug in the code that I had written long ago to delete excess city cars after they were generated. Tick Tock was correct that a deletion mechanism had been designed, but it had not worked because of the bug. So, from the next version (3.12) onwards, this issue should be fixed. My (brief) tests have shown greatly reduced traffic as a result.

2. Aircraft

I always intended that, as in real life, aircraft should have a much longer loading time than other forms of transport. The loading time should be taken into account as part of the travelling time. The loading time can be set in the pakset, so part of the difficulty is the lack of Simutrans-Experimental compatible paksets.

However, what I have done for version 3.12 is to vary the default loading times for vehicles depending on their type. From now on, 'buses and trams will continue to have a default loading time of 2,000; trains, monorail trains and maglev trains will have a default loading time of 4,000; ships will have a default loading time of 20,000; and aircraft of 30,000. This will apply both to Simutrans-Standard paksets and Simutrans-Experimental paksets made with the next version of makeobj (which will be released alongside 3.12) in which the loading time is not specified manually. This should provide a realistic counterbalance to the high speed of aircraft (in reality, people do not often take aircraft for journeys where land transport takes less than about three hours precisely because of the loading time).

Incidentally, please note that, unlike in Simutrans-Standard (where the feature is optional in any case), passengers and goods pay for the full route distance, not just for the as the crow flies distance. This is subject only to the limitation that, for each leg of the journey, the total chargeable distance should not exceed a certain proportion of the as the crow flies distance. This would not, therefore, impede your revenue for aircraft passengers who take a long way around to avoid a slower land journey. Note also that speed is the only thing that passengers (and goods) measure when deciding which route to take: they do not take into account cost. It would be extremely difficult to design a weighted routing algorithm with more than one type of inter-nodal cost, the relative weight of each is context-specific.

As to the suggestion of having first class passengers - that idea (or, more broadly, the idea of having different types of passengers with different preferences) has been discussed before. It would certainly add a layer of interest and depth, but would be enormously complicated to program and balance. Since Simutrans-Experimental is currently in a long-term feature freeze, that is not likely to be possible for some time. However, it is a possibility to bear in mind for the long-term (and would encompass far more than aircraft travel).

3. Preferred lines and convoys

The difficulty with this, unfortunately, is that it would require the waiting time per line to be stored, which is not currently done. That would add a great deal of coding complexity, memory consumption and CPU time to the computation of waiting times and their uses. I am aware that the system of having a single best line or convoy has drawbacks, but, since changing the system would require fairly substantial re-coding, any change to the system will not be able to take place during the feature freeze. However, a number of versions ago, to ameliorate the difficulties caused by this in some cases, I made the time before which passengers switched from taking only their preferred line or convoy to being prepared to use any line or convoy shorter the shorter that the journey time for their next leg was.

***

Thank you both very much for your feedback (and, in effect, bug report) - it is most helpful. Sorry that it is not possible to resolve all of the issues fully at this stage: I hope that what I have done so far and what will be in 3.12 will be sufficient to make the game workable for the time being. Very glad that you have both taken such an interest in Simutrans-Experimental, and I shall greatly look forward to any further feedback.

[tick tock]

From now on, 'buses and trams will continue to have a default loading time of 2,000; trains, monorail trains and maglev trains will have a default loading time of 4,000; ships will have a default loading time of 20,000; and aircraft of 30,000.

Wow.  I'm very interested to see the effect on Avg Speed with these new loading times.  30,000 is 30 seconds, right?  Will these times actually be how long the convoy is required to stay at each stop?  Or is that time just added into the travel time calculation while the real time spent at each stop remains the same as it is now?

[jamespetts]

Tick tock,

the loading times will indeed be the full amount that the vehicles remain at each stop. As I wrote above, in reality, taking into account check-in and various security procedures, boarding an aircraft takes a very long time, so this should be realistic, and restrict aircraft's usefulness (realistically) to longer journeys. Of course, the figure can be adjusted for individual aircraft by pakset authors.

[tick tock]

Oh, I'm not arguing with the concept, I'm just contemplating the implications at this point.  This means that an airport that has been using only 2 or 3 loading areas to comfortably accommodate a line of several planes may now need a full complement of loading areas since each plane will now be sitting at the airport for a full 30 seconds.

[jamespetts]

Quite possibly - just like real life

[tick tock]

We'll also be able to look forward to bug reports like "Hey! My plane is fully loaded but it's just sitting there. What's the deal?!"   

[dantedarkstar]

@2. Alright. So how the waiting times are handled is what more or less I thought is the case, but wasn't sure. I wasn't aware that the passengers now pay for the full distance (within limits). I thought the standard simutrans procedure was in place.
About 1st and 2nd class - isn't it more about paksets than code itself ? I mean, the only thing in code to change would be to make cities generate both 1st and 2nd class passengers (possibly with set % for each, determined in simuconf). The rest is about putting 1st and 2nd type passengers into the pak. Or am I wrong ? Is it not possible to have pak designate 2 passenger type goods ?
One other thing to possibly code would be that 1st class passengers CAN load onto 2nd class vehicle, but only when there is no other route, and the comfort rating might take care of the rest (1st class require high comfort, 2nd class are content with much lower).
Anyway, not the thing to worry about at this moment I think
Hopefully the extended loading times will take care of some aircraft problems. Still at very long distances, there will be Paris-Moscow-Berlin behavior. Well, but if they pay for that trip... 

@3. Ah, but travel times are stored per line ? I remember them being displayed in the station "link". Well, it's not critical drawback of the current routing scheme. I know there is "timeout" for waiting for specific line.

[jamespetts]

Dante,

the change in the code would be needed for towns to produce two different kinds of passengers, and for different kinds of passengers to have a different set of priorities when choosing a route. Currently, town buildings produce only mail and passengers. (Note that the Japanese pakset has converted mail into "first class passengers", but then it is not possible to have mail).

As to aircraft - if, in the real world, it was faster to fly from Berlin to Moscow and then from Moscow to Paris to take a train from Berlin to Paris, then there would be people who would do that. If the loading times are high enough, however, Simutrans-Experimental's aircraft should display realistic routing behaviour.

Travel times are not stored per line - only the best line's travelling time is stored. Travelling time can be calculated per line (because travelling time, unlike waiting time, is calculated based on the distance and average speed, rather than an average of a set of actual waiting times), however.

[dantedarkstar]

Ah, I sort of remembered 1st and 2nd class passengers being somewhere, but I didn't remember it was "costing" the mail. I never ever transport mail though, so I wouldn't cry 

As for Paris-Berlin-Moscow, yes, in real world SOME might do that, but in here, everybody will, since it's the fastest. In reality people tend to care about their money, so price plays a role. But as I agree that trying to calculate price etc. would be probably too complicated.

About line choosing, if travel time CAN be calculated per line, then my initial proposal is doable - you compare
current line travel time (calculated from distance and speed)   versus   best travel + wait (stored on the stop)
(current line is the line of the convoi that arrived at station, and passengers are considering boarding).
If the line travel time is equal or better than travel + wait of the best, then passengers board. Of course if the line happens to be the best, it is automatically true, so you don't have to check if the line in question is "best" or not
Since convoi arriving at the station does not happen very often (often, but not very), the calculation time shouldn't affect the performance.

[jamespetts]

The fix for the traffic bug is now available in version 3.12.

Dante,

that is a very interesting suggestion in relation to the calculation of whether to wait for another convoy or not. It would add extra computation to the loading routines, but that should not be too much of a problem, since they are not time-critical, as they are called relatively infrequently. One possible modification that would be required to that is to deduct the time that the goods/passengers have been waiting already from the waiting time to be added to the best line or convoy's total journey time. I shall have to give that more thought - very interesting idea.

Does anyone else have any comments on Dante's suggested method in the meantime?

[knightly]

In reality people tend to care about their money, so price plays a role.

I perfectly agree with Dantedarkstar here. People are time-conscious, but they are also money-conscious. Time and money are 2 important trade-off factors in people's decision on which transport to take. Additional calculation is needed to achieve this, but maybe we can try to think of an efficient way to do that. IMHO, this is a very worthwhile thing to consider.

[jamespetts]

Knightly,

that may indeed be something to consider for the future, but not during a feature freeze (Of course, now that you have Git working, you could always create a Git branch to develop new features, which could be merged in after they are tested thoroughly).

(One issue, as I have mentioned in previous posts, with passengers also considering cost is that the results could be perverse or capricious if the player had no control over prices: there may be cases in which route A costs passengers more than route B, but the player would make more money if the passengers took route A but paid route B prices anyway. So, there would have to be some ability for the player to control prices. The trouble with this is that it adds enormous complexity to the player's experience, although there may be ways of simplifying it by, for example, having just one or two "discount" settings for a line or convoy. Nonetheless, this issue would have to be considered before passengers take price into account).

[knightly]

that may indeed be something to consider for the future, but not during a feature freeze

You are right. But still, we can dream about it and think over it for the time being.

there may be cases in which route A costs passengers more than route B, but the player would make more money if the passengers took route A but paid route B prices anyway.

Sorry, James, I can't quite follow what you mean by this. Can you elaborate with a simple example? Thanks a lot!

[jamespetts]

The most obvious example is where route B is run by a rival