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.

[inkelyad]

Yes, i don't want to break savegame compatibility.

[mopoona]

Did I get it right: Spacing is enabled only by line, not by station? So this does ensure a distance between 2 vehicles of one line?

[inkelyad]

So this does ensure a distance between 2 vehicles of one line?

More or less. But it is not distance based. It is time based. Parameter is 'convoys/month'.

[jamespetts]

I am just looking through this thread and other discussions on the topic to determine whether to include this patch in 9.0 or leave it until 10.x. One thing that needs consideration in particular, I think, is what Prissi wrote here about months:

First, the time you see in simutrans is different dependent on your setting. A month can be either three days or 28-31 days long. (The first option make sense when you have small number of bit_per_month).

Inkelyad - how does your code deal with this?

[inkelyad]

Inkelyad - how does your code deal with this?

It is why I use convoy/month -- it is affected by month length same way as 'max wait' setting. There is no clock/calendar confusion.

Industry production also use units/month. So 'right' value for convoy/month should be 'right' for any bit_per_month.

[mopoona]

I still would like to see that this feature is improved so structured timetables are possible in the game to ensure low waiting times and efficient use of the given infrastructure, like in my original request.
One example: Lets say you have network off many single-track rails. In SE, the average speed of line will decrease, when a train has to wait a long time before the track before it is cleared.

[inkelyad]

You want synchronization, right?
My patch will do this. Enable spacing on all stops => convoys on all stops will departure simultaneously.

But then trains will wait at stop. it is not much better.

Ex:
spacing is 30 cnv/month. path from A to B in only 1 km. Then convoy will wait almost whole day at B as journey time A->B is very small.

[jamespetts]

I have now, eventually, had a chance to test this - see my new branch on Github. I have also added the ability to save the "spacing" setting, although this will break compatibility with previous games saved using the 9.x branch home-compiled binaries. To make sure that older games can be saved, save them as Experimental version 8 before upgrading to the newer version on this branch.

Overall, it seems to work well, and seems to be a worthwhile additional option. One or two small things: first of all, the new code uses the "snprintf" method in simconvoi.cc, yet this method is not defined in any of the requisite include files, so it gives a compile error. It works file with the less safe "sprintf", but I am intrigued as to how you managed to get the version with snprintf to compile without additional #include files.

Secondly, there is a GUI glitch: the new spacing command does not appear when the schedule window is accessed through the convoy window rather through the depot or line windows. I have also tried to make the tool greyed out when it will have no effect as suggested by SDog, but this does not seem to work properly: it is only greyed out when the minimum load setting is returned to zero after being at another setting. This also applies to the maximum wait tool, so this may be a problem that ultimately comes from Standard, as I replicated the Standard code when implementing this.

Finally, I have produced a draft revised help file for the schedule window to take into account the new features, which I reproduce below. Please let me know if I have misdescribed the feature, or if it could be explained better:

Code Select Expand


<title>Schedule Help</title>

<h1><strong>Schedule</strong></h1>

<p>
The <strong>Schedule</strong> window sets the schedule for a <a href="convoiinfo.txt">Convoy</a> or a <a href="linemanagement.txt">Line</a>.
It lists<a href="station.txt">Stops</a>, where convoys pick up and drop off goods and passengers, and waypoints, which can be used to determine which route that convoys use, with their respective map co-ordinates.
</p>
<p>
The <strong>Schedule</strong> window for a particular convoy can be accessed by pressing the "schedule" button in the <a href="convoiinfo.txt">Convoy Information</a> window or  the <a href="depot.txt">Depot</a> window.
To open the <strong>Schedule</strong> window for a line, select "New line" or "Update line" in the <a href="linemanagement.txt">Line Management</a> or <a href="depot.txt">Depot</a> windows.
</p>
<p>
When the <strong>Schedule</strong> window is opened from the Convoy Information window, the assigned Line (if there is one) is shown at the top of the window.
</p>
<p>
<em>Serves</em> <a href="linemanagement.txt"><em>line:</em></a> This shows the line currently served by the current convoy. To change the line served by this convoy, click on the left/right-arrow buttons to cycle through the lines, or click on the name box to open a drop-down-list of the lines, then click one to select it.
Click on the name box and type new name to change the name of the line.
</p>
<p>
<em>Minimum load:</em> This is the minimum quantity of passengers or goods that must be loaded at the selected stop before the convoy will leave the stop for its next destination.
The percentage figure refers to the total capacity of the convoy and not an indiviual type of item carried.<br>
To use this feature, click on a stop in the list to select it, then use arrow buttons to cycle through the percentages, or type in a precise percentage in the text box.<br>
</p>
<em>Max. wait for load:</em> This is the maximum amount of time that a convoy will wait at a stop for the load level specified in "Minimum load". If this is set to "off", the convoy will wait as long as it takes to get the loading level stipulated. The remaining settings are proportions of game months: at 1/1, the convoy will wait up to one game month before departing the stop whether it has reached the specified loading level or not. At 1/512, the convoy will wait 1/512th of a month before moving off even if it does not have the specified level of load.<br>
<em>Tip:</em> Use this feature on lines carrying passengers, mail or other time-sensitive loads to make sure that the journey times are not too long if the "minimum load" feature is set.
</p>
</p>
<em>Spacing cnv/month</em>: This option only works if the "Minimum load" option is set. If this option is set in a schedule with a minimum load, the convoy will wait until either the minimum load specified is reached or the stipulated time (in fractions of game months: "2" is 1/2 of a month, etc.) has passed since the last convoy departed from this stop.
<em>Tip</em>: Use this feature to cause convoys to spaced evenly throughout a line, reducing waiting times.
</p>
<p>
<em>Mirror schedule:</em> If this option is selected, the convoys using this schedule will reverse the direction in which they follow the schedule when they get to the end of it. So, for example, if a line has the schedule A>B>C, if this button is not selected, the convoy will go A>B>C>A>B>C, etc. If this is selected, the convoy will instead travel A>B>C>B>A>B, etc.<br>
<em>Tip:</em> If this option is used with trains on double-track railways, the game will automatically work out which direction platform should be used, but this does mean that the exact platform cannot always be specified when this option is enabled.
</p>
<em>Alternate directions:</em> If this option is selected, each convoy assigned to this line will start in the opposite end of the schedule to the last convoy assigned to this line. This is useful for making sure that convoys are evenly spaced on a line.
<p>
Option buttons (click to use, button is indented when selected) include:
</p>
<p>
<em>Add</em> <a href="station.txt"><em>Stop:</em></a> This places a stop used by vehicles to pick up or drop off goods and passengers (water transport vehicles may use any square of water in the catchment area of a dock) or waypoint on the route.<br>
To add a stop or waypoint: click on the option to select (which changes the cursor to a "stop" arrow), then click the required point in the main game window for the stop or waypoint. It must be a point on road, track or water as appropriate for type of vehicle. A stop placed outside a station will automatically create a waypoint.<br>
<em>Tip:</em> Vehicles do not pick up or drop off goods and passengers at waypoints.
</p>
<p>
<em>Insert:</em> This places a <a href="station.txt">Stop</a> or waypoint on route, before an existing stop or waypoint.<br>
To insert a stop or waypoint: click on an existing stop/waypoint in list to select, then click on the insert button (which changes the cursor to a "stop" arrow), then click required point in the main game window for the stop or waypoint.
</p>
<p>
<em>Remove:</em> option deletes a stop or waypoint from the schedule. Click on the "remove", then click on a stop or waypoint in the schedule to remove it.
</p>
<p>
<em>Promote to</em> <a href="linemanagement.txt"><em>Line:</em></a> (only available when the <strong>Schedule</strong> window is opened from the <a href="convoiinfo.txt">Convoy Information</a> window) creates a new line using the current schedule.
</p>


Edit: One thing that I do notice with this, however, is that, when the spacing feature is used without also using the maximum wait time feature, the average speed can get very, very low and the journey times very, very high. Is this feature designed to be combined with the maximum waiting time feature?

[inkelyad]

Overall, it seems to work well, and seems to be a worthwhile additional option. One or two small things: first of all, the new code uses the "snprintf" method in simconvoi.cc, yet this method is not defined in any of the requisite include files, so it gives a compile error. It works file with the less safe "sprintf", but I am intrigued as to how you managed to get the version with snprintf to compile without additional #include files.

It is MSVC 'fault'. Microsoft don't like snprintf for some reason. See here.

Secondly, there is a GUI glitch: the new spacing command does not appear when the schedule window is accessed through the convoy window rather through the depot or line windows.

Spacing is line schedule feature, not convoy schedule. So it is more or less intuitive.

the stipulated time (in fractions of game months: "2" is 1/2 of a month, etc.) has passed since the last convoy departed from this stop.

It is not correct. Departure/arrival time don't used here.
It work like this:
Every 1/n month is departure time. If month == 30*24 hours, spacing=60, then convoys will depart at 00:00 and 12:00 every day.

One thing that I do notice with this, however, is that, when the spacing feature is used without also using the maximum wait time feature,

It is intended mode of operation. If journey time too long => you need more convoys and larger value for spacing.

Is this feature designed to be combined with the maximum waiting time feature?

It can be combined. Useful, if for particular station (busy hub, for example) spacing waiting can be too long and we wand override it.

Relevant code is in void convoi_t::laden():

Code Select Expand


        halthandle_t halt = haltestelle_t::get_halt(welt, fpl->get_current_eintrag().pos,besitzer_p);
        if(go_on_ticks==WAIT_INFINITE) {
                sint64 go_on_ticks_spacing = WAIT_INFINITE;
                if (line.is_bound() && fpl->get_spacing() && line->count_convoys()) {
                        uint32 spacing = welt->ticks_per_world_month/fpl->get_spacing();
                        sint64 wait_from_ticks = (welt->get_zeit_ms()/spacing) * spacing; // remember, it is integer division
                        int queue_pos = halt.is_bound()?halt->get_queue_pos(self):1;
                        go_on_ticks_spacing = wait_from_ticks + spacing * queue_pos;
                }
                sint64 go_on_ticks_waiting = WAIT_INFINITE;
                if ( fpl->get_current_eintrag().waiting_time_shift>0) {
                        go_on_ticks_waiting = welt->get_zeit_ms() + (welt->ticks_per_world_month >> (16-fpl->get_current_eintrag().waiting_time_shift));
                }
                go_on_ticks = (std::min)(go_on_ticks_spacing, go_on_ticks_waiting);
        }

it is easy to understand.

[jamespetts]

Inkelyad,

thank you for your responses - most helpful.

1. Thank you for pointing me to that. I  have used the workaround suggested there and it works nicely now.

2. Ahh, I understand now! I shall update the help file accordingly.

3. Is it assumed that every month has 30 days, or are adjustments made for particular months (and then for leap years); or is 60 simply a fixed number of departures per month? Also, does this represent 60 departures/month from each stop on the schedule, or 60 departures  per month from any stop on the schedule?

Thank you again for your help with this!

Edit: Updated draft help file attached:

Code Select Expand


<title>Schedule Help</title>

<h1><strong>Schedule</strong></h1>

<p>
The <strong>Schedule</strong> window sets the schedule for a <a href="convoiinfo.txt">Convoy</a> or a <a href="linemanagement.txt">Line</a>.
It lists<a href="station.txt">Stops</a>, where convoys pick up and drop off goods and passengers, and waypoints, which can be used to determine which route that convoys use, with their respective map co-ordinates.
</p>
<p>
The <strong>Schedule</strong> window for a particular convoy can be accessed by pressing the "schedule" button in the <a href="convoiinfo.txt">Convoy Information</a> window or  the <a href="depot.txt">Depot</a> window.
To open the <strong>Schedule</strong> window for a line, select "New line" or "Update line" in the <a href="linemanagement.txt">Line Management</a> or <a href="depot.txt">Depot</a> windows.
</p>
<p>
When the <strong>Schedule</strong> window is opened from the Convoy Information window, the assigned Line (if there is one) is shown at the top of the window.
</p>
<p>
<em>Serves</em> <a href="linemanagement.txt"><em>line:</em></a> This shows the line currently served by the current convoy. To change the line served by this convoy, click on the left/right-arrow buttons to cycle through the lines, or click on the name box to open a drop-down-list of the lines, then click one to select it.
Click on the name box and type new name to change the name of the line.
</p>
<p>
<em>Minimum load:</em> This is the minimum quantity of passengers or goods that must be loaded at the selected stop before the convoy will leave the stop for its next destination.
The percentage figure refers to the total capacity of the convoy and not an indiviual type of item carried.<br>
To use this feature, click on a stop in the list to select it, then use arrow buttons to cycle through the percentages, or type in a precise percentage in the text box.<br>
</p>
<em>Max. wait for load:</em> This is the maximum amount of time that a convoy will wait at a stop for the load level specified in "Minimum load". If this is set to "off", the convoy will wait as long as it takes to get the loading level stipulated. The remaining settings are proportions of game months: at 1/1, the convoy will wait up to one game month before departing the stop whether it has reached the specified loading level or not. At 1/512, the convoy will wait 1/512th of a month before moving off even if it does not have the specified level of load.<br>
<em>Tip:</em> Use this feature on lines carrying passengers, mail or other time-sensitive loads to make sure that the journey times are not too long if the "minimum load" feature is set.
</p>
</p>
<em>Spacing cnv/month</em>: This option only works if the "Minimum load" option is set. If this option is set in a schedule with a minimum load, the convoy will wait until either the minimum load specified or the stipulated departure time is reached. The "spacing" value represents the number of departures from the particular stop per game month, and a departure time for each vehicle calling at the stop is automatically calculated based on an even distribution of these times. This value is set for the whole schedule, not each stop.<br>
<em>Note:</em> This feature is only available for the schedules of lines, not individual convoys. The "spacing" setting will not be visible when editing an individual convoy's schedule.<br>
<em>Tip:</em> Use this feature to cause convoys to spaced evenly throughout a line, reducing waiting times.
</p>
<p>
<em>Mirror schedule:</em> If this option is selected, the convoys using this schedule will reverse the direction in which they follow the schedule when they get to the end of it. So, for example, if a line has the schedule A>B>C, if this button is not selected, the convoy will go A>B>C>A>B>C, etc. If this is selected, the convoy will instead travel A>B>C>B>A>B, etc.<br>
<em>Tip:</em> If this option is used with trains on double-track railways, the game will automatically work out which direction platform should be used, but this does mean that the exact platform cannot always be specified when this option is enabled.
</p>
<p>
<em>Alternate directions:</em> If this option is selected, each convoy assigned to this line will start in the opposite end of the schedule to the last convoy assigned to this line. This is useful for making sure that convoys are evenly spaced on a line.
</p>
<p>
<em>Add</em> <a href="station.txt"><em>Stop:</em></a> This places a stop used by vehicles to pick up or drop off goods and passengers (water transport vehicles may use any square of water in the catchment area of a dock) or waypoint on the route.
To add a stop or waypoint: click on the option to select (which changes the cursor to a "stop" arrow), then click the required point in the main game window for the stop or waypoint. It must be a point on road, track or water as appropriate for type of vehicle. A stop placed outside a station will automatically create a waypoint.<br>
<em>Tip:</em> Vehicles do not pick up or drop off goods and passengers at waypoints.
</p>
<p>
<em>Insert:</em> This inserts a stop or waypoint into a schedule immediately before the currently selected stop or waypoint. To insert a stop or waypoint, click on an existing stop or waypoint in list to select it, then click on the insert button (which changes the cursor to a "stop" arrow), then click the required point in the main game window.
</p>
<p>
<em>Remove:</em> option deletes a stop or waypoint from the schedule. Click on the "remove", then click on a stop or waypoint in the schedule to remove it.
</p>
<p>
<em>Promote to</em> <a href="linemanagement.txt"><em>Line:</em></a> (only available when the <strong>Schedule</strong> window is opened from the <a href="convoiinfo.txt">Convoy Information</a> window) creates a new line using the current schedule.
</p>


[inkelyad]

Inkelyad,
3. Is it assumed that every month has 30 days, or are adjustments made for particular months (and then for leap years); or is 60 simply a fixed number of departures per month?

30 days was an example.
It is fixed number of departures per month.

Also, does this represent 60 departures/month from each stop on the schedule, or 60 departures  per month from any stop on the schedule?

Uh, I don't understand this.

With spacing == 60 we will have 'table' of 60 evenly spaced departure times.
Every stop with 'Min load' will use it.

[jamespetts]

1. Right, thank you, that's helpful (and makes more sense).

2. I should explain more clearly: suppose that a schedule is:

Stop A
Stop B
Stop C

and the "spacing" setting is 10. Is that 10 departures/month from Stop A, 10 departures/month from Stop B and 10 departures/month from Stop C, or is it 10 departures/month from stops A, B and C combined?

[inkelyad]

Stop A
Stop B
Stop C

and the "spacing" setting is 10. Is that 10 departures/month from Stop A, 10 departures/month from Stop B and 10 departures/month from Stop C, or is it 10 departures/month from stops A, B and C combined?

It is former. What give you idea it can be latter?
It make no sense to do this.

[jamespetts]

Thank you for the clarification! I was just being a little dim, I think.

[jamespetts]

Inkelyad's patch is now included in 9.0.

[ӔO]

just to confirm, the convoy spacing feature must be used along with the minimum load function as well, correct?

Currently, as far as city buses go (50km/h), I get good results with
(1.5x buses / 1 stop (mirrored)) with 15 convoy/month
(2.0x buses / 1 stop (mirrored)) with 32 convoy/month
(2.5x buses / 1 stop (mirrored)) with 40 convoy/month
(3.0x buses / 1 stop (mirrored)) with 45 convoy/month

using mercedes citrao G that has 2100 loading time.
40~45 convoy/month seems to be the saturation limit for a bus with 2100 loading time.
These numbers are under ideal conditions with no other private vehicles or intersecting bus lines interfering.

[inkelyad]

Minimum load decision override spacing and max wait decision. When 'min load' = 0 convoy will not wait for anything.

Also, loaded up to 'min load' convoy will not wait too.

As for rest, I don't understand question.

[ӔO]

Minimum load decision override spacing and max wait decision. When 'min load' = 0 convoy will not wait for anything.

Also, loaded up to 'min load' convoy will not wait too.

As for rest, I don't understand question.

In order for this to work, minimum load must be greater than 1% and convoy/month must be set to 1 or more.
correct?

[inkelyad]

Yes.

[ӔO]

okay, thank you for clarification.

It seems to take some trial and error to get the timing right, but this is a fantastic tool. Great job.

[inkelyad]

Here is another demo.
Take note on end stop for bus -- it is cargo only, no passengers.