Idea: metronome for timetables

[mopoona]

What do you think about implementing a metronome into the timetable function? I mean something like this:
Instead of choosing a minimum waiting time depending on the occupation of a vehicle you choose a minute of an hour, lets say minute 8 for station A. When a train (or other vehicle for that matter) reaches station A at 7:04 it unloads and loads again. Now it waits until 7:08 and departs. A train of this line arriving at 8:22 at station A (with the same preferences) would have to wait until 9:04.
This feature could be used to synchronise lines or to use a given infrastructure more efficiently, especially with mixed speeds.
The only complicated thing about this feature is to find a good equivalent to a minute (inside the game). I think the resulting advantages for players (for example on maps with less passengers) are very high.

[vilvoh]

The equivalent to minutes inside the game are ticks..

[jamespetts]

I have considered in the past whether to implement timetables and rejected it because it would make things far too complicated for the player: although the interface for setting an individual vehicle's timetable can be made very simple, co-ordinating each and every line in an enormous map to fit in with each other timetable would be a gargantuan task. In real-life, it takes people with degrees in mathematics to prepare timetables.

[mopoona]

I did not mean every timetable/every station. Only a few halts would need this "wait for minute" tag. In passenger rail, these stations would be the last/first station and important nodes. This option would be only a addition to the already existing ones.
And I see no reason not to include this option. In fact, the biggest difference between SE and Simutrans Standard is the importance of speed. And this is one very powerful feature to ensure smaller waiting times. The swiss rail network shows how important that is.

[jamespetts]

Hmm - that's an interesting and unusual implementation. I'd be interested in comments from others, as it could possibly have unforeseen ramifications. One thing that I do wonder, however, is this: the clock times at the bottom left of the screen depend on the settings for the display of the time: only ticks (which are not revealed to the user) is a consistent measurement. I am not quite sure how how that would work with regular intervals as suggested (if, for example, the user chose only to show months/years)?

[mopoona]

Well, the games does know how much time a train needs to go from A to B in minutes. I don't know how these minutes compare to other dates inside the game.

[jamespetts]

Ahh, but those minutes are not the minutes displayed to the user on the clock at the bottom left: there are two distinct time scales in the game. To use the journey time clock for timetabling would require a whole new clock interface to be shown to the player.

[mopoona]

But this would be important to enable real synchronized networks like in switzerland...

[jamespetts]

Indeed: if one wanted to go as far as having timetable synchronised networks, it would be necessary. However, it would also be complicated: the scale for calculating journey times is quite slow (in other words, not much faster than real life time). How would synchronisation work effectively then? And I can imagine it becoming exponentially more complicated the more synchronised bits that must connect to other synchronised bits: suppose that one has a perfectly synchronised network of 'buses in one town, and another perfectly synchronised network of 'buses in another town and one then connects both towns with a railway - would that not potentially require the resynchronisation of every single 'bus in both towns? Or even if you had a gigantic network with everything synchronised with everything else, and new types of trains enabled you to reduce the journey times on your high speed routes - would you have to spend (real life) hours resynchronising everything?

[mopoona]

In fact, it's not that difficult if you are prepared to sacrifice some speed. Example: You are playing on a 512x512 map with one big city in the middle of the map and 8 smaller cities. If you want to synchronize all lines at a station inside of the big city, you just have to make a "wait for minute" tag at this station for all lines. Properly made, this should result in a situation like this: One trains of every line and every direction would wait 'til the chosen minute is reached. You just have to make sure, that all trains get to your hub in time (e.g. by setting a wait for minute tag at the last/first station).

If you want to do this in a perfect way, you would have to consider the speed of the trains.

[jamespetts]

You are assuming an extremely simple setup, however. I envisage 1024x2048 maps with 200 - 500 cities or more, with enormously complicated networks of many different players built up over hundreds of game years - that would be an enormously daunting task to resynchronise on every speed increase wouldn't it?

[mopoona]

Even on a large map of more than 2000x2000 and with more than 500 cities this is not that difficult. The main task would be to search for potential nodes and than set a minute. Normally you have lines with more than one train per hour.
On the other hand, it is more or less impossible to ensure that all you can ensure acceptable waiting times on very large maps. You have much to do without this feature, it wouldn't be more with it.

Think of a large map with less passengers than usual and low maximum waiting times. You would have to drive/stop the trains by hand, if you want to connect everything without any lost passengers.

But I understand the problem with the scaling. I have no idea what to use here. But if this question is answered, i think the implementation isn't that much of a problem.

[ӔO]

might it be better to base how passengers calculate their schedules if there is monthly wait time on the route?

Airplanes, for instance, you can have hourly to daily to weekly flights and that means you sometimes have to wait until a certain day in order to get to your destination. weekly flights are mainly international bound and more than 7hrs of flight, and hourly is domestic.

for the current implementation, wait times are also calculated as part of the average speed, so it's usually better to run passenger lines with no wait time.

[Junna]

for the current implementation, wait times are also calculated as part of the average speed, so it's usually better to run passenger lines with no wait time.

Something should be done about this issue, for there is no better way to distribute several convoys along a single line but to make them wait a certain amount of time at some end stop.

[inkelyad]

Max. wait for load in schedule exists exactly for that. Or you can use traffic lights.

[The Hood]

What about having a minimum time since last convoy on the same route?  This would default to zero (current behaviour), but if set, the time between that convoy and the previous convoy at that station on that route would have to be greater than the minimum in order for the convoy to set off from that station/waypoint, if not, it would wait there.  I don't know how wait times are currently programmed, but if the time since a last convoy on a line is already known at a station, this may be a way of achieving this behaviour without too much additional effort or complication?

[Brambo]

What about having a minimum time since last convoy on the same route?  This would default to zero (current behaviour), but if set, the time between that convoy and the previous convoy at that station on that route would have to be greater than the minimum in order for the convoy to set off from that station/waypoint, if not, it would wait there.  I don't know how wait times are currently programmed, but if the time since a last convoy on a line is already known at a station, this may be a way of achieving this behaviour without too much additional effort or complication?

I thought about this problem in the past, and the also thought the solution The Hood presents here seems to be the only one that is at least a bit practical. E.g. on most bus routes it would be sufficient to set this once on 1 stop only and get rid of all buses arriving at the same time. The problem lies in how to determine this time.Maybe it could be set automatically, based on computed journey times and the number of vehicles?

[ӔO]

for buses, you can set up traffic lights and change the timing so that they space out more.
there's a tutorial on how to do that in the help section.

[sdog]

bunching is already quite a problem in simutrans standard, but in experimental it causes massive loss, since passengers won't wait as long. Synchronised timetables would be way too much, but having something like mopoona suggested would come in pretty handy.


Oh, a possible simple sollution building on the reverse direction station/waypoint lists. When a convoy is at the middle of it's route and less than 20% full check the number of convois in the route going obverse or reverse. If there is a significant imbalance and more vehicles are going same direction as the convoy let it unload and reverse route. (possibly check if the stop is overcrowded, if yes go one more stop repeat procedure). I think this short-turning is what some public transport systems do on non timetabled routes.

[Junna]

Max. wait for load in schedule exists exactly for that. Or you can use traffic lights.

But the problem in Experimental isn't just that it piles up; for example, using a load and waiting time, even none too long - which would be sufficient in Standard for sorting the problem of convoys going too close to each other, will dramatically decrease the average speed of the line, resulting in dropping passenger numbers, sometimes to the point where nobody will ride at all (presumably this goes for using traffic lights as well) I think this could be fixed by perhaps making it so that dwelling time at a station or stop will not affect convoy average speed. Would this be difficult to implement?

[inkelyad]

Ok. I will do something about all this. But waiting at station is bad solution. It will block road/station for another player/convoy. How about slowing down some convoys until they are far enough from each other?

[sdog]

seems like we're with simutrans confronted with the same problems as in real life. bunching is a major problem, and the consequences it has are nicely simulated in experimental. a solution completely ameliorating the problem would not be good.
In real life it can be avoided for low utilization routes by introducing schedules and let the convoys wait at the stop until their time to leave. on high frequency high utilization lines it can not be avoided. sometimes dispatching convoys  (short turning, additional units for parts of the line,


I'm not so fond of the idea of slowing down convoys, afaik this is not used in real life. Except the driver who know's to be too early on schedule might do this. If the drivers is able to see the preceeding convoy already, it's too late to slow down, since the first convoy is always slower (full and first vehicles have longer loading times).
the schedules have one very fundamental problem, what if a vehicle is behind schedule? wait for the next time slot would be silly and cause a similar problem, when the whole line gets stalled. Thus the system would need to be flexible enough to let a convoy run behind schedule, and it would need buffers (e.g. at the end of a line where it could wait [that's again AEO's trafic light solution])

short turning is only useful for lines with many convoys.

some rough ideas (brainstorming):
- a specific building (actually trafic sign) doing the Trafic light workaround for buses automatically.
- this is actually what the bus-depot should do.   let players put a depot on the line, specify the time interval between convoys. and let the depot send out units. This would also help as a buffer for units getting delayed somewhere along the line. the part before the delay will still get enough convoys, after the obstacle there will be overcapacity but the depot will take it back before the next cycle.

- advanced choose signal for roads, let's linearly stack stops.

Code Select Expand


    /-PP-\
->-C--PP--E->-   ->-C--P-P-P--E->-
    \-PP-/             3 2 1

first sketch is the choose signals (C) as it is, it let's units choose one of several parallel platforms (P) before comming to a end of choose (E). Platform fields adjacent on the same road count as one platform. For buses it would be useful to have the first bus go to the furthest platform (1) on the same road (right figure), the next bus chose the platform (2) and so forth. Perhaps to discern it from multi tile platforms have one empty space inbetween. Buses/Lorries can overtake already so they should be able to get out even if the convoy on (1) blocks them. This would make having wait times at bus stops a possibility, when wait times are disabled for the last available free platform.

[inkelyad]

introducing schedules and let the convoys wait at the stop until their time to leave.

It is not hard to implement. Except GUI. And actually using it. It will be nightmare.

[ӔO]

another idea. How about dividing the average time it takes for the convoys in line to do one loop by the amount of convoys in the line?

I can see a problem if you run pax and mail on the same line, or even different vehicles, since they might have enough differences in speed and loading time to cause a difference in the average. So maybe set it for per vehicle type and treat each vehicle separately.

[inkelyad]

Metronome done.
How to use:
1)Line need to learn its length by road, so wait >4 convoys do full circle.
2)Enable 'Do spacing' checkbox for some stops in line schedule.
3)Adjust 'Max. wait' if you think it is too small.
4) Look at tooltips for convoys at stops.

Windows SDL exe at patches.simutrans-germany.com, github branch (James, don't merge it, I need to resolve conflicts with latest loading_queue).

[jamespetts]

Interesting; thank you for that Inkelyad. I don't think that this will make it into 9.0, as that is largely feature complete, but I should be very interested in how people find that this works in practice (especially on larger, more complicated maps) and whether it is practical or not; it would then be considered for inclusion in 10.0. Testers welcome!

[inkelyad]

It looks like a bug surfaced in Windows version. (sure, it exists in Linux too, but is hidden).
All convoy <-> line ownership will not be loaded from savegame. Sorry.

[Carl]

Concern: will this mess with the average speed of lines and thus effectively break the route-finding features?

[inkelyad]

Average speed -- no. But waiting times will be different (just like in 'wait for n% full').
Pathfinding, obviously, will be affected. I don't think it break anything.

[sdog]

i'm just testing this from your latest commit in your line spacing branch.

the effect is a bit difficult to see. I've got two parallel roads with 5 stops, 30 fields length and 3 vehicles (speed 24 km/h). With a factor of 3 convoys/month for line 24 and no spacing set for line 23. The spacing is the same for both groups after roughly 100 cycles. The only difference is that line 24 is lagging behind slightly. Per month 12 convoys were passing a stretch of road, this means 6 trips.

Testing with 6 convoys/month now. Spacing does not change, line 24 is only falling behind much more. With factor set to 12 it is even more lagging. Perhaps the lead vehicle of the bunch sees the last one still?

Setting to 1 convoy/month, spacing still the same for both groups.

Now testing if 'reverse route' has an influence, it is turned off and the return schedule is set manuallly. No change.

Deleting 1 vehicle now, only 2 convoys in each line.

After setting the factor back to 0, stopping the lead vehicle by opening 'schedule' will cause the next vehicle stop in the same field to wait for road clearance. In line 23 where no change to spacing factor was mad the vehicle stops one field behind.


Increasing the road length by factor 3, adding extra stops. testing again with factor 3 (and 20, 200)for line 24. No spacing effect observable, only general slowing of line 24.

[inkelyad]

Are you using it right?
Spacing enabled only on "Waiting for % load" stops.
Usually one spacing stop per line in enough.
And there must be enough convoys in line. Full loaded convoy will not obey spacing.

Download demo from this thread.

EDIT:
compare how demo works for "Wait for 100% load, Max.wait: 1/8, spacing: 0" and "Wait for 100% load, Max. wait: off, spacing: 8"

[sdog]

ah, i did not know it's required to set to wait for load. Setting it to full load i can quite see an effect. I did not have enough time however to actually tune the convoy/month parameter to get some equal spacing.

Two remarks. The max wait box can only be set when full load is active. This would be desirable for the spacing parameter too.

It is not fully compatible with bidirectional lines, there are easy workarounds however. Trains only take the first encountered platform when they are not set to 'wait for load'. For wait for load they will always take the platform designated in the schedule, unless they choose via choose signal.

Having line spacing set at a bidirectional line, bidirectional station would require it to go to the desired platfom. Workaround is having a platform choose terminal station at the end of the line and set line spacing there.

It's more difficult for circular lines, as there are no end stations.

Likely it's easy to fix this in the code, it'd be a bit too many conditionals for my taste however.

[inkelyad]

Two remarks. The max wait box can only be set when full load is active. This would be desirable for the spacing parameter too.

Spacing is whole line parameter, not per-stop. It is bit unclear where is should be enabled/disabled.

For wait for load they will always take the platform designated in the schedule, unless they choose via choose signal.

The reason 'wait fo load' convoys excluded from "first encountered platform": We don't want block mainline platform.
Usually some out of the way platform selected for waiting. We want keep that.

Workaround is having a platform choose terminal station at the end of the line and set line spacing there.

That is general idea: to have one service station which do spacing.

It's more difficult for circular lines, as there are no end stations.

It is same. service station with choose signal and multiple platforms can be par of circular line too.

Likely it's easy to fix this in the code.

Hard part is "what, exactly, do we want?"

[sdog]

Usually some out of the way platform selected for waiting. We want keep that.

yes, it is very much necessary.

Hard part is "what, exactly, do we want?"

let's see what the others think. Documenting it well enough should be enough in my oppinion, the workarounds in game should be easy enough.

Spacing is whole line parameter, not per-stop. It is bit unclear where is should be enabled/disabled.

Oh, yes, that makes it a bit more complicated. But still possible. Only activate it if at least one stop in line is 'wait for load' .and. not 'max wait'
Question is, if this is worth the work, if setting the parameter wouldn't do anything.

[sdog]

i've just loaded a game with line spacing, and it seems the parameter is not yet saved and/or reloaded.