[Patch] Long Reserve PBS signal

[Jafinto]

This patch adds another signal to the game: the Long Reserve PBS signal (I'm still looking for a better name).

This signal can be used to prioritize trains from a line, as is often needed when connecting lines with a main-line (coop-style). This can be done with the old blocksignals (see picture 1). But, when giving the train from the low priority line the choice between multiple high-priority lines, there are problems (I thought I saw a post about it on openttdcoop's blog, but I can't find it).

With the LR PBS signal, a train driving past it will try to reserve as much LR PBS signals in front of it (see picture 2). This also happens when the LR signal is already green.

So what do you guys think?

[Forked]

win32 binary attached

edit: nice one I like the idea.

edit2: binary removed due to GPL violation (it was missing the LICENSE, readme.txt etc.. this was not on purpose)

[Eddi]

have you checked advance signals?

[Jafinto]

have you checked advance signals?

That patch seems to have the same goal as my patch. It is strange though that it hasn't got a topic (as noted here. Is there any documentation on that patch available (ie. what do the different signals mean)?

[Eddi]

might find something in the IRC logs (that and the next few dates, probably)

[audigex]

I really like this idea, can you give more information on the signals? I can't quite work out what's going on from your pictures.

My idea on how to work it would be to have three types of signal.
1) Normal, bog standard PBS signals, work exactly as now and reserving one block.
2) Long-reserve signals which reserve as many blocks as possible (empty blocks up to a maximum or #3 signal, possibly with a setting, default at maybe 3/5)
3) No-reserve signals. Work as a standard PBS signal but a long-reserve signal will not reserve any blocks past this signal. Eg

2,1,1,1,1,1, will reserve 6 blocks
2,1,1,3,1,1 will serserve 3 blocks

[Jafinto]

I really like this idea, can you give more information on the signals? I can't quite work out what's going on from your pictures.

My idea on how to work it would be to have three types of signal.
1) Normal, bog standard PBS signals, work exactly as now and reserving one block.
2) Long-reserve signals which reserve as many blocks as possible (empty blocks up to a maximum or #3 signal, possibly with a setting, default at maybe 3/5)
3) No-reserve signals. Work as a standard PBS signal but a long-reserve signal will not reserve any blocks past this signal. Eg

2,1,1,1,1,1, will reserve 6 blocks
2,1,1,3,1,1 will serserve 3 blocks

I combined signals one and 3. A long-reserve signal will reserve as many blocks starting with another LR signal as possible. If it is not possible, for example when a train is in the way, it will try to reserve these blocks when it passes another LR signal. It doesn't matter if that signal is red or green (see pictures 1 and 2).

So, to stay in your terminology: the only 2 (important) signals are what you called signal 1 and 2. So in your examples:
2,1,1,1,1,1, will reserve 1 blocks
2,2,2,1,1,1 will reserve 3 blocks

Note that the LR signal is not a one-way signal, i.e. it can be passed from the back. I thought that wouldn't be a problem, since the most reasonably usage is after a normal PBS signal.

I like michi's solution though. If I understand it correctly, the frequency of a special signal indicates how many blocks have to be reserved.

[audigex]

Ah i get it now! I thought the signals with the red points either side were a special signal too

A 1-way version could be useful too though, depending on track layout.

[Jafinto]

Ah i get it now! I thought the signals with the red points either side were a special signal too

A 1-way version could be useful too though, depending on track layout.

Those with the red are the default one way signals in OTTD. About the 1-way version, that's the reason I liked michi's version, you can choose witch type of signal you like to use. On the other side, you do have to place (many) extra signals, and it will not reserve after you've passed the signals.

[Jafinto]

New version, with loads of bug fixes. The patch of michi was quite useful, looking at his code and seeing where my logic failed . There are still some parts I have written myself though .

There is still a bug there somewhere, and I haven't got a clue how I can change the sprites of the signal (there are a few good unused signal sprites in openttd(d|w).grf). I guess I'll have to search the code some more.

Any suggestions for improvements?

[Kelytha]

Works like a charm and the Combined North American Signals set has replacement for the sprites you used, so it not only works good, but also looks nice.

I hope this idea will get into the main branch one day, possibly together with a few other new signal types... you can just never have enough of them and each adds more possibilities to creative constructions.

[audigex]

Ah i get it now! I thought the signals with the red points either side were a special signal too

A 1-way version could be useful too though, depending on track layout.

Those with the red are the default one way signals in OTTD. About the 1-way version, that's the reason I liked michi's version, you can choose witch type of signal you like to use. On the other side, you do have to place (many) extra signals, and it will not reserve after you've passed the signals.

I'm still using an older version of trunk, the PBS signals just look like old 1-way start pre-signals

I'd really love this feature in trunk, it's one of the few things missing from YAPP.

[Forked]

win32 binary for v2
built against r15979

edit: binary removed due to GPL violation (it was missing the LICENSE, readme.txt etc.. this was not on purpose)

[Jafinto]

I'm still using an older version of trunk, the PBS signals just look like old 1-way start pre-signals

I'd really love this feature in trunk, it's one of the few things missing from YAPP.

Actually, it is the old 1-way pre-signal in the newer revision to . I just couldn't figure out where I could change it. Guess I'll have to look into it when I've got some free time.

[Expresso]

Nice patch. I'd love to see this in trunk (when it's reasonably bug-free).

Maybe you'd want your patch to change the save game version? So people testing this patch will get a nice error, instead of an assert, when they accidentally load a save game made with your patch applied in an unpatched openttd.

There's also some trailing whitespace in your patch, could you get rid of that?

[el koeno]

I like the idea, I have one issue though:

Santa Ana Transport, 11th Jun 1930 (Medium).png (241.87 KiB) Viewed 13603 times

In the screen shot there's a "main line" and a "side line". The train on the sideline is supposed to wait for the train on the main line. It does, for one train, but as soon as that one clear the merge block, the side line gets a green, blocking the second main line train, which was in the middle of its block, and thus unable to get a reservation for the merge block. Because the sideline train has to accelerate etc. it will block the main line, even though I built a prio-system that was supposed to avoid these problems.

I hope I made myself clear enough, otherwise feel free to ask for clarification.

[Jafinto]

The train on the sideline is supposed to wait for the train on the main line. It does, for one train, but as soon as that one clear the merge block, the side line gets a green, blocking the second main line train, which was in the middle of its block, and thus unable to get a reservation for the merge block.

This is intended behaviour. At the start of the LR PBS block, the train will reserve as much LR-signals as possible. If it can't reserve past a certain signal, it will simply stop the reservation at that point. The train does try to extend its reservation when it passes another LR-signal though.

If I understand your problem correctly, you'd like either an immediate reservation when a block is free. I have no intention of coding such a thing. You could approximate the effect though, by putting a LR-signal on every track on the main line and leaving quite some space between the signals on the side line. There will still be some trains from the side line getting in front of trains from the main line, but way less.

Anyway, here is another update that fixes a bug with trains that couldn't find a path to their destination but could find a 'safe' path. Oh, I also changed the save game version

I've also looked into the signals, but that is taking some more time because 1) I can't draw and 2) I do not understand the way OTTD loads the signals from the grf file. Any suggestions (especially on the latter) would be appreciated

[el koeno]

The train on the sideline is supposed to wait for the train on the main line. It does, for one train, but as soon as that one clear the merge block, the side line gets a green, blocking the second main line train, which was in the middle of its block, and thus unable to get a reservation for the merge block.

This is intended behaviour. At the start of the LR PBS block, the train will reserve as much LR-signals as possible. If it can't reserve past a certain signal, it will simply stop the reservation at that point. The train does try to extend its reservation when it passes another LR-signal though.

If I understand your problem correctly, you'd like either an immediate reservation when a block is free. I have no intention of coding such a thing. You could approximate the effect though, by putting a LR-signal on every track on the main line and leaving quite some space between the signals on the side line. There will still be some trains from the side line getting in front of trains from the main line, but way less.

...

Well, the thing is I'd like to create a priority system. Right now, if a set of trains comes along the main line, the first one will have priority over the side line. The next ones only stand a fifty-fifty chance (not sure about this) of getting priority over the side line if they happen to be at a signal at the exact moment the first train passes the merge block. Which is a big if. So if this is intended behaviour, your system is unfit to serve as a priority system, and I personally see little use for it.

[Jafinto]

Well, the thing is I'd like to create a priority system. Right now, if a set of trains comes along the main line, the first one will have priority over the side line. The next ones only stand a fifty-fifty chance (not sure about this) of getting priority over the side line if they happen to be at a signal at the exact moment the first train passes the merge block. Which is a big if. So if this is intended behaviour, your system is unfit to serve as a priority system, and I personally see little use for it.

I understand what you want, but I do not see little use for a system you propose . In the games that I play, the chance of two trains waiting for another one to clear from a junction is pretty low. If it happens a lot at one junction, I've gotten to much traffic on to little track and I'll have to increase the amount of tracks. That's where my patch comes in handy: when there two or more tracks to choose from that all go the same way.

[Ammler]

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

Greets
Ammler