Transport Tycoon Forums

Ammler wrote:Basically, he (and we) would like to replace prio systems with presignals like here: http://www.openttdcoop.org/wiki/Prio#Pa ... _presignal

Greets
Ammler

I see what you mean, and I do understand the need for it. The problem is that implementing such a system is not so trivial. The biggest problem is when to update the reservation of the train in the LR block (on the main line):
1) Try to extend the reservation every tick. This would require that all trains in a LR block are listed somewhere. This would mean that quite a performance hit, as we would have to go trough all the trains in said list every tick.
2) Check for a train in an LR block when a train arrives at a non-LR signal (i.e. from the side line). This would mean that for every train that encounters a normal (or one-way) PBS signal the game has to check if the next block might conain LR-signals. That would again mean quite a performance hit.
3) Create some sort of weak reservation at the entrance of the LR block to the end of the block. A train entering an LR block would create such a reservation, allowing other trains that are already on the block to continue, but disallowing new trains to enter the block. When a train leaves a block that has been weakly reserved, the block is hard reserved by the next train. This might be a feasible approach, but it would require a new reservation type and probably quite some changes to the source.
4) Some other (and probably genius) ideas.

Well, there are my thoughts on the matter. I might even look into it, but I don't think I've gotten the time to write such a big patch (but who knows ).

Anyway, I'd like to here alternative ideas about a feature like this. I think it would be a great addition to the game, and a large step to making the old block signals redundant.

Ammler wrote:Basically, he (and we) would like to replace prio systems with presignals like here: http://www.openttdcoop.org/wiki/Prio#Pa ... _presignal

Greets
Ammler

Exactly. I don't like to build the type of layout OpenTTDCoop does for its prios (with all the "false" track), but the concept of prios itself would be very useful to maintain flow at crucial lines for me. The LR Path Signal seemed an elegant way of implementing them. Anyway, keep building this patch, as it's sure to be useful for quite a few players.

EDIT: Of the options you listed, I'd go for 3. But it's probably best to keep this patch modest for now.

Jafinto wrote:4) Some other (and probably genius) ideas.

The following may be worth looking at:

When the last wagon of a train passes a signal, it calls a function to update all the signals in the previous block. This function (see signal.cpp) explores the entire signal block and adjusts the state of the signals according to the new situation. Perhaps it is possible to extend this mechanism, so whenever it meets a LR signal to which a path is reserved, the vehicle will try to extend its path.

I have no idea whether this would work or not, it's up to you to find out

4) Some other (and probably genius) ideas.

Well, there are my thoughts on the matter. I might even look into it, but I don't think I've gotten the time to write such a big patch (but who knows ).

Anyway, I'd like to here alternative ideas about a feature like this. I think it would be a great addition to the game, and a large step to making the old block signals redundant.

Excellent!!! This is the thing i've been looking for!
You can use single track on both directions WITH line-blocking like on reality!!
Some advanced single-track configurations can be achived now!!!



Very much thank you! I've been looking this for ages just for single track bi-directional line-blocking. Now i've found it. How are the chances of this feature going in trunk?

Did he ever say it was a pre-signal replacement for priorities?

It's just one use where it's better than current PBS signals. If you prefer to still use the old system, go for it - this just allows you to do a "more" (as opposed to "fully" or "not") realistic system.

audigex wrote:Did he ever say it was a pre-signal replacement for priorities?

If you refer to my post, I meant el koeno with "he".

Else I agree, it is a nice addition to pbs, anyway.

Edit: well, if you read the first post in this thread, it seems also the idea of the creator.

Greets
Ammler

a bit shorter name: what do you think about PreReserving pbs signal, or just PPBS if I'm allowed

maybe we need 2way long reserve pbs signals (now still the official name) for kyosuke1989
now i'm waiting for the deadlocks (unless he added overflow depot or something )

avdg wrote: a bit shorter name: what do you think about PreReserving pbs signal, or just PPBS if I'm allowed

maybe we need 2way long reserve pbs signals (now still the official name) for kyosuke1989
now i'm waiting for the deadlocks (unless he added overflow depot or something )

There won't be deadlocks if you have enough sidings for other trains to pass.. And this single rail line-blocking configuration is not designed on large traffic.

EDIT: And it is realistic too.

Hmm. There is a flaw in that my design. If train should be in side track (opposite side) and there is two trains coming from other way, before the second train has updated it's reservation, the train from side track would get permission to leave towards train coming from line. Second train needs to have reservation block from other side.

kyosuke1989 wrote:i'ts

apihna

And it definitely doesn't have one there, of all places.

(bump)
What about altering the reserved length by the speed of the train. i.e. a train moving slowly (or stopped) will only reserve one block (block = track between signals) ahead, while a train running at 100mph will try to get 3 blocks ahead? Any block without a junction would be allocated without regard for speed (what you have already).

I'm thinking that trains around junctions wouldn't jam up with slow trains locking blocks for a long time.

I think that to get a priority, the signals have to be reserved backwards from the junction rather than forwards onto it. The signals could just be forced to reserve behind rather than just as far forwards as it can, until it reaches a signal that stops it.

What about weak reservations? i.e. a train locks track like normal PBS, but after that specifies blocks it would "like" to use. That way other trains could avoid desired tracks (pathfinder cost). But if no other route is available the second train overrides the 'desired' flags and locks it for itself.

Essentially you'd use this to lock up to junctions, but then only set "desired" afterward. When a train enters the segment before the junction, it would try to lock what it wanted. In this sense it mimics what happens in real life. As typically trains will be slowed down when arriving to a junction and when they near the home-signal, it is 'ramped up', i.e. it locks track further on.

Then again on UK rail, the junction is actually locked for the train and the home-signal will be yellow (or ramped up).