News:

Want to praise Simutrans?
Your feedback is important for us ;D.

reservation of longblocksignal

Started by THLeaderH, September 21, 2018, 05:53:43 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

THLeaderH

In current simutrans, a longblocksignal reserves only tiles behind a stop. The main reason of this is its algorithm with next_reservation_index. It is more reasonable to reserve all tiles that were checked.

This patch makes longblocksignals reserve all tiles that were checked. To realize this, next_reservation_index is abandoned and vector_tpl<koord3d> reserved_tiles is introduced.

The biggest benefit of this patch is that it becomes possible that a local train waits for the departure of an express train without waiting settings. A demo of new behavior is below.

prissi

The longblock singal is only to be used for tracks without further signals on them. In that form it would reduce the throughput of the main line a lot, sinc eit needs 12 tile signal spacing. The new greedy block "priority" signal is exactlz now included for this situation.

Also at every signal now the route is slowly appendend to a vector. This will impact performance with many trains.

Anyway, testing this patch exposed a bug in the long block signal route search, which search through the current position of the engine and thus waited on the way back of a branch line when a station behind it was occupied.

So I am afraid, I do not think this patch adds to game play, since the greedy block signals are better suited for this.

THLeaderH

Greedy block signals are not suited for this situation. My aim is to make a local train wait for the DEPARTURE of an express train, not the PASSAGE. For waiting a passage of a train, greedy block signals are well suited. To wait for the departure, the express train has to reserve the tile where the main track and the sub track merge. So the express train has to reserve beyond the end of its route when it stops at the station. This cannot be accomplished with any conventional signals, including greedy block signals.

Reserving tiles beyond the end of the route should be done with long block signals, not with greedy block signals, as Leartin stated before.
Quote from: Leartin on August 26, 2018, 09:40:18 AM
But okay, consider someone actually wants to build this constellation, I'd still look at the long-block-signal. I don't know why the long-block-signal does not reserve as much as it checked, since you would never want another train to enter that area after the check - else, why check at all? I'd assume it has something to do with performance, but since you would create a signal that would reserve anyway, I can't think of a situation where that would break an existing long-block-signal in use.
That being established, you could place such a reserving long-block-signal in front of the switch, no other signal on the "fast lane", a normal signal at the end of the "slow lane" and any number of gauthiers recursive signals before the long-block-signal. Gauthiers signal, according to the description, "Immediately tries to reserve next signal whatever its type", hence if there was a long-block-signal after a recursive signal, the recursive signal should already reserve the long block even beyond the station, so any "fast" train would reserve up to the switch where both lanes merge again as soon as the first recursive signal is hit, forbidding a train in the "slow" station to exit, while still allowing it to move up to the signal before the switch.
I still fail to see WHY anyone would want to do it, but you could do it without adding functionality to a signal that does not need it.

Performance issue you put is critical and I'm thinking about it. How about using a vector only when the reservation is done by a long block signal?

prissi

The thing with long block signals is, that they will reserve until the end of line or the next signal. Those may serve the situation you have mentioned, but will require no signal on the main line for many tiles. Also it will only work, if the two trains are directly behind each other.

But waiting for the express is useless. Passengers in standard Dimutrans will never change to the express train (unless we have also unloading all stops to force manual unloading. And even then many will still borad the local again ... ) So in standard letting a faster train pass may have a merit in the simulation, but waiting for a stop of the express train has none.

Leartin

Quote from: prissi on September 24, 2018, 12:08:27 PM
The thing with long block signals is, that they will reserve until the end of line or the next signal. Those may serve the situation you have mentioned, but will require no signal on the main line for many tiles.

The idea is to place one right in front of the express-station, after the regional station already split off. So you could have the long-block-signal right before the platforms, and the regional line coming back in right behind the station. Given that there are never signals in stations anyway, you can maintain your regular signal-every-two-tiles spacing, yet a regional train won't leave it's station as long as an express train already passed the long-block signal and is therefore entering the station. In order to have the regional train yield even earlier, just use greedy signals which would trigger the longblock early.

Useful? I doubt it. But I'm pretty sure it could work as intended, even if the intention is questionable. If it doesn't hurt, why not allow it? (And I get that it currently would hurt due to performance issues, but your argumentations sounds as if you wouldn't allow it even if THLeader could make it work)

prissi

No it will not work, since you would need no signals after the longblock signal. Hence two tile signal spacing up to the longblock signal and then nothing until after the express stop. This make it more or less useless for me.

Leartin

Quote from: prissi on September 24, 2018, 02:14:46 PM
No it will not work, since you would need no signals after the longblock signal. Hence two tile signal spacing up to the longblock signal and then nothing until after the express stop. This make it more or less useless for me.
Are you placing signals on a station???

gauthier

At first glance, I was not convinced of the usefulness of a such layout. As both trains have to stop and assuming they have similar performances regarding acceleration and maximum speed (otherwise one should not run them on the same tracks), there is nearly nothing to gain at making one overtake the other.Then here is a situation where it could be useful: trains both stops at station A, then they go to B where there is only one way (for any reason the player could not build an overtaking way). At B, only the local train stops. To ensure that an express won't be stopped after a local at B, overtaking even when calling at A, using the greedy-long-block-signal  :D would be usefull.
This is still a very specific situation and I won't support it if it could cause a noticeable drop of performances using vectors instead of indices. Was there not any solution to implement this keeping the index system ?

prissi

It still means no further signals until the next stations, which will strongly reduce throughput on that stretch. You can get the same effect with a special station layout, see below. All tiles in the following belong to the same station. All signals can be used after and before (and even in the station).

THLeaderH

This version of patch uses reserved_tiles vector only when the reservation is triggered by a longblocksignal. In other cases, next_reservation_index is used. This significantly reduces slow access to the vector and overcomes anxiety about performance.

prissi

I will have a look at it, although I am not sure this is really needed to slove any routing issues.

THLeaderH

This feature is already on OTRP and some bugs were reported.
These bugs are fixed in attached longblocksignal_reservation_v3.patch.