Transport Tycoon Forums

A: Would it be possible to make all YAPF signals use PBS by default? This would allow players to specify which PBS signals are and aren't pre-signaled, which would make a lot more interesting combinations possible.

B: How easy/hard would this be? I am not a coder and do not pretend to understand how it works, but I'm aware that some things are easier than others...where does this fall on the scale?

Edit: I just realized this might be more appropriate in the Suggestions forum...if a Mod feels it belongs there, then feel free to move.

PBS was removed from the main trunk because of bugs. Until the rewrite is done, I doubt they will put it back in...

gamezguy wrote:PBS was removed from the main trunk because of bugs. Until the rewrite is done, I doubt they will put it back in...

That was not his question.

A: I think that it would be possible, although I don't think that it would happen.

B: I will probably be as hard as actually implementing PBS. All the signals will just behave as PBS signals on default.

Don't forget that there are eight different types of signals; Normal, pre, pre-exit, combo, PBS, PBS-pre, PBS-pre-exit and PBS-combo. Hackykid's choice not to use the latter three types in no way forces KUDr to make the same decision.

Until PBS has the same requirements (including memory and processor-power requirements), limitations, and number of bugs as the non-PBS, the option to have non-PBSed junctions must remain.

hackykids choice was made because in hacykids implementation, PBS entrance signals ignored any Pre-signal status(actually, PBS ignores the signal state, so, you'd completly mess up the pre-signal junction if it were used.), however, what he didn't consider is that you might want to use pre-signals on the exit block, which did actually work.

Well - with good pathfinder, which YAPF looks like being, comparing to NPF, one doesn't need any special/"PBS" signals.

Normal signals can easily act like "PBS"-implementation, but I guess that would be a suggestion for the YAPF topic...

SirkoZ wrote:Well - with good pathfinder, which YAPF looks like being, comparing to NPF, one doesn't need any special/"PBS" signals.

Normal signals can easily act like "PBS"-implementation, but I guess that would be a suggestion for the YAPF topic...

...that was pretty much what I was asking about.

SirkoZ wrote:with good pathfinder, which YAPF looks like being, comparing to NPF, one doesn't need any special/"PBS" signals.

I may be mistaken, but I don't believe I've actually seen KUDr say one word about PBS in relation with YAPF. When I asked directly, several people answered, but KUDr himself did not. Not even to comment on if he was planning on implementing PBS himself. This makes me believe that right now any information on the future of PBS is nothing but a rummor. The one thing he did say about NPF is that it WAS well designed, it was just slow.

Now, if anyone has had a chat with KUDr on IRC or something, I'd love to hear about what he had to say himself.

-Hazelrah

PBS defintiyl will come, there are too many people wanting it for it to just die, its all just a matter of time.

From what i can remember (which isn't usually that much!) KUDr started work on a shiny new working PBS implementation, and then gave up, due to the problems with NPF, I seem to recall him saying he was going to code a new pathfinder, which would be a solid foundation for the new PBS.

Sacro wrote:From what i can remember (which isn't usually that much!) KUDr started work on a shiny new working PBS implementation, and then gave up, due to the problems with NPF, I seem to recall him saying he was going to code a new pathfinder, which would be a solid foundation for the new PBS.

Exactly, and this new pathfinder has been called YAPF (Yet Another Path Finder)

sacro knew that, sacro is just a bit of a frube.

I may be mistaken, but I don't believe I've actually seen KUDr say one word about PBS in relation with YAPF. When I asked directly, several people answered, but KUDr himself did not.

Hazelrah: KUDr himself is not always watching IRC (not 24/7). Also if people already answered your questions why should i repeat it again and again? I guess that everybody who is really interested about PBS must already know the story. But, OK. I will recapitulate it here from very beginning step by step how it happened:

1. i found OTTD
2. i started to play OTTD instead of TTDP
3. i have learned what PBS is
4. i used PBS heavily as i love it
5. it started to crash my trains and caused other troubles like unreversible trains and so on
6. PBS was removed from the trunk due to such problems
7. this event made many people (including me) unhappy
8. so i started to work on it to repair some bugs
9. i have learned that it contains lot of conceptual mistakes (not just bugs in the code)
10. started to rewrite it (or more think about new design)
11. learned that people want to have it NPF independent as NPF is slow
12. learned that NTP is unusable for such feature
13. after discussion with developers i decided to start with new pathfinder that will be PBS-able but faster than NPF
14. after many many hours spent on it YAPF is finally in the trunk
15. reopened discussion with Celestar and other people about PBS concept
16. agreement that PBS should be common behavior of all signals
17. agreement that we need to change the signalling concept from "driven by train movement" to "driven by train route plan" first
18. now i am playing OTTD and thinking more about this concept

So YES - PBS is still in plan and YES - YAPF is related to PBS (PBS is the reason why YAPF was made). And until YAPF is fully debugged it makes no sense to extend it by new features like PBS. It is better to prepare it for the next release as independent feature and implement further extensions later.

Current task is to change the signalling concept to reflect future needs and to avoid load balancing problems like two trains deciding for the same lane when the segment is free and then one of them enters it and another one must stop immediatelly. If train can open his path by talking to the next few signals (like "I would like to pass. Can I?") then we should have solved at least load balancing (and unrealistic train stops) and prepared ground for full PBS support in the near future. Then the biggest change from the user perspective will be, that the default signal state will be red and it will change to green only if train is comming.

KUDr wrote:12. learned that NTP is unusable for [PBS]

I'm still trying to figure this one out, because TTDPatch is still using OPF (Original ...) to support PBS, and I would assume that NTP would be better the OPF, since it was implemented after OPF.

Am I incorrect in assuming that NTP is better than OPF[0], or have I made some other faulty assumption?

[0] This makes no sense either, though.

DaleStan: I don't know how PBS is implemented in TTDP (i would like to know, but TTDP is one big magic for me). Anyway IIRC there were some limitations like max. number of crossings inside the block and that OPF was invoked multiple times to reserve path through all those crossings.

Simply: I don't want to implement new feature with such limitations. If using PBS signals would slow down the game signifantly (by invoking NTP many times) then it will be good candidate to be rewritten soon. I am not sure if it makes sense to develop such feature(s) and/or if developers would add such feature(s) into trunk. It could be good as proof of concept, but not as regular development task.

btw: if you know some background info how PBS is done in TTDP, I would appreciate some lesson (thanks in advance).


Edit: to your question if NTP is better than OPF: I guess so. As it always finds the proper path (if it exists).

But what is still missing there is the route recorder so the only information it returns is the next trackdir to be taken. Then i could imagine why PBS would need to call it multiple times to reserve one route. Changing NTP to be more flexible (whether to use or not to use PBS reservations in cost calculations, whether to record the path or not), then you probably would need to do it modular and the result will be another NPF. Believe me, i didn't want to reinvent the wheel.

KUDr wrote:DaleStan: I don't know how PBS is implemented in TTDP (i would like to know, but TTDP is one big magic for me).
...
btw: if you know some background info how PBS is done in TTDP, I would appreciate some lesson (thanks in advance).

Talk to patchman. I can tell you what happens, but (with a few exceptions) not how or why it works.

KUDr wrote:Anyway IIRC there were some limitations like max. number of crossings inside the block

No. The limit is that no path can cross more than seven junction tiles. You can have as many junction tiles as you want in one block. And that is enough for the vast majority of junctions.

KUDr wrote:and that OPF was invoked multiple times to reserve path through all those crossings.

AIUI, twice. Once as-is (with red signals red and reserved paths reserved), and once optimal (all signals green and no paths reserved.) This is offset by the fact that OPF does not get called in a PBS junction; the saved path is simply played back.

KUDr wrote:But what is still missing there is the route recorder

I would guess that patchman just tacked one on to OPF, but I don't know for sure.

OPF's algorithm is a search of all possible paths from the current location. A path ends when one of the following is reached: 1) the destination, 2) the eighth junction tile, 3) the 65th tile, or 4) a red two-way signal[0]. The best path that gets to the destination, or failing that, the path that gets closest to the destination, is the path taken.

[0] A red two-way only ends the path if it is the first signal on that path, though.

hello,

KUDr wrote:Then the biggest change from the user perspective will be, that the default signal state will be red and it will change to green only if train is comming.

I'm not a dev, I know you gives so much to this projet, KUDr, but sorry to say I find this idea a little bit weird.
even if you need to perform deep change internaly. I think it would really be a bad idea to change visual aspect of signal.
it look so strange to have red signal every where, and the train arrive near the next signal, so it become green (?!) and stay green till the train reach next signal. and the next train will stop a green ?!

step 1
----####A-----[1]---------[2]--------
train A arrive to signal [1](become green). signal [2] is red.

step 2
-------#[1]###A----[2]-----
train A is passing on signal [1] (stay green)- train on same tile as [1]
but if now another train arrives near signal [1], signal is *green* but train must stop.

it's so strange....

I think that KUDr meant that signals won't switch back to green if there isn't a train comming. LoMo does it this way too IIRC, it looks a bit weird at first but after a while it makes sense.

At least where I live, all train signals are red, except when a train approaches from the previous signal and the road is clear. Same with the subway.

DaleStan wrote:

KUDr wrote:DaleStan: I don't know how PBS is implemented in TTDP (i would like to know, but TTDP is one big magic for me).
...
btw: if you know some background info how PBS is done in TTDP, I would appreciate some lesson (thanks in advance).

Talk to patchman. I can tell you what happens, but (with a few exceptions) not how or why it works.

Conceptually, it's very simple. Call the pathfinder upon approach to the PBS signal, and record the route it finds if any. Then call it again ignoring reserved pieces and compare both routes; if the second is substantially cheaper we wait for those pieces to become available.

Then there are some decisions based on whether the PBS signal is red: if it's red, we wait if we couldn't find a route, if it's green we reserve any route through the block.

KUDr wrote:Anyway IIRC there were some limitations like max. number of crossings inside the block

No. The limit is that no path can cross more than seven junction tiles. You can have as many junction tiles as you want in one block. And that is enough for the vast majority of junctions.

And that's just a limitation of TTD's original pathfinder implementation and could be fixed if needed. So far, there hasn't been a need.

KUDr wrote:But what is still missing there is the route recorder

I would guess that patchman just tacked one on to OPF, but I don't know for sure.

Indeed, that wasn't particularly hard either, it's about 5% of the total PBS code. Much more code is needed to reserve/unreserve pieces for all possible tile types, check their reversedness and so on.