Some thoughts about pre-signals…

[Azra3l]

Some thoughts about pre-signals…

When checking the signal state (pre-signal), OTTD will use the pathfinder to search for all exit signals. The problem is that it will include the state of all exit signals from a block.

Starting at rail_cmd.c:

UpdateSignalsOnSegment -> FollowTrack -> TPFMode1 (tpf->enum_proc(…)) -> SetSignalsEnumProc

(…I think. I didn’t look at the code for more then 5 min. Please don’t throw flames at me because of that. I really don’t have much time now to go deep into the code right now. I want to do that but I will have to spend some time understanding everything from the map array, bits, pathfinder etc… you know that it’s not a simple job… )

Anyway, as I was saying, the pathfinder should not include the state for all exit signals but only does that really provide a valid (train) path to exit the block.

The signal [A] should be red because the path from [line 2] to [line 1] is not a valid one and, because of that signal should not be included as an exit signal away from that block.

I know that this track layout is not really one you want to use as an optimized TTD track layout. (I know all that theories about junctions and RODO stations, but I’m more into track designs that, are more close to reality, then huge junctions that are almost light years away from reality and are really ugly. This is just a personal opinion…)

I’ve read the threads about Path Signals and the way they are implemented in TTDPatch. They will really provide a better way to build layouts that are closer to reality, but I think that correcting this will provide more freedom to players using traditional pre-signals.

I know that this is the default behavior of the TTDPatch but, should it be like this?

Thanks

P.S. I would be grate if someone would comment functions explaining that they do, including parameters, etc… just a couple of lines will really improve the reading of code.[/i]

[Bot_40]

I agree, can't remember when but there have been quite a few situations where this really bugged me.

[Celestar]

I think the suggestion is a valid one. I'll see to it that it gets put somewhere on the todo list if we can still find some free space on it

Celestar

[acidd_uk]

Yeah, I've run into this problem when trying to make efficient multi-line tracks. It also happens if you have:

Code: Select all

A--\---C
B---\--D

That represents a 2-track one-way system. A and B are 1-way presignal entrances. C and D are (2-way) presignal exits.
Trains starting at A or B pass left to right to C or D. Trains starting at B cannot get to C because of the way the track is layed out and this causes the same problem as described above. A train coming from B will enter the block even if D is red, becasue C is green, even tho the train cannot get to C.

If that doesn't make sense, then the main point is I agree with Azra3l

[Bjarni]

P.S. I would be grate if someone would comment functions explaining that they do, including parameters, etc… just a couple of lines will really improve the reading of code.[/i]

yeah, that would be useful. I add comments whenever I find parameters without any or something like that, given that I figure out what they are.

As for the idea: I thought about this when presignals was added to OTTD in the first place, but I never really looked enough on the signal code to get an idea of how to do this. I really want it as I actually miss it, specially early in the games where money do matter.

It will also be useful if track maintaince is added. You could save money on keeping just one track even trough you have more than 3-4 trains using that line

[siu238X]

Yeah, I've run into this problem when trying to make efficient multi-line tracks. It also happens if you have:

Code: Select all

A--\---C
B---\--D

That represents a 2-track one-way system. A and B are 1-way presignal entrances. C and D are (2-way) presignal exits.
Trains starting at A or B pass left to right to C or D. Trains starting at B cannot get to C because of the way the track is layed out and this causes the same problem as described above. A train coming from B will enter the block even if D is red, becasue C is green, even tho the train cannot get to C.

If that doesn't make sense, then the main point is I agree with Azra3l

Actually this also led to the "crossover problem". I think by solving this problem trains might also be able "intellegently" know to move or not on crossovers like this:

Code: Select all

A->(P)-\-/-<(E)>--C
        X
B-<----/-\-<(E)>--D

(P is pre-sig entrance, E is pre-sig exit)

I always hope that a train from A will get into C,
ignoring the signal if a train is going to B via D.

Of course, there's more to consider, like crossovers
involving more than 1 entrance / exit.

[Prof. Frink]

Congratulations.

You just described TTDPatch's Path-Based Signalling.

[acidd_uk]

I don't think it's exactly the same - I read siu238X's post to mean that two trains could occupy the same block as long as they weren't going to collide.

What Azra3l describes isn't quite PBS either, it's simpler - presignal entrances just need to know to ignore exits trains physically cannot get to.

[Prof. Frink]

I don't think it's exactly the same - I read siu238X's post to mean that two trains could occupy the same block as long as they weren't going to collide.

And that's exactlywhat PBS does.

[siu238X]

I don't think it's exactly the same - I read siu238X's post to mean that two trains could occupy the same block as long as they weren't going to collide.

What Azra3l describes isn't quite PBS either, it's simpler - presignal entrances just need to know to ignore exits trains physically cannot get to.

Actually what I see is somehow an "extension" of Azra's plan, I don't mean exactly the same thing, really.

[siu238X]

I don't think it's exactly the same - I read siu238X's post to mean that two trains could occupy the same block as long as they weren't going to collide.

And that's exactlywhat PBS does.

So do you mean TTDPatch has included this but OpenTTD hasn't yet?
(I didn't try out nighty releases)

[JenovaUK]

I think so (If I understand what your talking about). TTDP PBS is actually quite good, I've seen a game with a 10 platform terminal handling three entrances and exits without any halts for more than a few seconds and it's never closed the station off totally.

It's a really good idea, I'd like to see it come to OpenTTD.

[Azra3l]

But, from what I saw yesterday in the code (maybe 2 hours looking at it) It might be simpler to implement TTDPatch Path Based Signals then the change what I’ve proposed… (I think)

Because what the pathfinder does is to find signals that are behind the signal that the train just passed, storing all the pre-signals data from signals found. (actually a count of pre-signals pointing to that block) and then looks forward and does the same thing… the pathfinder doesn’t actually finds and stores paths between signal to validate does paths.

So one thing that could be done is to make the pathfinder do that, but, without profiling..., I think that it will make things slower. Maybe another approach the way signals are implemented… if a signal could have some knowledge about its surroundings; this could lead to other approaches. Implementing Directional signals? Red to turn left green to turn right… (There are only 3 ways out of a signal).

Ok enough of that!!! I will look at the code, it’s a cool thing to do… I loved my session yesterday. Maybe I will see the light…