News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

Request for two new timetable features

Started by dschr, September 30, 2014, 02:23:20 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

dschr

Hello,

While playing simutrans yesterday, i not just found the bugs which i already posted here, but i also saw the need of a typecast between timetable functions.
First, a definition: I will call a station, where a convoy has to wait to reach 400% load or a given departure time, a sync station -- As trains get punctual synchronized to the timetable.

The behaviour now is that a convoy at a sync station waits for the next free timetable slot and then departs.
I will use two scenarios to show the need of three different typecasts of sync stations:
First scenario:
A two track suburban line which has to share tracks in the city line with other lines. In the center part, the tact of this single line combines with other lines to a more dense tact with equilong intervals between upcoming trains. As a simple scheme, please refer to the drawing for S-Bahn on wikipedia:
https://de.wikipedia.org/wiki/S-Bahn#mediaviewer/File:Shema_U-Bahn_S-Bahn.PNG

The problematic is now that trains have to arrive at this central part in a very small time window, otherwise the line scheme does get messed up. On the other hand nobody wants to wait horribly long in the middle of a line for the train to depart. This is the reason why i usually only set sync stations at the end of lines in the termini stations. A Terminus station can hold more than one train and on long runs with a short time window, a Terminus station can hold a subsidiary train. This has the advantage that if an arriving train is delayed and will miss the next timetable slot, the subsidiary train can fullfill this service instead and so if one train is delayed, the upcoming services are still all in time again. I call this "self-healing", as the system is build in a way that mistakes in one timetable slot (here, a delayed train) are corrected without affecting the upcoming timetable slot. So, syncing in Termini has two advantages: -The fastest possible service on this route and - Subsidiary Trains for self-healing. This is our first type of sync station: The Terminus.

But for very long Suburban Lines (for those who have my savegame, please refer to the Berlin map and there to the S1 between Potsdam and Oranienburg), this is not enough to fullfill the inner city tact and to provide always same time intervals between different lines. So there also has to be sync stations placed in the middle of the line. But we still want to have a shortest possible stop -- the train should not loose time by standing still horribily long in the middle of the line. This middle sync station is at the S1 "Nordkreuz". You will see that most trains of S1 have to wait at Nordkreuz less than a minute -- that is acceptable. But some very full trains take more time between Oranienburg and Nordkreuz, so that 40 seconds is not enough. Right now, the actual timetable slot is left blank and the delayed train waits until the next timetable slot is reached. As this next slot is already filled up by the next train, a congestion accrues. This congestion will stay forever, if you use a subsidiary train. Otherwise it stays at least until every convoy frequented this station. And if you use a station to sync where more than one line holds at the same platform, a delay in a single line can doom the complete service with today's behaviour of sync station. So we need a second type of sync station: A limited sync station for the middle of the line.
I propose the following behaviour: In the line overview, a new feature is added: "Maximum waiting time". This is set to the value "Unlimited" or "Off" by default. The user can set this value for a stop to a limited time, let's call it k.
So in our scenario, if a train finished boarding at a sync station, it will only wait for the next timetable slot if the train has to wait less or equal than k. If the train should has to wait longer than k, and if k is set to for this stop to a limited value, the train should depart immediately instead. This behaviour would also lead to "self-healing", as the upcoming timetable slots wouldn't be no longer affected. The delayed train would run to it's other line end and would get there synced correctly. Also, if the sync station is used by multiple lines, the other lines may get affected, but since they all could depart to the Terminus without elongate the congestion, this mistake would get corrected in a limited amount of time.


Second Scenario:
A long single track overland route with exactly the needed amount of passing places and with a dense tact with more than two trains.
If a train get's delayed and does not reach the next passing place in time, the train of the reverse direction is affected. As the reverse train moves out because of the timetable slot, the block he wants to use is not free yet so the train can only truddle to the exit signal of the passing place station. There he has to wait until the delayed train comes in. Because of this waiting at the exit signal, the reverse train will also arrive delayed at the upcoming station and therefor will be the inhibitor for other trains to run in time. With the timetable functions now, this is not self-healing. Once this a train is delayed in this scenario, all other trains will be delayed in future. This makes it very prone to errors to run a stable tact on a single tact line with more than two trains.
Instead, i propose a third type of sync station: Long block Sync Stations.
With the right kind of sync station, it is also possible to have a Service on a single track line similar to the Self-Healing described above. Therefor a sync station needs a similar behaviour as a Long Block Signal: It must check wether the block to the Long Block section is free. So unlike today, where there is a test at the station for the timetable slot and after that another test at the longblock signal wether the next longblock is free, those two functions need to be combined. A sync station in this scenario needs to check for both and only let's the train depart if both tests are true. If the train misses it's timetable slot by one of the tests, it has to wait for the next timetable slot, where the both checks are made again. By this, a delay of one train would let all convoys on this line miss one slot, but after this everything is in time again. So as a delayed train affects also all other convoys, this is not exactly a Self-Healing Service, but as everything is corrected after one tact, this is the closest you can get in this scenario.

So, in conclusion, i hopefully showed why i think that there is a need for these two new features.

Please write me a message with your email adress so that i can send you the savegames.

jamespetts

Thank you very much for your suggestions, and apologies for not having been able to review these sooner: I have been preoccupied of late with moving house, which I have still not completed.

As to the two suggested features, the first should be relatively straightforward to implement, albeit there will be some fiddly work needed with the GUI and this will require changing the saved game format (meaning manually rescuing old saved game files saved in a non-release version).

The second, however, is much more complex, as it it alters the relationship between a station and a signal, and it is not clear to me quite how this might work in the code. I do eventually plan to overhaul the signalling system quite significantly, but there are quite a number of higher priorities with which I need to deal first. It may be that this feature can be considered when the signalling is overhauled.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

The main issue with time tables currently is it is impossible to optimize them based on the game dynamics. You need to convert the hours shown for the average round trip time (which factors in wait time unfortunately so is inaccurate) into months and then work out how many times per month the convoy will go around and then multiply that by the number convoys you have and then round down and hope everything works. You then need to watch if any time slots are missed and repeat when you realise you need to be adding 2 convoys per month to cope with rising traffic.

I would strongly recommend having a graphed metric for the line "slots missed" which represents every time a slot came up but there was no convoy waiting for it. This way you can over estimate and then optimize in a fraction of the time.

jamespetts

Dr. Supergood - that is an interesting point about the different measures: timetabling really, I suppose, ought not be done in months at all, but in hours; but how would that actually work, I wonder?

As for a graph for "slots missed", that is another good idea, but I am not entirely sure how one would go about detecting when this occurs so as to count them.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

QuoteAs for a graph for "slots missed", that is another good idea, but I am not entirely sure how one would go about detecting when this occurs so as to count them.
The inverse graph would also work ("on time convoys"). That is probably easier to do as you can tie it to the event of a convoy departing after waiting for a slot. The idea is that if you are aware that some slots are being missed you can adjust your schedule or add more convoys. Currently it is very hard to tell if slots are missed, especially if a line shares a common way with other lines.

killwater

Then one can subtract the amount of convoys departed after waiting from amount of slots available and then get the amount of slots missed. It should be easy to calculate amount of slots based on timetable setting/month. Then average through few months and it should be a good benchmark.

DrSuperGood

QuoteThen average through few months and it should be a good benchmark.
Anything that requires that is not viable. Sure if you are playing "line simulator" then yes as you can devote all your time to your single line. However as seen on the server companies can have dozens of huge lines.

A streamlined process should be...
1. Estimation of how many convoys per month. This should be a number given to the user somewhere in line statistics based on guessed times (line is new) and average times (running for months). Prefer over estimation instead of under estimation (to stop way blockages).
2. User enters estimation, plus a few slots into schedule.
3. User comes back a month or two later, looks at the slot missed metric and then reduces it appropriately so that no slots will be missed. Reduction could be larger than the slots missed amount to accommodate for traffic slowing the line down over time.

jamespetts

#7
I have been looking into implementing dschr's first suggestion. I have just pushed to the way-improvements branch some improvements to the timetable functions, including a new "wait for time" setting which removes the need to use the "wait for load" at a very high percentage (which was always something of a hack in any event).

I also notice that the maximum waiting time feature (currently named "Max. wait for load", but the revised English translation text that will be released with the next release will rename it "Maximum waiting time", as it is now not just used with the wait for load feature) already interacts with the spacing feature such that, if the spacing time exceeds the maximum waiting time, the convoy will leave after the maximum waiting time. This is not quite what dschr suggested, however, which was that, if a convoy is scheduled to wait beyond the maximum waiting time, it would depart immediately. Is the existing arrangement sufficient, or would a new per schedule option (perhaps termed, "Make up time") which has the effect for which dschr asks be necessary to make schedules self-healing?

Edit: Turning to Dr. Supergood's suggestions, I have just implemented a "service frequency" display in the line management window based on the collected round trip times for all the active convoys on the line with round trip data. I notice that there are two handy spaces available for new graph indicators in the line management window, too: one possible way of implementing Dr. Supergood's idea is to have one graph for "departures" (which would only register departures from schedule points with spacing set), and another for "scheduled departures" (simply based on the number of scheduled departures from timing points in the month). This would not, of course, show whether the convoys are departing from the right places, but would at least be of some assistance. Any feedback on this?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

A busdriver running late in traffic jam, would not wait for anything if he knows he's late. Maybe I misunderstood the suggestion, but wouldn't it be better instead to allow the vehicle to "run late" from the timeslot? If he arrives 2 minutes or less after a slot on his sync station, he may go directly, not waiting for the next slot?

I was thinking, isn't it possible to create a graph from the schedules?
Take time as one parameter and the schedule stops as the other? Then it would immediately become obvious what's happening.

jamespetts

Ves - I think that your reply crossed with my edit, above. As to the first point, this is not as simple as it seems, as the game does not know in advance for which slot that the convoy is aiming. Take your 'bus example. 'Bus A has a schedule of 10 stops, each 2 minutes apart (including loading time). 'Bus B is on the same route, 2 minutes behind. At stop 0, 'bus A is on time (0 minutes), and arrives on time at stop 1 at 2 minutes. A then leaves stop 1 and arrives at stop 2, again on time, at 4 minutes. 'Bus B, meanwhile, is at stop 1. Now, imagine that 'bus A runs into difficulty between stop 1 and stop 2, and arrives there 3 minutes after leaving stop 1. The code has no way of knowing whether this is 'bus A running late or 'bus B running early: if it is the former, it is better to let it go straight away, but, if the latter, it should be held for a minute. dschr's idea is to make the tolerance value customisable, I think, so that players can specify, for each stop, how much waiting would mean that the convoy is probably late rather than early and should drive on rather than wait.

As to the graph, see the above edit: is that the sort of thing that you had in mind?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

QuoteEdit: Turning to Dr. Supergood's suggestions, I have just implemented a "service frequency" display in the line management window based on the collected round trip times for all the active convoys on the line with round trip data. I notice that there are two handy spaces available for new graph indicators in the line management window, too: one possible way of implementing Dr. Supergood's idea is to have one graph for "departures" (which would only register departures from schedule points with spacing set), and another for "scheduled departures" (simply based on the number of scheduled departures from timing points in the month). This would not, of course, show whether the convoys are departing from the right places, but would at least be of some assistance. Any feedback on this?
Round trip time can have issues with responsiveness due to lines taking multiple months to do a trip (cross map lines in the server are a good example). That is unless it updates dynamically as it makes the journey (the old code the server uses is badly bugged). All departures from time-tabled stops (with a wait interval) would be enough since you can always divide by the number of them you have. It would be a problem if you did all departures from all stops unless you also put a "number of stops" field somewhere since some lines can have an unknown number of stops (well it is known to the game, just you never counted them at the time) so total departures might be hard to make sense of. The basic idea is to detect when slots are missed in a few seconds and not having to do advanced calculations or watch the line for months. Where as multiplying by 2-10 is easy (you seldom have more checkpoints), multiplying by 40-60 is less so.

jamespetts

Quote from: DrSuperGood on December 28, 2014, 01:19:59 AM
Round trip time can have issues with responsiveness due to lines taking multiple months to do a trip (cross map lines in the server are a good example). That is unless it updates dynamically as it makes the journey (the old code the server uses is badly bugged).

I was not aware of bugs in the round trip time code, and it was not I who wrote the code in the first place. Can you give me steps reliably to reproduce this bug? I should add that updating it dynamically would make the journey would make the code for it considerably more complex than it is now.

QuoteAll departures from time-tabled stops (with a wait interval) would be enough since you can always divide by the number of them you have. It would be a problem if you did all departures from all stops unless you also put a "number of stops" field somewhere since some lines can have an unknown number of stops (well it is known to the game, just you never counted them at the time) so total departures might be hard to make sense of. The basic idea is to detect when slots are missed in a few seconds and not having to do advanced calculations or watch the line for months. Where as multiplying by 2-10 is easy (you seldom have more checkpoints), multiplying by 40-60 is less so.

I am not sure that I fully understand this; do you mean that, when having a "departures" and "scheduled departures" graph, the "departures" graph should show only departures from points in the schedule that have a wait programmed into them? If so, that is what I was planning and should be relatively straightforward.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

While you are at adding graphs and diagrams, maybe consider how to make a diagram, available from the stop dialog, that have time as one factor and convoys as the other. Think this also would help a lot in getting an overview of convoys and schedules

jamespetts

There is already a graph in the stop dialogue showing the number of convoys departed in each month.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

No, not number of convoys as the one parameter but individual convoys as parameter, meaning the graph gets bigger (more entry's) the more convoys.

In other word:
A graphical overview of which times the convoys are leaving

jamespetts

That would represent quite a fundamental change to how the graphs system works, and would involve very major work.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

QuoteI was not aware of bugs in the round trip time code, and it was not I who wrote the code in the first place. Can you give me steps reliably to reproduce this bug? I should add that updating it dynamically would make the journey would make the code for it considerably more complex than it is now.
As I mentioned to you ages ago (as well as Sarlock) adding convoys to our long-distance cross map lines on the server resulted in average speed plummeting to 0 and round trip time raising to insane values like 5-8 times larger than the real round trip time. It eventually auto-corrects but since the round trip time is ~6 months this takes a very long time.

The steps to reproduce are simply add more convoys to my long distance freight lines. After adding enough you will see average speed drop, revenue drop to near 0 (as it thinks the goods are moving at 0 speed) and all goods re-riouting over Sarlocks network as an intermediate (before routing back to me at the end destination) as it thinks using me would take multiple times longer than Sarlock even though it is a direct route.

You said the waybranch improvement version might fix that however but I can tell you it is messed up in the server version.

QuoteI should add that updating it dynamically would make the journey would make the code for it considerably more complex than it is now.
Maybe just every month with some sort of correction? The current system is fine for passenger train lines where they usually completely circle in under 1 month but for long distance freight lines that take multiple months the responsiveness of trip time is very poor.

QuoteI am not sure that I fully understand this; do you mean that, when having a "departures" and "scheduled departures" graph, the "departures" graph should show only departures from points in the schedule that have a wait programmed into them? If so, that is what I was planning and should be relatively straightforward.
Yes exactly. Using this it would be easy to fix a route after a month.

Would it be possible if you could have a graph "convoy utilization" as well? By this I mean a graph that shows how many convoy months were either used or wasted that month on a line. Used convoy months are if a convoy is constantly moving/loading the entire month, even if it is stuck waiting for traffic or moving slowly. Wasted convoy months are months that a convoy spent waiting for goods/time table. The idea behind this is for multi-month lines to give you a rough estimation after a month how many convoys are still waiting to start so you can better estimate if you have too few/too many. It also serves another purpose of highlighting inefficient lines as any value larger than 1 means that in theory you could use 1 entire convoy less for the same service.

Oh another improvement is if you could please skip "impossible" slots? By this I mean where the depature time is considerably sooner than the unload time. With convoys that take greater than timetable period to unload you get clumping (multiple convoys leaving at once) unless you overload the line with enough convoys that the convoys can return and unload before running out of unloaded convoys. The idea behind this is that these lines would start out missing a number of slots instantly (say 6 or so for 30 minute shipping with 3 hour unload on ships) but then immediately have correct spacing from then on (no clustering).

jamespetts

Ahh, that old problem: that was, I think, an integer overflow, which I at least partially fixed, long ago, in the way-improvements branch.

The thing that would make the computation of the round trip time vastly more complicated than it is now is doing it other than by measuring the time that an actual round trip takes, which is the method done now. Doing it monthly would not make the programming any easier than doing it at more frequent intervals. The complicated thing is to work out what the round trip time will be without knowing what it actually has been.

As to a convoy utilisation graph, this does seem as though it would be quite complex to implement (as one would have to measure very precisely the time that every convoy is waiting and doing something other than waiting, and given that spacing time and loading time deliberately overlap, this would be hard, especially with convoys, such as ships, with very long loading times), and rather less critical than the other features on which I could otherwise be spending my time.

If you are able to compile the code, look at the way-improvements branch and let me know what you think of the timetable improvements so far. Do you have any views on dschr's suggestion earlier of a system of immediate departure if the maximum wait time is exceeded?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

Quote from: jamespetts on December 27, 2014, 10:14:57 PM
I have been looking into implementing dschr's first suggestion. I have just pushed to the way-improvements branch some improvements to the timetable functions, including a new "wait for time" setting which removes the need to use the "wait for load" at a very high percentage (which was always something of a hack in any event).

This sounds good; may I ask exactly how it works? Is it still a matter of determining the number of convoys per month (i.e. the service frequency) along with the spacing shift?

jamespetts

Quote from: Carl on December 29, 2014, 12:34:58 PM
This sounds good; may I ask exactly how it works? Is it still a matter of determining the number of convoys per month (i.e. the service frequency) along with the spacing shift?

Yes, the basic system works in the same way, but it is no longer dependant on the loading feature: instead of setting a line to wait for a 400% load that will never come, one simply sets it to wait for a time, which is marked with an asterisk in square brackets before the stop name in the schedule. The actual timing features work in the same way (and, as before, one can use the maximum waiting time setting to limit timetabled waits).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

I should add that, as of a few days ago, I have implemented Daniel's original first suggestion, which is that the "Maximum waiting time" (formerly "Max. wait for load") will act as a lateness indicator when "wait for time" is set: if the convoy has to wait for longer than the maximum waiting time at any given timed stop, it will assume that it is running late, and depart as soon as it has finished loading (and, if applicable, reversing). It will continue to act as before where a minimum load is set.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Octavius

In the real world, timetables have about 10% extra time. Trains take about 10% more time to run their route than would be possible if they were running as fast as they could. So, after a 30 minute run from the starting point of the route, waiting for 2 minutes at a sync station would not be unrealistic. Of course, in the real world trains are synced at every station, but doing this in simutrans would lead to a lot of undesirable micromanagement. It can be done though, and on a few occasions I managed to run 12 trains/hour/direction on double track or 4 trains/hour/direction on single track without ever seeing one train wait at a signal, which is close to the real world maximum. (Metro systems have very short braking distance and can therefore reach 90 second intervals.)

I also thought it would be nice to allow trains to run late, so that's a nice change. There's one small problem though, I think. If a train is too much delayed, it waits for the next slot in the timetable. Nice. But the next train on the same line will approach in time and wait just before the sync station, arriving at the entry signal just before the delayed train leaves. When the delayed train leaves, the next train will move to the platform and sees it's only two minutes late, so it leaves at once. Maybe it would be nice if there was a way to check whether the last time slot was used, and only leave delayed when it was not. Unless we prefer the scenario described below.

The second scenario in the original post reminds me of something I saw recently close to my home (nice to follow here). There is a single track railway with several passing loops at the various stations. Simplified track layout:
| | Nijmegen station
|X|
| | Mook - Molenhoek station
\|
  |
/|
| | Cuijck station
\|
  |
/|
| | Beugen former station
\|
  |
/|
| | Boxmeer station
\|
  |
/|
| | Vierlingsbeek station
\|
  |
  |\
  | |\
  | | | Venray station
  | |/
  |/
  |
  |\
  | | Mierlo - Tienraij former station
  |/
  |
  |\
  | | Lottum former station
  |/
  |
  |\
  | | Blerick station
  |X|
  | | Venlo station
(see here for all details)
The train operator runs trains on this line at 15 minute intervals during peak hours (which last quite long). The passing loops at all stations are used, but none of loops at the former stations are used. Obviously, this means that the trains have on average 7.5 minutes to get from one station to the next, including loading time, and actual travel time must always be less than 7.5 minutes. The distance from Venray to Blerick is about twice the distance between the other stations, which would work if there were a passing loop in the middle, but there isn't. Passing at Mierlo - Tienraij and Lottum would increase total travel time by 7.5 minutes, so instead service frequency is only twice per hour south of Venray.

On that day a few weeks ago I saw the northbound train from Blerick leaving 7 minutes late. By the time it was supposed to cross the southbound train at Venray, it was still south of Mierlo - Tienraij. To prevent the southbound train from running late too, the southbound train was sent on its way and the northbound train waited at Mierlo - Tienraij. The northbound train arrived at Venray 10 minutes late, by which time the next southbound train from Vierlingbeek, scheduled to reverse at Venray, was already on its way. So when the northbound train was finally able to leave Venray 12 minutes late, the next northbound train was ready to leave Venray too. Both trains went north at only 3 minutes interval, with all southbound trains passing two northbound trains at one of the stations. Funnily enough (except for the people on board), the same thing happened again just half an hour later. Still, 92% of the trains on this route run on schedule.

Of course, it's only possible to run with two trains in the same direction on single track at a 3 minute interval for 7.5 minutes when the track has been divided into at least 3 blocks. In simutrans we cannot divide a single track section into more than 2 blocks, as it may cause deadlocks. In the real world this is solved by setting the direction of the track for the entire single track section and only pulling the signal when the track is clear and set to the right direction. There will still be a deadlock when from both directions more trains approach than can fit on the passing loop, which sometimes happens in real life.

Two final remarks:
Tuning timetables with a non-integer number of hours per month is a nightmare. You can't create decent half-hour services. I solved this particular problem by redefining the minute to 64 seconds, which gives me exactly 6 hours per month.

I don't see any use for trains leaving when there is a time table slot OR its loading criterion has been fulfilled, but maybe someone else does. However, I do see a use for trains leaving when there is a time table slot AND its loading criterion has been fulfilled. This allows for facultative trains, goods trains only running when there is enough cargo to move, but only running at specific times, so that it doesn't get onto the main line just in front of that passenger express. In real life many goods trains are facultative and all goods trains use a timetable.

jamespetts

Thank you very much for your interesting comments. Some of what you write touches more on signalling, which is a project for the future, but I am interested in what you write about the combination of timetables and loading criteria, and I should be interested in any feedback from others about whether the current system or the system that is proposed here woudl be more useful, as it would not be hard to change the code in this way.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

dschr

I am really sorry for not answering for such a long time.
Thank you Octavius for your post! This was the discussion I initially hoped for. The example you gave is very interesting for me. The trains I use do generally use two-track lines, so my described solution derived only by thinking rather than how it is done at the real Railroad.
And yes, I agree that it would be most realistic to sync trains in all stations, but that would be a herculean task in simutrans.
Since I've read your example and as it seems quite complicated to temporarily allow Simutrans to have more than one train in a Block (and to automatically decide when this is appropriate) I'm still in favor of the first suggested version. I would say that this is the best solution in compromise between practicability and solving the actual problem of having a timetable on single-track lines.

To your final two notes:
I completely agree with you in both points! :)
In the past, I already complained about the strange time order a 3/4 year ago! I already pledged for a hard-coded 24-hour system (call it day or month...) with a parameter to vary the speed in which time flies by.
If the way time is calculated today would be called "internal" time calculation then the described 24-hour system could just be a "shown" time for the user & for the timetable.

The second point is true indeed. I haven't complained about this in the past as I never use freight trains in Simutrans but actually what you said does make sense and is worthwile. It is even feasibly to have the old behaviour back if this new method is implemented: One just needs to set a very high timetable frequency.







dschr

#24
To give an Overview:
Now there are three points regarding timetable/signalling:

1)
The maximum waiting time feature needs to change it's behaviour: It is most realistic if the train departs instantaneously after loading if max_wait_time comes earlier than the next free time slot. The today's behaviour, that the vehicle waits for max_wait_time-time units and then departs is unrealisitc and rather unsatisfying.
Done

2)
The described combination of timetable slot and long block signal would give the user a powerful tool for single track lines and the real example seems the underline this. I am having big hopes in James' reimplementation of the Signalling system here.

3)
Octavius' description of a combination of loading criterion and timetable has won my favour. So I would like to support this idea.

jamespetts

#25
It might help if I were to explain the latest as to the signalling improvements. I had not originally intended to undertake the signalling overhaul until after the next major release, but I decided to do so for two reasons: primarily because I needed to improve the simulation of the cost of ownership and operation of convoys in order for the game to balance properly (and the current plan is not to release any new versions until I have the game in a state where I can begin work on full cost balancing, as continuing to release an unbalanced game does not seem to make much sense when half the game lies in the balance), and that, in turn, required consideration of the possibility of convoy re-ordering during a journey, which, in turn, touched on the signalling aspect of things, as any such system would have to fit in wit the signalling system. The second reason is that I grew tired of seeing little people holding flags next to railway lines in the 20th century and beyond in the online game, as currently players have no incentive to replace obsolete signalling.

I am currently part way through the signalling project: I have implemented drive by sight signalling (the default mode), which makes things considerably easier for urban tram networks which now require no signals at all (modern trams that run both on street and on railway lines will need signals to achieve full speed on the railway sections), absolute block signalling, the traditional signalling method used for railways, and token block signalling, a variation on absolute block signalling used for single lines. I plan to implement track circuit block signalling (with multiple aspect colour light signals), cab signalling and moving block signalling (the latter two being very recent developments), and am considering whether also to implement time interval signalling (a very early method, although still used on some remote U. S. routes), edit: whether to implement speed signalling (which I have discovered was used in the UK at one point on one line), and whether a separate signalling mode ("working method") is required for RETB and one engine in steam. I also plan to introduce signal boxes: each signal would have to be assigned to a signal box, and each signal box could support a certain maximum number of signals. Furthermore, depending on the type of signal and the type of signal box, there will be a maximum distance between the signal box and any signal. To facilitate this process of assigning signals to signal boxes, players will build signals by choosing them from a menu that appears on clicking on the requisite signal box, rather than from the general railway toolstrip (from which signal boxes could be built). Deleting a signal box would delete all the signals assigned to it; it might be necessary to make a reassignment tool. Each type of signal box will be able to support only certain types of signals.

The different working methods are determined by the signal (if any) that the train has last passed. When first spawned from a depot, a train is in drive by sight mode, in which it will remain if it passes no signals. This will reserve a number of tiles ahead based on the sighting distance (currently fixed at 2 tiles, but will in the future be customisable), and restrict the train to the speed at which it can stop with its current braking abilities within the sighting distance. This is perfect for traditional types of tram, whose maximum speed is well below this in any event.

When a train passes an ordinary, two aspect stop signal, the working method is switched to absolute block: see here for details. The train will check where the next stop signal on its route is, and proceed on the basis that it has to stop at that next stop signal unless it can be seen to be clear, and it can only be seen to be clear when it is within the train's sighting distance. This means that, when only stop signals are used, trains will have to slow down in advance of each signal until they are going slowly enough that they can stop if the signal is at danger if they start to brake when the signal first comes within the sighting distance.

To avoid trains having to do this, using only two aspect signals (including all semaphore signals), a distant signal must be used. This was formerly known in Simutrans as a pre-signal. A distant signal is placed ahead of one or more stop signals. A distant signal will clear if all the stop signals before the next distant signal are also clear, otherwise it will be at caution. (Note that when I code signal boxes, all the stop signals on the route controlled by the same signal box will have to be clear for the distant to show clear). When a train passes a distant signal at clear, it can proceed at full speed past stop signals that were at clear at the time that it passed the distant signal. If the distant signal, however, is at caution, as in real life absolute block practice, it will have to slow down for each stop signal until it reaches the next distant signal.

An end of choose sign (which should now be considered as an end of zone sign, as it is no longer confined to choose signals) can be placed after a stop signal to indicate that the way beyond the last stop signal should no longer be checked, and that the train must assume that the next stop signal will be at danger no matter what the aspect of the previous distant signal. This is to prevent trains checking a very long way ahead on lines where distant signals are not universally used. This feature may be dropped when signal boxes are introduced, as it was intended in large part to assist a testing feature, although it might be retained if a use for it can be found.

In the absolute block working method, every time that a train stops at a station or a reversing waypoint, the working method is re-set to drive by sight, and likewise on emerging from a depot. To address this, all station platforms (except for single track stations on single track lines) should now have a signal at the end of the platform, as there is no longer an invisible, implied signal built into every station and other stopping place. If a train is starting from a station and the next signal on the train's route is before the end of the station (it is best to put it on the last platform tile, but this is not compulsory), then the train will not start from the station until this signal is clear.

Token block signalling is very similar to absolute block signalling, using two aspect signals, with a number of special adaptations for single line working. A train enters the token block working method when it passes a token block signal (formerly "longblock" signal; any longblock signal defined as such in any pakset will work for this purpose). In the token block working method, the train will reserve the section right up to the next stop signal, and, crucially, will not unreserve any tile through which it passes until it passes the next signal, helping to prevent deadlocks in single line sections. Signalling single line sections with two aspect signals now requires a different arrangement than before: at the ends of each passing loop (including a station with a passing loop), there should be a token block (longblock) signal facing into the single track section. Immediately before the next passing loop (including a station with a passing loop, but not a station without a passing loop), there should be a stop signal facing into the loop or station. Optionally (but highly advisedly), there should be a distant signal positioned a decent distance before the exit stop signal. Using this system, it is also possible to signal a blind terminus (i.e., a long section of single track with no passing loops ending in a single track station or siding with no passing loop): just place a token block signal at the entrance to the section facing into it, and a stop signal facing out of it just inside the section, and no train will enter the blind end when another is occupying it. With the model in the current release version, any blind end like this would lead to deadlocks.

As might be loosely inferred from some of the above, unidirectional signals no longer enforce a single direction of travel: trains can pass unidirectional signals in either direction, but they are only effective as signals in the direction in which they face. This makes it possible to have unidirectional signals on a single track stretch and at the exits of terminus stations. It does mean, however, that running lines that are intended to be unidirectional should have one way rail signs in the appropriate places.

As should be apparent from this description of token block signalling, this should, I think, solve the issue that dschr mentioned earlier with trains leaving a platform and moving forward a short distance to stop at a long block signal for a long time: these can now be built into the platforms and the train will not leave the platform until it is clear.

The development of different working methods is paused whilst I design new signal graphics to go with these new working methods, and, whilst I am about it, produce new signal graphics for all the signals, as the current signals in the pakset are all right handed, whereas we need left handed signals for the British pakset. The current signals were drawn, I believe, well before left handed signals were an option in Simutrans.

In  due course, I do plan to introduce a directional reservation system for use with bidirectional multiple aspect signals (i.e., the forthcoming track circuit block working method), which should allow tokenless block working over single track lines, including the practice of letting multiple trains travelling in the same direction enter the same stretch of single line at once. This should also allow for more robust bidirectional signalling other than on single lines, too.

I should note that, whilst the signalling features are under development, certain data related to the new features will not be saved, including the working method for trains, which will default to drive by sight on loading. This will be remedied before the release version.

In the meantime, I will look into making the suggested minor changes with respect to departure times and spacing, which, as stated above, should be relatively straightforward (I think that I might already partly have implemented some of this, but I will need to check again).

Thank you all very much for your helpful feedback so far.

Edit:

Quote from: dschr
1)
The maximum waiting time feature needs to change it's behaviour: It is most realistic if the train departs instantaneously after loading if max_wait_time comes earlier than the next free time slot. The today's behaviour, that the vehicle waits for max_wait_time-time units and then departs is unrealisitc and rather unsatisfying.

Are you sure that this is what happens? I did implement a feature to provide for instant departure when a convoy is detected as running late, which is defined as when the spacing time exceeds the waiting time. If this does not work, there may be a bug, in which case, I should be very grateful if you could let me know the steps to reproduce it. I have made one small change to the code here, which deals with an ambiguity which had a small chance of producing problematic behaviour with this.

Quote3)
Octavius' description of a combination of loading criterion and timetable has won my favour. So I would like to support this idea.

I have now implemented this feature:

Quote
I don't see any use for trains leaving when there is a time table slot OR its loading criterion has been fulfilled, but maybe someone else does. However, I do see a use for trains leaving when there is a time table slot AND its loading criterion has been fulfilled. This allows for facultative trains, goods trains only running when there is enough cargo to move, but only running at specific times, so that it doesn't get onto the main line just in front of that passenger express. In real life many goods trains are facultative and all goods trains use a timetable.

I should be grateful if you could test it to see that it is working correctly.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Wow! What nice new features you are working at! Really looking forward to try it out!
May i throw a suggestion in about the signaling:
You are about to allow for vehicles to reassemble. Maybe now at the beginning it will be more of a symbolic assembling (vehicles not actually moving around to form the convoys but maybe more like jumping between tracks?) but just for the sake of the future, consider to add or prepare a signal type that allows a convoy to enter a track with another convoy already on it (driving by sight). In skandinavia, such signals are represented by dwarf signals.

jamespetts

That is under consideration: we call them calling-on signals in the UK.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

dschr

Hello,

just a small update to the proposed features two and three:
Two is not implemented yet. Three is partly implemented:
If a vehicle once has it's loading minimum reached it will
start immediately if the timetable time was once gone. So freight trains will still depart at a random time if the waiting time for load > time it has to wait for the first time slot. This subvertes the idea of feature 3.

I want to improve my suggestion: There should be a new button, called
"strict mode" or "precise mode". This button should be in the same line
as "Wait for time" on the right (as you can see on the picture, there is
a nice free place for a button right at the mouse cursor).
This button should be off by default.
Activating it will change the behaviour for a single station. At this
precise station, a vehicle will only depart if all conditions are true:
free time slot right at this moment (expired time slots are invalid) &&
minimum load reached && platform signal can turn to green immediately.

Such a button would be similar to a implementation of feature 2 and the
missing part of the implementation of feature 3. And the player would know that the train has a different behaviour right
at this station. And if someone does not want/need it, he can simply let
it disactivated.