News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

[Feature request] Line Scheduling update

Started by Mariculous, August 20, 2019, 10:52:05 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Mariculous

I really like the line scheduling feature.
It is essential that it works the way ist does to allow single tracked lines used by multiple trains before time interval signaling with telegraph or even token block was invented.
Also later on it is still useful but the fixed time slots don't allow for any delay without high time reserves at these stops.

For railway lines without level-crossings this is not a huge problem as max. travel times are well calculable, assuming a network where all lines are scheduled.

However, most lines don't have such a setup. Addditionally, road traffic has some completely uncalculable factors, also known as private cars, which makes it pretty impossible to create a relyable schedule.

I propose an additional "max. delated departure" settings at scheduled stops.


btw. are posts like this better placed in the dev forums or in here?
This value sets a time interval in which a vehicle may depart the station even if it missed the last schedule slot, given that the last schedule slot was not used.
Naturally, a value of 0 means "when delayed, use the next schedule", which is the current behaviour, but one could use higher values where the exact departure is not that important as long as it is after some point in time.

This is often the case when a track is used by intercity and local trains. The local trains schedule will let the intercity train pass while waiting at a station.
Currently, if the local train is late, the intercity train can still overtake but due to the fixed schedule slot, the local train will wait for the next slot instead of leaving the station when it could still get back in time a few stations later.

Using the "max. delated departure" setting, the player can define when a train can get back in time, so it should continue its journey and when it can't.

Vladki

Yeah, I would also like to see such delayed departure feature.

Phystam

Yes, it will be very useful for us. Can we have a default setting for the tolerable time in simuconf.tab?

Mariculous

#3
What do you mean by a default setting in simuconft.tab?
When it's just some number that will be pre selected when creating a new "wait for time" stop in a schedule I'm fine with it but it should always be possible to manually set this to 0.
However, having savegame compatibility in mind, when loading saves from versions that did not have this feature, the default value should always be 0 otherwise, it could easily break early years schedule based single tracked drive_by_sight networks.
Also any other single tracked networks would be affected when a delayed train is entering a single tracked section when not being in a specific time frame, so the other train will be delayed, which can quickly snowball to all trains on that line running late.

Furthermore, I think any value other than "don't depart delayed" (max_delay_time=0) or "always depart when delayed"(max_delay_time=<time of one month>) strongly depends on the line frequency, other lines using that track and the track itself.

Phystam

Single tracked network with drive_by_sight is very dangerous... Such network usually makes severe stuck...
Anyway, in default, (if the delay tolerable time is not set) I agree with your opinion, it should be 0.
however, if you want to set the tolerable time for all scheduled stops, it will take much time to set them. not to spend much time, we have to have a user-configurable setting for this feature.

Mariculous

As long as the network is small and there are no level crossings with roads, which is always true for early networks, there won't be any factors that you can't calculate.
My first network was of that exact type. It had two lines and 5 trains on it and worked perfectly without deadlocking for 15 ingame years, which is much mre than any other type of network I ever yet created.

Well for scheduled stops you have to set the shift anyway. Setting the max tolerable time would be just another one. However, one could set some default value for new scheduled stops, so for scheduled networks one could simply set this to 0 manually.

Matthew

Quote from: Freahk on August 29, 2019, 05:14:05 PM
As long as the network is small and there are no level crossings with roads, which is always true for early networks, there won't be any factors that you can't calculate.

Why won't there be any level crossings with roads? I know that the gate graphics don't appear with gates until ~1835, but they still function as level crossings, don't they?

QuoteMy first network was of that exact type. It had two lines and 5 trains on it and worked perfectly without deadlocking for 15 ingame years, which is much mre than any other type of network I ever yet created.

Well for scheduled stops you have to set the shift anyway. Setting the max tolerable time would be just another one. However, one could set some default value for new scheduled stops, so for scheduled networks one could simply set this to 0 manually.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

Mariculous

You are right, level crossings before 1835 don't have gates but still work the same as later level crossings with gates.
However these aren't available in very early rail transport from ~1750 to ~1770

Due to this restriction early railway lines have to be designed without level crossings.

Matthew

Quote from: Freahk on August 29, 2019, 10:23:32 PM
You are right, level crossings before 1835 don't have gates but still work the same as later level crossings with gates.
However these aren't available in very early rail transport from ~1750 to ~1770

Due to this restriction early railway lines have to be designed without level crossings.

Thank you for explaining your point. It seems that the misunderstanding was caused by different definitions of "early".  :D
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

Octavius

Quote from: Freahk on August 20, 2019, 10:52:05 AMThis is often the case when a track is used by intercity and local trains. The local trains schedule will let the intercity train pass while waiting at a station.
Currently, if the local train is late, the intercity train can still overtake but due to the fixed schedule slot, the local train will wait for the next slot instead of leaving the station when it could still get back in time a few stations later.
Actually, that will only work as long as the passing loop is long enough and has an intermediate signal to hold two local trains simultaneously, else the next intercity will get stuck behind the local train.

Another consideration is what to do when the train has excessive delay. Waiting for the next departure slot of that line only really works if it's the only line serving that platform and there's room to keep a second train on that line for a short while without causing more disruptions. Furthermore, one train of that line will remain stuck at that platform until all trains of that line have run their entire schedule. One return train will get cancelled completely. In other words, waiting for the next departure slot for that line is only a good option at the terminus of that line when the terminus station has a spare platform.

In real life, when a train has excessive delay it's usually solved with some variation of skipping stations. Sometimes, it skips its terminal station, reversing back to its origin early and back on schedule. Sometimes it takes a shortcut, finding a shorter and faster route to its final destination by skipping an intermediate station. For example, a delayed train from Antwerp to Brussels via Brussels Airport could skip the airport. Sometimes a local train skips a few stations if it's not a long wait for the next local train calling at the same stations.

One could use some form of "IF train has excessive delay at this station, THEN depart anyway and skip ahead until entry #n in the schedule". That's not such an easy fix, but may be considered in a further reworking of scheduling (along with convoy recombination, facultative stops etc.).

Ranran(retired)

#10
"max. delated departure" looks basically a good idea. I also want a function that trains can operate on time.

I think that Simutrans is too sensitive to the load of cargo compared to the real world, so on-time operation is difficult.

Consider the on-time operation of the railway:
I think that two or three functions are lacking in order to realize scheduled operation in Simutrans and Simutrans-extended.

1. Extra time
1a) In the example of Japan's railway diagram, they have some extra time to travel between stations. Japanese guys are very strict in time and do not tolerate a 2 minute delay. So the crew apologizes again and again for the 2 minute delay.
However, if no abnormality occurs, it will be driven fairly accurately. A two-minute stop may be enough to be overtaken by an express.
Anyway, acceleration and braking will vary depending on the number of passengers and the weather. Rain and wind will have an effect. The driving skills of drivers are not constant.
Therefore, the travel time between stations fluctuates.
Then calculate travel time taking that into account. If the train arrives at the station early, take a break at the station.

1b) Allow extra time for stopping at the station. For example, it stops at the same time for 0 passengers and 15 passengers. This behavior is different from current extended's game system.
However, when it is very crowded, the scheduled departure time may be exceeded.
But if not, departure time adjustment will occur and depart at the scheduled time.
This is a big difference between trains and buses.


2. Constant acceleration function, brake adjustment
It is common for current EMU to have an adaptive load function. That is, the amount of current or braking force is automatically adjusted according to the amount of cargo.

2a) The actual acceleration of real world may also be adjusted.
The current EMU calculates the weight of the load from the amount of air in the air spring, and increases the propulsion by increasing the amount of current flowing through the motor. Therefore, the acceleration power is constant unless it is very crowded.
Steam locomotives do not always run at maximum power. Adjust the amount of coal thrown by the fireman.
Implementing an adaptive load feature may be difficult because the cost of fuel consumption must be considered. Also, the fuel consumption depends largely on the powering time.
For example, even if the distance between stations is the same, it will consume a lot of fuel if it is always uphill. Because the force required for acceleration increases, it must continue accelerating for a long time.

2b) Travel times between stations are not calculated using maximum braking. It is almost impossible for a driver to stop the train at the correct stop position from the maximum speed using only the maximum brake without waste.
So you usually use a slightly looser brake and adjust the braking force some times before stopping.
The effectiveness of the brake depends on the number of passengers. Some are calculated by the computer, in which case a strong braking force works.
Train which does not have this feature can still adjust with stronger brakes by driver.
That is, a slight difference in weight does not affect the train deceleration.
However, since the current extended braking force is always constant, the deceleration force weakens and delays as the number of passengers increases and the weight of the convoy increases.


This is a feature that will improve the situation:
3. Speed control by signal
With extended, for example, 5 levels of state are displayed in a 5aspect signal as in reality. But now it works either by allowing it to pass at max speed or stop except for the time interval signal.
As in reality, "caution" is not "slow down".
Unscheduled train stoppages cause significant time delays. The effect is particularly great for trains with slow acceleration such like express train. This is likely to further affect the following trains.
Normally, as the train approach the previous train, the speed allowed by the signal will decrease accordingly. In order for this to work properly in the game, signals will be placed at shorter intervals than currently, but it will not be a problem due to the ability to place signals at equal intervals.
This has the potential to improve the situation over double tracks with many trains going at high speed.
In the case of cab signaling, the distance to the previous train is calculated, the speed is controlled, and there is no need to stop as much as possible.
These actions minimize delays.

This feature is most useful for schedules overtaking trains.
Now, when the train catches up with the vehicle that is going to pass, it stops at the traffic light.
That feature allows train to approach just behind the previous train while slowing down until the previous train enters the evacuation line.
When the previous train evacuates, the signal on the passing line indicates "clear", so the train accelerates and overtakes. The important thing is to avoid stopping as much as possible. Imagine the speed at which the express train overtakes the previous train. It will overtake faster than if it were once stopped.
In this way, the improvement of the signal function may make the track flow smoother.

Currently, the time interval signal limits the speed of the train in extended, so I think it is possible to implement speed control by signal.




Thus, Simutrans train operation system is  much more likely to be delayed than in the real world. With no loading and no other trains in the way and no passengers getting on and off at the station runs on time, which, of course, almost always results in delays.
Usually the line will increase the delay each time you arrive at the station. It is likely that the result of expanding the delay through several stations will eventually exceed "max. Delated departure". Also, if you set "max. Delated departure" to a large value, it no longer makes sense. Because empty train just only arrive much earlier than trains that carry a lot of cargo. At first glance, each of them is just running as they wish, not the on time schedule.

EDIT:
Differences in formation are one of the factors that affect delay. In many cases, the number of vehicles is a big difference in weight, and the difference in one vehicle's model often leads to a difference in weight.
However, in reality, they operate on the same schedule even with such small differences on the same line.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Mariculous

Quote from: Octavius on December 27, 2019, 09:13:54 PMActually, that will only work as long as the passing loop is long enough and has an intermediate signal to hold two local trains simultaneously, else the next intercity will get stuck behind the local train.

Quote from: Octavius on December 27, 2019, 09:13:54 PMAnother consideration is what to do when the train has excessive delay. Waiting for the next departure slot of that line only really works if it's the only line serving that platform and there's room to keep a second train on that line for a short while without causing more disruptions.
This is already the case. I have some platforms shared by two lines being scheduled at that platform every 32 minutes, shifted by 16 minutes. Trains will wait 6-10 minutes for schedules at that station.
In that case it works well but waiting times are given immediately by travel times in between scheduled stations, so that's not always that well.
Imagine I only had 6 minutes of time at that station and again 6-10 minutes at the next station, I could simply allow the train to depart up to 6-10 minutes delayed and it will be more or less likely to get back in time at that next station even if it departed delayed.

For sure delayed departures can't fix any kind of delay issues. If the delay becomes too long, trains will still have to wait but it makes it much easyer to allow for some travel time variation without huge waiting times at each scheduled station.

@Ranran had a pretty detailed post about it.
1. Extra time can be implemented using schedules at each station while setting a relatively high max delay. Punctual trains will wait for that extra amount of time while delayed trains will immediately depart using the extra amount of time to catch up.

On-time services can work well with only that feature.
Point 2 seems to be closely tied to 1a. A train could travel slower if it still arrives in time at the next station, which will save some fuel in case the train is in time and help scheduling trains to enter a piece of track or a station in a specific order without stopping at a station just before.

However, as long as fuel consumption is not implemented, this would only be partly useful.

While the first two points can greatly improve scheduling in stations including overtaking while stopping at a station, the additional third feature will greatly improve
overtaking at passing loops but we need an addition for this: Choose signals need to route the previous train to the adversary tracks, otherwise the overtaking train will have to greatly decrease speed at the junctions, so passing lopps still need to be pretty long.

Octavius thoughts about excessive delay is in fact another problem that currently exists and will still exist with the suggested improvements but it won't happen that often anymore.
In Germany those trains usually continue delayed after reversing at their terminus, where they have a relatively long waiting times so they can compensate a relatively huge delay.
Sometimes, when they have a huge delay, trains will reverse eralyer. I don't know of any line that is missing intermediate stops to catch up.
In switzerland the train will usually continue delayed their whole journey but an additional train will start in time to ensure not too many people get affected by that delayed train.

I am not quite sure if conditional delay dependant schedules are great idea in simutrans-ex. What should we do with passengers that want to leave at a skipped station?

Phystam

In Japan, trains frequently delay due to overclouding in the morning, but the train never skip the next station. Changing destinations of the train to nearer station is usual solution.
Instead of scheduled time (using spacing and shift), if we could have a waiting time parameter at the station (this parameter will be used to waiting faster trains) , then the schedule will be more flexible.

jamespetts

This is a somewhat complex topic. However, I am not convinced at present that any further feature is needed to deal with the issues raised. The various things that Ranran describes that lead to there being less variation in timing between trains in reality than in Simutrans-Extended all ultimately amount to an added tolerance in the schedule in reality. This tolerance can already be simulated in Simutrans-Extended using the schedule feature.

The word "delated" is not an English word and I am somewhat confused by its meaning in this context. The way in which scheduling works in Simutrans-Extended is by use of intervals rather than absolute times. Thus, there is no concept of convoy X leaving stop Y at time Z. Instead, line N will have a departure frequency at stop Y of P: that is, P times per game "month" (6:20h), a convoy of line N will depart. When a convoy arrives at a timed stop, it checks to see when the next slot is; but there is a tolerance (I cannot now remember what it is) such that if it has missed a slot by a small amount, it is assumed to be late, and will depart as soon as it is ready. Is what is being requested here the ability to customise this tolerance per stop?

As to speed signalling, this has been discussed before. The basic idea is that signals showing a restrictive aspect other than danger are an indication that the train will need to stop at some point ahead sooner than the next scheduled stop. The reason for this indication is to give the driver enough opportunity to apply the brakes so that the train can stop in time for the next signal at danger. This is the basic idea behind all restrictive aspects other than danger in railway signalling, whether speed signalling is used or not.

The difference between speed signalling and the system used in the UK and some other places is that, in a speed signalling system, the distance between signals and the trains' braking capabilities are calculated when determining the speed limit to give any given signal aspect so that, if the driver follows the rules about what aspect determines what top speed, the train will be able to stop in time for the next signal at danger that the driver sees. The UK system, by contrast, does not prescribe a maximum speed, but the drivers are required to have detailed knowledge of the route so that they know how fast that they must brake in order to stop in time for the next danger signal. This can sometimes mean, for a train travelling at full speed, apply the full non-emergency brake force as soon as a signal at a restrictive aspect is sighted.

If we were to try to simulate speed signals in Simutrans-Extended, it would be necessary somehow to constrain the distances between signals very precisely: if the distances were too short for the speed, this would amount to an exploit, since the real life reason not to do this (that the trains would not stop in time for the danger signal and may crash) is not simulated. If the distances were too long for the speed, the player would be penalised as the trains would travel more slowly than necessary for part of the distance. This is not really a practical thing to do, so speed signalling has been omitted.
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.

Mariculous

I guess I confused "delated" with "belated", alternatively "late" or "delayed", don't know which fits best. That means a train arriving too late at a station to get its schedule.

About the schedule/
Six schedules a month (6:24) means a train will leave every 64 minutes, so at 0:00, 1:04, 2:08, 3:12, 4:16, 5:20 a train will depart. That's exactly the same as departing every hour at 0:00 given 6:00 per month instead of 6:24 per month, so I don't really see any difference in between "convoy X leaving stop Y at time Z" and a departure frequency.

Quote from: jamespetts on December 29, 2019, 03:53:48 PMbut there is a tolerance (I cannot now remember what it is) such that if it has missed a slot by a small amount, it is assumed to be late, and will depart as soon as it is ready. Is what is being requested here the ability to customise this tolerance per stop?
This is roughly what I requested. However, to disallow multiple trains departing late, we need to remember if a train used that slot already.

Ranrans suggestions go further by allowing trains to travel slower that possible if they are in time, so allowing time reserves in between stations instead of only time reserves by waiting at a station.
Whilst this can be useful in some situations, I don't think it's worth the effort unless fuel consumption gets implemented.

The third point is in fact very useful independently of schedules but I guess it's simply another signalling system/working method than the one used in the UK.

jamespetts

Quote from: Freahk on December 29, 2019, 05:16:19 PM
I guess I confused "delated" with "belated", alternatively "late" or "delayed", don't know which fits best. That means a train arriving too late at a station to get its schedule.

Thank you for the clarification: that is helpful.

QuoteAbout the schedule:
Six schedules a month (6:24) means a train will leave every 64 minutes, so at 0:00, 1:04, 2:08, 3:12, 4:16, 5:20 a train will depart. That's exactly the same as departing every hour at 0:00 given 6:00 per month instead of 6:24 per month, so I don't really see any difference in between "convoy X leaving stop Y at time Z" and a departure frequency.
This is roughly what I requested. However, to disallow multiple trains departing late, we need to remember if a train used that slot already.

The difference between the interval system and a true schedule system is that, in a true schedule system, each specific convoy would know which specific time that it is supposed to be departing from each specific slot. In this system, no such data are stored: just the overall frequency from which the actual departure time must be inferred at each stop.

QuoteRanrans suggestions go further by allowing trains to travel slower that possible if they are in time, so allowing time reserves in between stations instead of only time reserves by waiting at a station.
Whilst this can be useful in some situations, I don't think it's worth the effort unless fuel consumption gets implemented.

Fuel consumption is planned with the main scheduling/vehicle management features. Given the discussions here, there may be some merit to allowing players to limit the speed of vehicles in the schedule, but this will need careful consideration. If this were to be implemented, I imagine that it would be implemented as a parameter of a schedule, specifying a maximum speed for a convoy heading to that stop from the previous stop. The allowable maximum speed would also have to have a minimum, especially in the case of aircraft.

QuoteThe third point is in fact very useful independently of schedules but I guess it's simply another signalling system/working method than the one used in the UK.

I am not sure that I follow - what is the thing that is useful independently of schedules?
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.

Mariculous

Quote from: jamespetts on December 30, 2019, 11:04:25 AM
I am not sure that I follow - what is the thing that is useful independently of schedules?
It will allow multiple trains to travel nearly constantly at the same speed as the slow train occupying the track instead of stop-and-go ing, so the faster trains don't have to accelerate from 0 as soon as the slower train left their track.
This would be helpful e.g. for cargo trains that usually don't use fixed schedules but instead use wait for load.

Additionally, if one would modify choose signals (or create a special sign, signal or waypoint) to route a train causing a speed restricton to the alternative route, this would greatly improve passing loops.

I don't think setti g a fixed maximum speed to save fuel is a good idead with schedules in mind. Grains being scheduled for lower speeds have a great chanche to get back in time using a higher speed, so I guess setting a preferred arrival time as an arrival shift in schedules is a better idea.

jamespetts

Quote from: Freahk on December 30, 2019, 11:46:27 AM
It will allow multiple trains to travel nearly constantly at the same speed as the slow train occupying the track instead of stop-and-go ing, so the faster trains don't have to accelerate from 0 as soon as the slower train left their track.
This would be helpful e.g. for cargo trains that usually don't use fixed schedules but instead use wait for load.

But how in practical and economic terms would this actually add anything useful? What would be better about a constant speed?

Quote
Additionally, if one would modify choose signals (or create a special sign, signal or waypoint) to route a train causing a speed restricton to the alternative route, this would greatly improve passing loops.

I am not sure how you imagine that this would work and how it would be of assistance; could you elaborate?

QuoteI don't think setti g a fixed maximum speed to save fuel is a good idead with schedules in mind. Grains being scheduled for lower speeds have a great chanche to get back in time using a higher speed, so I guess setting a preferred arrival time as an arrival shift in schedules is a better idea.

I can only imagine it being extremely difficult to get a reliable algorithm for convoys attempting to achieve a particular arrival time.
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.

Mariculous

Quote from: jamespetts on December 30, 2019, 11:55:52 AM
I can only imagine it being extremely difficult to get a reliable algorithm for convoys attempting to achieve a particular arrival time.
While this is true, the algorithm does not need to consider other trains blocking the route. The gain of target aival times would be load independant travel times, so it is much easyer to create schedules where the track will be free. The only cases where this is not possible are highly used tracks and unscheduled lines at the track. For both, buffer times in the next station or upcoming less used tracks are required anyway.


Quote from: jamespetts on December 30, 2019, 11:55:52 AMBut how in practical and economic terms would this actually add anything useful? What would be better about a constant speed?
It will increase the traffic flow, thus slightly increasing tracks capacity. More importantly it will greatly improve passing loop relyability because the following, faster train will start overtaking at the same speed as the slower one.
Economically we will get increased track capacity, which can make a difference if you need to build an additional track.
When fuel consumption is implemented, this will also have a huge impact at fuel consumption.
Quote from: jamespetts on December 30, 2019, 11:55:52 AM
I am not sure how you imagine that this would work
If a signal showing a speed limitation is passed, the train causing that limitation gets roted to the alternative route if the alternative route is free.
Quote from: jamespetts on December 30, 2019, 11:55:52 AMand how it would be of assistance;
Trains entering the alternative route will most often slow down due to curves, so it takes much longer to overtake if the overtaking train has to slow down. The other way round the slowdown of the slower train would even assist the process of overtaking for both trains. The faster one can overtake faster and for the slower one it is less likely to come to a complete halt.

jamespetts

Quote from: Freahk on December 30, 2019, 06:53:45 PM
While this is true, the algorithm does not need to consider other trains blocking the route. The gain of target aival times would be load independant travel times, so it is much easyer to create schedules where the track will be free. The only cases where this is not possible are highly used tracks and unscheduled lines at the track. For both, buffer times in the next station or upcoming less used tracks are required anyway.

Even not taking into account conflicting vehicle movements, this would still be extremely difficult to code.

Quote
It will increase the traffic flow, thus slightly increasing tracks capacity. More importantly it will greatly improve passing loop relyability because the following, faster train will start overtaking at the same speed as the slower one.
Economically we will get increased track capacity, which can make a difference if you need to build an additional track.

I am not sure that I fully understand how speed signals as such (i.e. something approximating the German signalling system) are able to do this; and in any event, this does not deal with the insuperable obstacles to implementing an economically meaningful representation of speed signalling in Simutrans-Extended set out above.

Quote
When fuel consumption is implemented, this will also have a huge impact at fuel consumption.

I do not think that speed signals, as opposed to a means of limiting vehicles' top speed between pairs of stops in their schedule, is the right way to go about doing this, as it is dependant on players using a signalling system that implements speed signalling (i.e. none of the UK systems) and it gives the player no control. It also requires a large amount of other work to be done to implement speed signalling when far less work would be required to implement a schedule based speed limit system.

QuoteIf a signal showing a speed limitation is passed, the train causing that limitation gets roted to the alternative route if the alternative route is free.Trains entering the alternative route will most often slow down due to curves, so it takes much longer to overtake if the overtaking train has to slow down. The other way round the slowdown of the slower train would even assist the process of overtaking for both trains. The faster one can overtake faster and for the slower one it is less likely to come to a complete halt.

I do not understand this, I am afraid. Presumably, the train causing the restrictive aspect has already passed the signal, so how would one route that train retrospectively? Or have I misunderstood what you meant here?
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.

Vladki

Regarding the speed limitation by signals. I think it is not necessary to have hard limits, but something mimicking real world drivers would be useful. Something like this:
- if train runs at full speed and encounters a signal at caution (or preliminary or advanced caution), it continues and brakes as usual to halt at the signal at danger.
- if the train is not at full speed - typically due to braking when the signal ahead turns from danger to caution, or still accelerating from previous stop - it will not accelerate any more, until reaching the next signal showing clear or "more distant" caution.
- if the train was stopped, or at very low speed (say below 50% of trains or tracks maximum), it will accelerate as usual.

About the schedules. I think it would be enough to improve the current system with two changes
- flag if the latest departure time slot was used or not (probably we already have this to show green/cyan colored lines that miss their slots?)
- way to adjust the tolerable delay, and let trains depart if they are within tolerance, and the previous slot was not used.

jamespetts

I can see the possible utility of the schedule features, although there is a very long list of other things of at least equal importance; but I am still not sure that I understand the real economic significance of the signalling behaviour described compared to the existing signalling behaviour, given the really truly enormous amount of work needed for a feature of that sort.
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.

Vladki

Quote from: jamespetts on December 30, 2019, 10:30:15 PMI am still not sure that I understand the real economic significance of the signalling behaviour described compared to the existing signalling behaviour,
As said before - it _could_ provide better throughput. Trains will not start/stop that often if the start to catch up slower train. But I agree taht doing it right might not be easy

Mariculous

Quote from: jamespetts on December 30, 2019, 07:04:18 PMI do not understand this, I am afraid. Presumably, the train causing the restrictive aspect has already passed the signal, so how would one route that train retrospectively? Or have I misunderstood what you meant here?
I guess I need to illustrate it as soon as I'm home. In the meantime I will try to explain it from my smartphone.
That choose signal/passing loop functionality is not specific to speed signalling. It also works well for any other signalling system including moving block.
To make this work properly, a train has to look a few additional blocks or tiles ahead than reqiuired for working methods path reservation. i
If a train in that range is detected as being slower, that train will be marked as blocking. At a choose signal such a train will assume the path of the faster train behind the first junction after the choose signal as reserved, thus starting an alternative route search.
The blocking marker will be removed from a train if it was routed to an alternative route or it passed a given number of blocs without being marked as blocking again.

Quote from: jamespetts on December 30, 2019, 07:04:18 PM
Even not taking into account conflicting vehicle movements, this would still be extremely difficult to code.

I am not sure that I fully understand how speed signals as such (i.e. something approximating the German signalling system) are able to do this; and in any event, this does not deal with the insuperable obstacles to implementing an economically meaningful representation of speed signalling in Simutrans-Extended set out above.

I do not think that speed signals, as opposed to a means of limiting vehicles' top speed between pairs of stops in their schedule, is the right way to go about doing this, as it is dependant on players using a signalling system that implements speed signalling (i.e. none of the UK systems) and it gives the player no control. It also requires a large amount of other work to be done to implement speed signalling when far less work would be required to implement a schedule based speed limit system.

I do not understand this, I am afraid. Presumably, the train causing the restrictive aspect has already passed the signal, so how would one route that train retrospectively? Or have I misunderstood what you meant here?
Speed signalling aims at keeping trains speed more constant than n-aspect signalling. At least in simutrans-ex, a train following a slower one will accelerate/decelerate all the time, which is extrememy fuel consuming even for modern electric trains.
A scheduled maximum speed won't help much here as a slower train blocking a faster one is most often not something one would schedule but the cause of the faster train being belated.

jamespetts

Quote from: Freahk on December 31, 2019, 03:57:36 PM
I guess I need to illustrate it as soon as I'm home. In the meantime I will try to explain it from my smartphone.
That choose signal/passing loop functionality is not specific to speed signalling. It also works well for any other signalling system including moving block.
To make this work properly, a train has to look a few additional blocks or tiles ahead than reqiuired for working methods path reservation. i
If a train in that range is detected as being slower, that train will be marked as blocking. At a choose signal such a train will assume the path of the faster train behind the first junction after the choose signal as reserved, thus starting an alternative route search.

The blocking marker will be removed from a train if it was routed to an alternative route or it passed a given number of blocs without being marked as blocking again.

If I understand you correctly, what you propose is an extremely complex and sophisticated system that would probably take as much work to implement with the current signalling code as it would take to rewrite the whole signalling logic from the ground up.

Quote

Speed signalling aims at keeping trains speed more constant than n-aspect signalling. At least in simutrans-ex, a train following a slower one will accelerate/decelerate all the time, which is extrememy fuel consuming even for modern electric trains.
A scheduled maximum speed won't help much here as a slower train blocking a faster one is most often not something one would schedule but the cause of the faster train being belated.

If this is the only advantage, then it is not likely to be worthwhile the truly gargantuan amount of work required to implement this, as an equivalent advantage can be gained by limiting the convoy's speed using the proposed schedule speed limiting system. Also, this is not the purpose of speed signalling in reality: in reality, speed signalling is an alternative to (at least some aspects of) driver route learning, not a means of saving fuel. It would be extremely confusing for players for there to be an advantage to using speed signalling in Simutrans-Extended that does not exist in reality. Finally, it is also relevant that not all signalling systems use speed signalling; so this advantage would only be available to players who use paksets which simulate signalling systems that use speed signalling.
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

Quote from: Freahk on December 29, 2019, 12:59:54 PMIn Germany those trains usually continue delayed after reversing at their terminus, where they have a relatively long waiting times so they can compensate a relatively huge delay.
Sometimes, when they have a huge delay, trains will reverse eralyer. I don't know of any line that is missing intermediate stops to catch up.
In the Netherlands, they usually wait 5 to 15 minutes at their terminus before returning, so not much opportunity to compensate a delay (interestingly, I just discovered there are trains that don't return to their origin, but alternate between two lines. This way it stays shorter at its terminus, saving platform space). When the delay gets to more than about 12 minutes, they reverse early. That obviously has something to do with the relatively high frequency of dutch railway services.
Quote from: Freahk on December 29, 2019, 12:59:54 PMI am not quite sure if conditional delay dependant schedules are great idea in simutrans-ex. What should we do with passengers that want to leave at a skipped station?
The decision to skip a station (including skipping the terminus) is taken before the train leaves from the last station that's not skipped. Passengers can leave the train and recalculate their journey. It happens all the time here.
Quote from: jamespetts on December 29, 2019, 03:53:48 PMIf we were to try to simulate speed signals in Simutrans-Extended, it would be necessary somehow to constrain the distances between signals very precisely: if the distances were too short for the speed, this would amount to an exploit, since the real life reason not to do this (that the trains would not stop in time for the danger signal and may crash) is not simulated. If the distances were too long for the speed, the player would be penalised as the trains would travel more slowly than necessary for part of the distance. This is not really a practical thing to do, so speed signalling has been omitted.
There's no need to constrain the distances between the signals if it's dynamically decided (during signal placing) which aspects a particular signal can show, based on line speed and regulatory minimum braking deceleration. That's how it's done in real life – at least, in the Netherlands. Dutch railways have a very straightforward implementation of speed signalling, probably simpler than Germany.

Suppose a train runs from signal 2 -> 1 -> 0. Signal 0 shows "stop" and the signals are a full braking distance at 140km/h away from each other (about 1500 meters). Now signal 2 can show "proceed at line speed" because the driver doesn't have to do anything before he reaches signal 1, signal 1 shows "caution" and the driver can apply the brakes to slow down and stop before signal 0.

Now we move signal 0 to put it only half a braking distance from signal 1. We can no longer allow the train to approach signal 1 at line speed when it shows "caution". So, we add an aspect to signal 2. It will now show "slow down to 100 km/h" whenever signal 1 shows "caution". If the distance from signal 2 to signal 1 is a full braking distance, the train will run for half a block at 100 km/h instead of 140 km/h, which isn't optimal, but not that bad either. It looses about 8 seconds. It can be solved by putting a distant signal halfway between signal 2 and signal 1, but this is rarely done.

The difficulty with a fast train overtaking a slow train is that in real life everything on railways is scheduled – not just departures, arrivals and waiting time at passing loops, but also the order in which trains use a particular piece of infrastructure, something not (yet) possible in simutrans. If the schedule says "First train A, then train B", then train B will have to wait until train A has passed, even if train A isn't anywhere near yet. The entry of the passing loop says "First train A diverging, then train B straight", the exit says "First train B, then train A" and that's what's going to happen.

The controller can override (and that's what a controller is meant for), but as long as the controller doesn't do anything, the computer will operate all points and signals in the planned order and allow all trains to run in planned order, while ensuring no train runs early. (In recent years, computers are getting smarter. They can sometimes do simple things like swapping the order of two trains using the same diamond crossing.)

It seems there are several requests for changes in scheduling and there's also convoy recombination on the wishlist. That sounds like a complete redesign of the scheduling system. I have some ideas of my own, ranging from train ferries to slip coaches to mail (un-)loading without stopping. I'm considering to do some of the coding myself, but I first have to brush up my C++ (I'm mostly a C programmer) and familiarise myself with the code, so don't expect anything soon.