P****enger Preference

Topic: P****enger Preference (Read 2820 times) previous topic - next topic

P****enger Preference

May 24, 2010, 06:43:06 am

Hi,

I’m a long time player, first time poster to this forum. Firstly let me say how good Simutrans is, and how much better Experimental is. I acknowledge that Experimental wouldn’t exist without Standard, but I find Standard a little bit annoying to play with a p****enger network. The realism of p****enger movements in Experimental and the corresponding realistic transit networks makes it exciting to play. So, thankyou James, and everyone else involved in developing it.

However, one of the things that really bugs me (one of a few, but I’m not here to complain) is the following.

Say you have a network that looks like this…

A---B
\
C---D
/
E--- F

You have 2 lines, one A-B-C-D (Line 1) and the other E-F-C-D (Line 2). C-D is the inner city with relatively high p****enger numbers while A, B, E and F are the “suburbs” with low p****enger numbers, D may even be an interchange station with the broader network. The idea is to have twice as many vehicles travelling between C and D than A-C or E-C, a system I think many transit networks have around the world.

The first problem is when p****engers from C wanting to go to D will only (or prefer to) catch Line 1 because it runs more regularly. I know p****engers will catch Line 2 if they have been waiting a while, but this is not ideal.

The second problem, while rarer, is even more frustrating. P****engers from E want to go to D, so they board Line 2. But they change at C to get on Line 1 because it was “Faster” last month, despite the vehicle they are on going directly there.

There are countless other scenarios where this basic problem arises but I don’t think I need to go through them all.

Firstly, has anyone found a work-around for this? I know you could have one line that is A-D-E-D (all stops inclusive) but this is undesirable if you want more buses on one section than the other, or one is much longer than the other. For me, this introduces too much micromanaging.

If there is no work-around, what would need to be done to the code to reduce these effects? I think, and sorry if this is getting a bit wordy, that some tolerances need to be written into the code.

Say a p****enger waiting at C wants to go to D. Once he is there, he ignores the waiting time for a particular line and will catch any line that will stop at his destination. Any line, that is, within 20% travel time of the fastest line servicing the two stops. The 20% can be played around with in the balancing, perhaps even make it inversely proportional to the travel time.

I may have missed something blindingly obvious here and this idea could ruin other aspects of the game. I haven’t thought through what this could mean for p****engers who have to change lines and how it affects them. But I would like to explore the improvement of what I think is the best feature of Simutrans-Experimental.

Re: P****enger Preference

Reply #1 – May 24, 2010, 08:29:22 am

Dan,

thank you very much for your feedback - it is much appreciated. I am glad that you enjoy Simutrans-Experimental! These issues were discussed a little while ago, and, if I recall correctly, some changes to the code were implemented to deal with the issues that you describe. Either, therefore, you are using an old version, or the changes have not worked properly. The concept of a margin of error or tolerance, as you suggest, is the only practical way of fixing this, since it is possible to have something like:

A---B
\
C-----D-------------------------------J---------------I
/ \ \
E--- F -------G------------------------H------------------

with the E/F line going via G, H and I before returning to D via J: in those circumstances, p****engers should change at C when going from E to D. Do you find that this still occurs with the latest version? If so, could you perhaps upload a saved game with an example so that I can see it in practice and calibrate the tolerances accordingly?

Thank you very much for your feedback, and welcome to the forums!

Re: P****enger Preference

Reply #2 – May 24, 2010, 10:40:47 pm

James,

You are correct; I’m using a slightly older version of Experimental. I believe that it is version 7.1 (possibly 7.0, I’ll have to check when I get home tonight). I wouldn’t even like to guess what nightly of Standard I’m using. I have been hesitant to download the more recent experimental versions, as the “replace” feature, or lack there of, is something else that I now find frustrating in standard.

The scenario you outline above is correct, I find that p****engers from E-D will change at C, as would be expected.

I have just downloaded Version 8.0. When I get home tonight I’ll try and see if I can reproduce the problem and if so, I’ll send you the save game.

Re: P****enger Preference

Reply #3 – May 24, 2010, 11:09:54 pm

Dan,

searching the Simutrans-Experimental forum archives, I came accross this thread, which records that an attempt to fix this problem was implemented in Simutrans-Experimental 5.1. Have a look at that thread - is there anything that gives you to believe that the solution adopted as a result of those discussions is not working properly?

I shall look forward to your views on 8.0. Please note that I am about to go away on holiday, and should be back in about a week. In the meantime, however, I should be very grateful for your views, amongst anything else you think worth bringing to my attention, on the revamped convoy replacer, which has a number of new features to make cascading easier.

Thank you for your feedback, and enjoy 8.0 :-)

Re: P****enger Preference

Reply #4 – June 18, 2010, 03:39:38 pm

The "transfer time penalty" ought to account for this. The p****engers plan out their full trip in advance, if I'm not mistaken.

The time for the 'direct route' on line 2 should be less than the time for taking line 2 to C, then transferring to line 1 to get to D. Why? Because the transfer time should make the transfer take longer.

James, do you know exactly where in the code the comparisons between different routings for p****engers are made? Is it possible the transfer time penalty isn't being accounted for accurately?