Topic: [BUG?] Train choose signals force speed reduction to 50 km/h for other platform.

[DrSuperGood]

In a high-speed and efficient railroad network the choose signal is an important tool. It allows one to utilize multiple platforms in parallel for loading and unloading and so improve overall line throughput over a single platform solution.

However if the designated platform in the train schedule is blocked (a train is already there) the choose signal must find another platform to send the train to. When it does this it forces the train to drop speed to 50 km/h when passing the signal (as if the signal was red and the train had to stop). For slow trains that are only 60-80 km/h this is not really an issue since the speed loss is minimal, however for 270 km/h or faster trains it looks like they are about to hit a brick wall. The result is a significant line bottleneck to how fast trains can enter a station that is far larger than any other bottleneck on a common high-speed line.

What should happen. When entering the final block the train tries to locate a suitable platform. If it cannot it will keep trying until it is forced to slow down for the signal and eventually stop. If one can be found the train rushes past the choose signal at whatever speed it managed to keep and starts to slowdown once it reaches the end of the chosen platform.

What happens is unless the chosen schedule platform is free the train will always be forced to slow down to 50 km/h to pass the choose signal. This slowdown is non-trivial for high speed trains that can easily operate in excess of 400 km/h so will limit maximum line throughput. It also looks as if the train is about to hit a brick wall and slams on all breaks to drop speed, especially for high-speed trains operating towards the 400 km/h range.

I have only really noticed this problem now that high-speed train use in multiplayer sessions of pak64 is encouraged. Before then I only used trams which had a slow speed anyway so the signals made little noticeable difference.

The problem is likely because of route finding which I understand is a non-trivial operation. It would be nice if it could try to resolve the route when entering the final block rather than when approaching the signal to allow time for a possible full speed passing of the signal. In OpenTTD this was not a problem and I regularly had trains with "realistic" physics active running into dynamically chosen platforms at insane speeds.

[Ters]

Trains that are going to stop at a station won't generally enter the station at 200 km/h, so in one way the bug might be that choose signals don't slow down all trains (stopping at the station).

I have noticed something similar with long-block signals. Special behaviour is apparently not triggered until the moment the train reaches the signal.

I don't see how either can be a good idea on high speed routes, though. I want my high speed trains to move straight ahead, not divert to other platforms.

[prissi]

Usually the singal is tested four tiles before the signal. If there is no free route to the target (or some blocks in the long block signal occupied) it will deccelerate to 200 km/h and try again. Then retry at 100. And then, if it still not work, directly at the signal, a new route is searched.

Usually a choose signal is anyway at the entrance of a station, which is hopefulle not entred at 200 in any brached track.

[DrSuperGood]

Usually a choose signal is anyway at the entrance of a station, which is hopefulle not entred at 200 in any brached track.

Except you get the crazy situation where the train decelerates to 50 km/h just to accelerate back up to 200 while entering the station to decelerate back down a few seconds later. As I said, it works fine for slow trains but with high speed trains it literally gives that wall hitting feel as they drop speed very fast just to recover it very fast as well. Do not under-estimate how fast the fast trains accelerate due to the physics model used.

If possible it would be useful if it could try multiple tests for the platform before applying the first slowdown. If one is found then it should not slow down and allow the engine to proceed to it at whatever speed it was approaching the signal. Slowdown should only initiate if from the choose signal there is no free path to any platform of the target station as the train will need to wait at the signal. It would look much more natural as the trains will slow down slightly on-route to the platform (from the changing direction in case the platform is not straight ahead) and then slow down as it reaches the end of platform.

Currently...
Slowdown at choose signal -> accelerate to platform -> slowdown to stop at end of platform

Desired...
Pass choose signal at full speed -> slowdown slightly from required direction changes -> slowdown to stop at end of platform

[Ters]

Do not under-estimate how fast the fast trains accelerate due to the physics model used.

High-speed trains in pak64 needs many tiles to reach top speed (unless made unrealistically short), so it must be that your trains have been given a very high acceleration by the pak set author. So I don't think it's just the physics model, but how it is used. My trains hardly accelerate at all between the station entry signal and the station, at least when having to divert to the side.

[gauthier]

I agree that trains don't enter stations at 200 kmph ... and they usually don't slow down to 50 kmph before entering platform, they slow down to such a low speed only one or two tiles before the end of the platform. Slowing down is okay, but 50 kmph is too low.

it will deccelerate to 200 km/h and try again. Then retry at 100. And then, if it still not work, directly at the signal, a new route is searched.

This sounds weird, is that due to optimization issues (unability to do all the tries in time before the signal) ? In my games, trains always reach 50 kmph before the signal (and sometimes even stop).

A similar behaviour (slow down before signal) happens before long block signals too.

[prissi]

A route search can only be done in a step (since there is only one patchfinder and only one array to store the map), while the moving is done in sync_steps (for instance 4 sync_steps per steps in networkgames). Means that the train stops and waits for the next step (which might be three or four frames away if unlucky). This flickering (for a better word) looks much worse of course when the speed is higher. (This is also visible for circling airplanes, until the route search was delay to the end of the runway. Before I used the trick to limit the speed for them too).

Moreover, if the desired plattform is available, a train can pass at 200 km/h. It will only slow down, when it has to do a full route search. (However, a dedicated high speed line should get its own plattform with "exclude from choice" signs before.)

[TurfIt]

Quick'n'dirty proof of concept to run the route search while approaching the signal. No guarantees a step() occurs before the train has to start slowing, but as long as nothing too time consuming is occurring in step(), it should work for ~400 km/h trains. Tested only for the trivial case - likely to blow up spectacularly for many reasons. If changing this behaviour is desired, suggest someone else fix all the edges - else eta ~2020.

[DrSuperGood]

Moreover, if the desired plattform is available, a train can pass at 200 km/h. It will only slow down, when it has to do a full route search. (However, a dedicated high speed line should get its own plattform with "exclude from choice" signs before.)

You cannot park trains in a single platform for cargo. You need a choose signal for any form of terminal or yard so that the trains can park off the track. Yes I could spend ages doubling or more my number of lines, paving the map with separate rails etc to work around this however it would be simpler if the trains did not need to slow down for a choose signal.

Single platform is not a viable alternative, especially when load times are used to restrict turn around (a feature that is supported if I recall, just not used). In OpenTTD (another game) I had lines with such high throughput that 5 platforms were needed and continuously in use loading unloading trains and that game had no problem with a choose signal that did not slow down the trains. In experimental you need the same for freight lines due to the long turn around of freight coaches and reversing times.

Could it not be possible to defer the slowdown with choose signals? The train could only slowdown after the route finder has determined there are no available platforms (and only once it has done so) otherwise it keeps at full speed until then or the end of signal is reached in case it instantly stops. I would rather have some weird instant stops occasionally at choose signals with no free platform after than most of my trains passing the signal being slowed to 50 km/h.

[Ters]

You cannot park trains in a single platform for cargo. You need a choose signal for any form of terminal or yard so that the trains can park off the track.

Yes, but these are not high speed trains either. Since the trains are going to park, it doesn't matter that they slow down.

[DrSuperGood]

Yes, but these are not high speed trains either. Since the trains are going to park, it doesn't matter that they slow down.

It still looks a bit stupid that my 12 tile long pak64 RvG ICE trains running at 270 km/h are slowed down to 50 km/h to pass a choose signal (as the destination platform is seldom free) just to accelerate back up to >200 km/h (they accelerate very fast as expected for something with a 270 km/h top speed) before having to slow down at the end of the platform. I imagine it will look even more silly when this happens to a 448 km/h high speed train or a 700 km/h odd monorail.

[Ters]

It still looks a bit stupid that my 12 tile long pak64 RvG ICE trains running at 270 km/h are slowed down to 50 km/h to pass a choose signal (as the destination platform is seldom free) just to accelerate back up to >200 km/h (they accelerate very fast as expected for something with a 270 km/h top speed) before having to slow down at the end of the platform. I imagine it will look even more silly when this happens to a 448 km/h high speed train or a 700 km/h odd monorail.

If I have more than one passenger train per line at a station at any given time, I have too many trains on that line.

[DrSuperGood]

If I have more than one passenger train per line at a station at any given time, I have too many trains on that line.

Since this is a multiplayer server I need to have excess capacity to cope with the growth that occurs when I am not around. I cannot have barely enough passenger trains due to the volumes involved.

My one transfer station (as seen in the "moblet" server) is handling over 400,000 units of passengers/mail per month and it is connected to a public exchange of similar size and a smaller remote transfer which also handles hundreds of thousands per month.

The signals really should not slow down traffic like they do to some arbitrary speed. The speed should at least be raised based on the max speed of the convoy passing them.

[TurfIt]

The signals are not slowing trains down to some arbitrary speed. The trains are following the normal deceleration progression of 200, 100, 50, 0 as they approach a red signal. The trains are also coming to a full stop, not merely slowing to 50. They do instantly decelerate from 50 to 0, and then typically < 200ms realtime later instantly accelerate right back to 50, but they are at 0 speed for a while. Prissi detailed the reason above in his reply to you. My post right after had a potential fix. Feel free to take it and finish it.

[prissi]

Sorry, the patch does not really work. If the next sync_step comes before the next step, then find_route will be called during a sync_step. Especially when it is a fast convoi and get to the next tile first. Boom.

[TurfIt]

It is just a proof of concept, definitely needs work, although I was expecting more around handling someone deleting the signal, or other such world modifying things.

If the next sync_step comes before the next step, then find_route will be called during a sync_step.

How?  The find_route call in is_choose_signal_clear() is unchanged - only when in state WAITING_FOR_CLEARANCE. Is there some other call?
Multiple sync_steps before the next step is expected, and sync_steps from within a step. This occurs during my simple test case too which worked fine.

[DrSuperGood]

What if the pathing query was moved from signal approach to entering block? That way the train could have several tiles (6, 12, maybe more if needed) before it reaches the signal to resolve a route. Only if it fails to find one before the last 2 tiles before the choose signal would it use the deceleration mechanic. If people have trains stopping too often at choose signals they could then roll back the previous signal to allow for more time (eg for a 450+ km/h train which needs more tiles than a 270 km/h train). If the choose signal reservation is a huge problem then they could push the signal forward and reduce block size.

One could argue that this is fine tuning for a game mechanic (moving signals is not an intuitive mechanic) however it still gives the ability for the mechanic to function properly as opposed to currently where it results in slowing unless you use only 1 platform.

The only reason I am raising this now is that I only noticed it now. High-speed trains in pak64 used to be not really end-game viable so I used trams. Since trams only run at fastest of 90 km/h one did not notice the deceleration as much. Also freight is not really affected as again it is very slow. However with my high-speed RvG ICE trains it is very clear this is happening now.

From a visual perspective it is a disaster. Due to the non-dynamic slow procedure it looks like high-speed convoys are hitting a wall instantly decelerating from >>200 km/h to 200km/h and then slower. They then quickly accelerate back up to 200 km/h (since the acceleration curve is based on maximum theoretical speed) before stopping at the platform.

[Ters]

What if the pathing query was moved from signal approach to entering block?

It can't enter the block until it has found a clear path through it. Or if you are referring to the train entering the previous block, the situation might have changed by the time it reaches the signal. In busy stations with fast moving trains, it most definately will have. It can't reserve the block already either, because that will become a bottleneck fast. (Similar to the situation where I want a one-sided signal.)

[DrSuperGood]

It can't enter the block until it has found a clear path through it. Or if you are referring to the train entering the previous block, the situation might have changed by the time it reaches the signal. In busy stations with fast moving trains, it most definately will have. It can't reserve the block already either, because that will become a bottleneck fast. (Similar to the situation where I want a one-sided signal.)

I do not think it will bottleneck that much as it will allow the trains to keep at full speed instead of dropping to 0/50. You can always place a signal exactly 2 tiles behind it for the current behaviour as well.

[Ters]

I do not think it will bottleneck that much as it will allow the trains to keep at full speed instead of dropping to 0/50. You can always place a signal exactly 2 tiles behind it for the current behaviour as well.

Maybe not at 400 km/h, but at 100 km/h it most certainly does. The junctions between the last signal and the platform is a bottleneck as it is. Signal spacing shorter than the trains looks just as wrong as the quick reduction and increase in speed.

[prissi]

The same restriction with speed is also if signals are to close (i.e. on every tile lead to an effective speed limit of 100 km/h and every second to 200 km/h).This here is really a broderline case.

Moreover, if the intended plattform is full, then the train will likely also wait some time for passengers here.

[DrSuperGood]

Maybe not at 400 km/h, but at 100 km/h it most certainly does. The junctions between the last signal and the platform is a bottleneck as it is. Signal spacing shorter than the trains looks just as wrong as the quick reduction and increase in speed.

Which is why you break the junction into function units of 2 platforms. The theory is that it allows for turn-around capacity similar to a through station. If you have two such functional units working at quickest turn around time one will always be able to accept a train while the other will always have a train leaving. If that is still not enough you can use 3 or more such functional units. I have done this on the server as I needed good turn around rate as well as platform space and did not have the space to build through stations.

Developing functional units can be difficult. In pak64 the lack of elevated ways means that you are forced to use either tunnels or very restrictive line layout with bridges. Pak128 is more flexible allowing them to be more efficient. Gradient changes are always required in a terminal with separate functional units to make sure that no cross-over occurs between the units so this does apply a slight limit to throughput.

Also I use signals shorter than the train when entering and exiting anyway. When entering I do so to try and minimize the loss of speed from the choose signal and when exiting I do so to allow trains the soonest opportunity to move when speeds are slow.

Moreover, if the intended plattform is full, then the train will likely also wait some time for passengers here.

Yes however if a route to a free platform is clear then the train should not have to stop at the signal? Crossing a junction is such a short time even at slow speeds it cannot be really used as an excuse for slightly longer reservations.