Routing restriction discussion

[steelixb]

The problem only lies in discovering the direction of the train, however only one tile needs to be checked, and if it is reserved, then a train should wait regardless. This is almost like treating a reserved tile like an exit signal I suppose. It turns 'green' once a train has left it.

[steelixb]

The way I would check is:

The top right exit signal would have a restriction based on entering from north east.

It would check the status of the track tile right after the exit signal at the end of the track.

If it is reserved, then the signal should not allow entry. If it is not, then entry should be allowed.

By the time all tiles that were reserved are unreserved, either the track will have a train so exit signals will show red, or it will be empty, so access is allowed.

Another thing... is it possible for it to check which signal caused a certain tile to be reserved? or is this not stored either? (even so, the route tracing window wouldn't be able to support this kind of criteria anyway I suppose)

And of course, I agree that it might be annoying to work out which direction the reservation is, which is why I propose:

[JGR]

From looking through code and some tests with Cht: Landinfo,
there are some points to note:
The signal status criteria will report a PBS signal which a train is currently passing through as red (this is because the signal is red internally but is displayed as green when reserved).
The signal at the end of a route reservation is untouched, (I might try and change this...).

A better tactic would be for a PBS route reservation to pass *through* the signal and reserve the track on the other side, but this would require per-direction settings, to set. (equates to 4 more bits, running out of landscape array ), also this has a high chance of really screwing things up if mis-used...

I am reluctant to add a restriction for testing the reservation state of a track tile, as it will probably end up being complicated to use and code...
I'd rather extend the signal status restrictions to support: G, R, reserved entrance, reserved exit; instead of just G and R...

I'll investigate into this more later...
I know that there is a very similar discussion in the OTTD section somewhere, I forget where...
Never mind, it's here

[steelixb]

Yeah, that would probably be much simpler to use, as I can't imagine any use for checking reserved tiles other than for my suggestion (apart from, say where tracks cross, where one line is reserved so a different route should be taken)

This was the topic that got me thinking, so for the past couple of days I'd been trying out different layouts and route restrictions, but came to the conclusion that without fully knowing which signal a train is headed towards, it would most likely be impossible.

[welshdragon]

PBS has been really helpful for me, my first network's quite messy, and pbs has helped a great deal! but, one thing, could you include a restriction like 'Train Terminating (yes/no), train continuing yes/no, as i do not understand how to use the 'stations' orders

[DaleStan]

Define "Train Terminating" and "Train Continuing", in terms that would be understandable to a computer.

[welshdragon]

PBS has been really helpful for me, my first network's quite messy, and pbs has helped a great deal! but, one thing, could you include a restriction like 'Train Terminating (yes/no), train continuing yes/no, as i do not understand how to use the 'stations' orders

Ok, i got confused, sorry!

[Ameecher]

The station restriction is, in my opinion one of the easiest restrictions to cope with.

"Station of Current order is X" will only allow a train heading for station X at the point it reaches the signal to pass and in the same way "Station of Next order is Y" will only allow a train heading for station Y as the order after the current one.

Here is how I set up a terminating station (apologies for the crude diagram).
Z ====== Y======= X
A train from Z to Y and back to Z will have a seperate platform at station Y with the signals being restricted to show the following.
"Or
Station of Next is Z
Station of Current order is Z"

That way only a train that will be heading back for Z will be allowed in that platform. Then to stop the train that is running Z-Y-Z from picking the wrong platform at Y the other platforms need to be restricted so the line to X will have something like
"Station of Next Order is X".

That should then sort the problem

[welshdragon]

I used another system, i created a longer entry path into the station, put a waypoint there, directed trains through that, then, i made it a ro - ro, every other platform in my station's an in, and all the rest are out's, so, as you can imagine, a terminating train can't come out of the same platform, cue a siding, the trains come into the IN plaform, unload, into the siding, load in the OUT platform, and depart

Here is a diagram of my station, it's not a good one, the arrows show direction of travel, the \ are junctions and corners, the s is a siding, wp a waypoint
wp>=======6=======\
<========5=========\====s=====
>========4========>
<========3========<
>========2========>
<========1========<

[JGR]

Probably the easiest method of mixed terminus, through stations is to use way-points as you suggested.
You don't actually need to use restricted signalling at all, but if you do, you can get away with less waypoints.
(the screenshots attached are examples of mixed terminus/through layouts from before I wrote restricted signalling).

You can only really get away with no waypoints, if you can separate trains by cargo, length, etc., or if all trains either going through or turning round have a specific station/waypoint as their next order, (this is usually not the case).

You're other option is to turn on allow reversing trains at stations, but I find that this causes many more problems than it solves (at least on my networks).

You could also use adjacent stations to make two separate stations, and send trains to the appropriate one...

JGR

[The Irish]

Hmm, I use the "station of current/next order" function excessivly, however as mentioned by JGR, that only works really well only if you have a controllable number of stations as possible next stations.

This is particularly the case on "longmaps", but it can get really messy on normal maps where you have connections in all different directions.

Still, the feature is great and it can really help you saving station IDs.

[WWTBAM]

.... and it can save orders and changing them everytime the waypoint needs moving.

[Pookey]

TycoonMarkJ, use a smaller font size so your posts don't take up so much room. It's not necessary to have your writing that big. So far in my use of PBS and route restriction, i have had PBS signals tell trains to do the wrong things but i have not had a route restriction signal fail yet.

[welshdragon]

pookey: posts edited i was just having a tired eyes couple of days (for some reason) so i used a larger font size, sorry

[DaleStan]

All competent browsers provide a method of increasing the text size locally. For Firefox, (and, I believe, IE), type <CTRL-+>.

[welshdragon]

in one of the themes of the forums, it has the ability to enlarge the font (it's the blueish one), the button's above the logout button

[Rob]

With the newest nightly, r1773, and the newest experimental switch active (tssignals on) there is a connection between the track build on the tunnel entrance and the underlaying track.
Signals get autoconverted because of it.

[JGR]

Would you mind posting a savegame of that Rob.
The signal you have highlighted is facing the wrong way to be autoconverted if there was signal propagation from above the tunnel to below it. the signal on the top left side would be converted.
I think it more likely that it is being autoconverted because of the signal directly below and right. If that is a through signal (either accidentally or on purpose) that is the expected behaviour, or if not there is a bug in the code that checks signal types/propagation.

I have done some tests with similar enhanced tunnel PBS setups using mine and your config, but could not reproduce any bugs...
But thanks for reporting it.

JGR

[Rob]

Sure, here it is.

But I doubt it is caused by a through signal because I just loaded that game with the tsignals switch activated for the first time and I was trying it out on the other side of the map when trains started to be unable to reverse safely.

The savegame is from just before I activated tsignals for the first time.
In the attached ttdpatch.cfg file tsignals is set to off.

[edit]hmmm, I just loaded that game again with tsignals on and CTRL-clicking the signal shows it being a through signal Any idea as to why, since I hadn't set it to that state ?[/edit]

[edit2]found at least 5 more signals being through signals too [/edit2]

[JGR]

As I suspected, the signal to the right and down was a through-signal, even before you turned on the switch.
L6 bit 2 (value 4) was set, even though it shouldn't have been.
As your game has been going for quite a while now, this probably was caused by some buggy old patch version and has been dormant for a long time now.
You can use the signal GUI to turn that off for that signal.

You also made me spot another bug.
When tsignals or isignals but not both (ie. xor) is set, the signal GUI has an ugly semi-transparent section, which is still clickable, even though it shouldn't be...

JGR

Edit:
I see that you already spotted that now...