[patch] Routing Restrictions - port from TTDPatch

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: [patch] Routing Restrictions - port from TTDPatch

Post by JGR »

messismore wrote:Hi JGR and thank you for this awesome patch :bow:

I am having trouble setting them up correctly though and wondered if you could maybe give me some pointers…
I am trying to build a track that gives one travel direction priority over the other (full trains vs. empty trains). I assumed the configuration depicted below would do just that however the signals appear to behave no different from vanilla PBS signals. I tried both reserve through and long reserve. What am I doing wrong?
Cheers

Image
Thanks for raising this issue.
The signal entry direction conditional did not work when being evaluated in the context of a reserve through action. This is now fixed in the repo and will be in the next release.
In the meantime you can just remove the entry direction conditional, as it is redundant when used with reserve through anyway.

Long reserve requires that the vehicle has some orders and is trying to go somewhere. Otherwise it will not try to reserve multiple sections.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
cp1900
Engineer
Engineer
Posts: 56
Joined: 30 Sep 2007 17:59
Location: Czech Republic

Re: [patch] Routing Restrictions - port from TTDPatch

Post by cp1900 »

Hello,

Apologies if this is not the correct topic to ask this question.

I am trying to recreate a route with single-track operations.
What I have so far is a Path Signal at the exit of the stations, just before the tracks join into a single line. The same is used on the next station where trains can meet and cross-over. This works fine for only one train to travel between the stations.

However, what I would like to have is the possibility to introduce a few block sections on that very same single track. The purpose is to allow more than one train to travel on the same single track, only if they are going in the same direction.

Let's consider trains A, B and C. Trains A+B go will travel in this direction -> meanwhile train C is traveling on the opposite direction <-. Now I want to have train C to wait for A+B to pass through but I want both of them to be going and for the C train to be held at the station. How can I achieve this? Or is it even possible to do such a thing?
User avatar
Gwyd
Chief Executive
Chief Executive
Posts: 721
Joined: 17 Apr 2017 16:52
Location: Western Ile-de-France Region

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Gwyd »

cp1900 wrote:Hello,

Apologies if this is not the correct topic to ask this question.

I am trying to recreate a route with single-track operations...
I think this is the solution, using path signals (not one way). However, I feel like this will only work once along a route, otherwise deadlocks will occur.

Image
User avatar
cp1900
Engineer
Engineer
Posts: 56
Joined: 30 Sep 2007 17:59
Location: Czech Republic

Re: [patch] Routing Restrictions - port from TTDPatch

Post by cp1900 »

Gwyd wrote:
cp1900 wrote:Hello,

Apologies if this is not the correct topic to ask this question.

I am trying to recreate a route with single-track operations...
I think this is the solution, using path signals (not one way). However, I feel like this will only work once along a route, otherwise deadlocks will occur.
This is what I tested at first but unfortunately it does create deadlocks, at least when having departure signals from the stations just before entering the single track. Thanks for the suggestion, non the less. I still wonder if there's another way to achieve what I have in mind, though.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: [patch] Routing Restrictions - port from TTDPatch

Post by JGR »

cp1900 wrote:
Gwyd wrote:
cp1900 wrote:Hello,

Apologies if this is not the correct topic to ask this question.

I am trying to recreate a route with single-track operations...
I think this is the solution, using path signals (not one way). However, I feel like this will only work once along a route, otherwise deadlocks will occur.
This is what I tested at first but unfortunately it does create deadlocks, at least when having departure signals from the stations just before entering the single track. Thanks for the suggestion, non the less. I still wonder if there's another way to achieve what I have in mind, though.
This is possible using the slots feature.
See here for a brief explanation.
This is not in the patch in the first post, it is included in my patchpack and the tracerestrict-sx branch on github.

Screenshot from test game:
Nuntborough Transport, 1997-04-17#1.png
(487.07 KiB) Not downloaded yet
Ex TTDPatch Coder
Patch Pack, Github
User avatar
cp1900
Engineer
Engineer
Posts: 56
Joined: 30 Sep 2007 17:59
Location: Czech Republic

Re: [patch] Routing Restrictions - port from TTDPatch

Post by cp1900 »

JGR wrote: This is possible using the slots feature.
See here for a brief explanation.
This is not in the patch in the first post, it is included in my patchpack and the tracerestrict-sx branch on github.

Screenshot from test game:
Nuntborough Transport, 1997-04-17#1.png
Hi JGR,

Thank you for this. I will try this one out. Fortunately I am actually playing with your patchpack. :)
odalman
Engineer
Engineer
Posts: 37
Joined: 07 Jan 2020 01:46

Re: [patch] Routing Restrictions - port from TTDPatch

Post by odalman »

JGR wrote: 31 Jul 2015 14:52
adf88 wrote:I have also a suggestion about the GUI part of this patch. Instead of these mysterious numbers (penalties) there could be simple words like "small", "medium" and "high".
How big is "small", "medium" or "high", how long is a piece of string? Without knowing the context of what the user is trying to achieve it's not possible to provide a 3-sizes-fits-all set of values. It's more pragmatic to just ask the user what value they want.
I did not look at the pathfinder but i assume that it adds penalties for various things that it finds along a path. Let us assume that there is one thing called <X> for which the pathfinder adds the penalty 500 and another thing called <Y> for which the pathfinder adds the penalty 200. The user could then pick <X> from a list and get a program statement looking like this:
Add pathfinder penalty: 500 (like <X>)

Other examples:
Add pathfinder penalty: 201 (slightly more than <Y>)
Add pathfinder penalty: 199 (slightly less than <Y>)

So the user would not enter a number but select <X> or <Y> and also select like, slightly more than or slightly less than. And that is also what is stored, not the numbers. So if the pathfinder is tuned, the routing restriction programs will display and apply the new numbers. I think that it would help a lot if the pathfinder is changed so that all penalties are changed by a factor 10 for some reason.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: [patch] Routing Restrictions - port from TTDPatch

Post by JGR »

odalman wrote: 22 Jan 2020 21:14
JGR wrote: 31 Jul 2015 14:52
adf88 wrote:I have also a suggestion about the GUI part of this patch. Instead of these mysterious numbers (penalties) there could be simple words like "small", "medium" and "high".
How big is "small", "medium" or "high", how long is a piece of string? Without knowing the context of what the user is trying to achieve it's not possible to provide a 3-sizes-fits-all set of values. It's more pragmatic to just ask the user what value they want.
I did not look at the pathfinder but i assume that it adds penalties for various things that it finds along a path. Let us assume that there is one thing called <X> for which the pathfinder adds the penalty 500 and another thing called <Y> for which the pathfinder adds the penalty 200. The user could then pick <X> from a list and get a program statement looking like this:
Add pathfinder penalty: 500 (like <X>)

Other examples:
Add pathfinder penalty: 201 (slightly more than <Y>)
Add pathfinder penalty: 199 (slightly less than <Y>)

So the user would not enter a number but select <X> or <Y> and also select like, slightly more than or slightly less than. And that is also what is stored, not the numbers. So if the pathfinder is tuned, the routing restriction programs will display and apply the new numbers. I think that it would help a lot if the pathfinder is changed so that all penalties are changed by a factor 10 for some reason.
In my own use of pathfinder penalties, I've tended to use things more like N * <X>, to match a parallel path.
The pathfinder constants should not change. While there are settings for them, they are hidden. Generally, the only savegames that I've seen where they are at non-default values are bug reports where the user has set all the constants to their maximum or minimum values, such that the pathfinder no longer works effectively.
Probably the pathfinder constant settings should just be removed.
Ex TTDPatch Coder
Patch Pack, Github
tvmelissa
Engineer
Engineer
Posts: 16
Joined: 01 Feb 2006 01:47

Re: [patch] Routing Restrictions - port from TTDPatch

Post by tvmelissa »

Hey JGR,

First of all, I just wanted to thank you for all your awesome work, both on this patch and your patch pack. Now on to my issue.

I'm trying to make stopping trains wait in the station to allow closely a following express to pass, so I've got this:

Image

All 4 signals at the platform ends share the program. It's not that obvious, but if you look carefully, you can see that the incoming train has reserved through the signal, even though the condition shouldn't be met.

Thanks.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: [patch] Routing Restrictions - port from TTDPatch

Post by JGR »

tvmelissa wrote: 21 Oct 2021 23:44 Hey JGR,

First of all, I just wanted to thank you for all your awesome work, both on this patch and your patch pack. Now on to my issue.

I'm trying to make stopping trains wait in the station to allow closely a following express to pass, so I've got this:

Image

All 4 signals at the platform ends share the program. It's not that obvious, but if you look carefully, you can see that the incoming train has reserved through the signal, even though the condition shouldn't be met.

Thanks.
This is because the train's "current order" is advanced as the pathfinder moves past the target.
In this case, once the pathfinder/reservation has gone past the platform, the "current order" becomes the next item in the order list, and the "last visited station" becomes Stoney Point.
This is the same as in vanilla and is so that PBS works reasonably when you have a junction or similar on the far side of the target station or waypoint.
Using "last visited station" instead of "current order" ought to resolve this.
Ex TTDPatch Coder
Patch Pack, Github
tvmelissa
Engineer
Engineer
Posts: 16
Joined: 01 Feb 2006 01:47

Re: [patch] Routing Restrictions - port from TTDPatch

Post by tvmelissa »

JGR wrote: 22 Oct 2021 21:10 This is because the train's "current order" is advanced as the pathfinder moves past the target.
In this case, once the pathfinder/reservation has gone past the platform, the "current order" becomes the next item in the order list, and the "last visited station" becomes Stoney Point.
This is the same as in vanilla and is so that PBS works reasonably when you have a junction or similar on the far side of the target station or waypoint.
Using "last visited station" instead of "current order" ought to resolve this.
Yep, that fixed it.

Thanks.
tvmelissa
Engineer
Engineer
Posts: 16
Joined: 01 Feb 2006 01:47

Re: [patch] Routing Restrictions - port from TTDPatch

Post by tvmelissa »

tvmelissa wrote: 23 Oct 2021 19:14 Yep, that fixed it.

Thanks.
Actually, not quite...

I just spotted a stopping train with a long reservation at another station with the same signal restrictions. This one has a level crossing between the platform and the signal, though, which I suspect might be throwing it off?
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: [patch] Routing Restrictions - port from TTDPatch

Post by JGR »

tvmelissa wrote: 24 Oct 2021 00:36
tvmelissa wrote: 23 Oct 2021 19:14 Yep, that fixed it.

Thanks.
Actually, not quite...

I just spotted a stopping train with a long reservation at another station with the same signal restrictions. This one has a level crossing between the platform and the signal, though, which I suspect might be throwing it off?
Which version are you running incidentally? It may be useful if you could post a save.
Ex TTDPatch Coder
Patch Pack, Github
tvmelissa
Engineer
Engineer
Posts: 16
Joined: 01 Feb 2006 01:47

Re: [patch] Routing Restrictions - port from TTDPatch

Post by tvmelissa »

JGR wrote: 24 Oct 2021 21:23
tvmelissa wrote: 24 Oct 2021 00:36
tvmelissa wrote: 23 Oct 2021 19:14 Yep, that fixed it.

Thanks.
Actually, not quite...

I just spotted a stopping train with a long reservation at another station with the same signal restrictions. This one has a level crossing between the platform and the signal, though, which I suspect might be throwing it off?
Which version are you running incidentally? It may be useful if you could post a save.
I was originally on jgrpp-0.40.4, but I reproduced the issue on 0.43.1 before reporting it.

My actual game has a lot of GRFs and a game script, so I've reproduced the issue in a clean save.
Attachments
Long Reserve Test.sav
(98.48 KiB) Downloaded 107 times
Maeximus
Engineer
Engineer
Posts: 1
Joined: 05 Feb 2024 20:25

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Maeximus »

Hey JGR,

thank you for maintaining the code! Are you open to "feature requests"?

I played around with the routing restrictions, especially the deny condition and I want it to force trains into a reverser. In vanilla this works with setting "rail_firstred_twoway_eol" to 1 and putting a twoway signal in the usual path of the train (like in https://wiki.openttdcoop.org/images/9/9 ... rimary.png note the twoway exit signals where usually a PBS signal would be used)

Now I tried a remotely similar setup with slots and "deny" trains entering a section when they are not able to aqcuire a slot (and send them into a reverser and then into an overflow depot). But they tried to go on nevertheless and ended up blocking the way so I had to resort to the twoway signal thing again which does not integrate well into the slot setup so I wondered what the difference is between the red twoway and the routing restriction "deny" since I would like to get it working without abusing pre-signals and tracks as priorities again.

So I did a bit of digging in the pathfinder and found out that the twoway signal is using this code:

Code: Select all

if (!IsPbsSignal(sig_type) && Yapf().TreatFirstRedTwoWaySignalAsEOL() && n.flags_u.flags_s.m_choice_seen && has_signal_against && n.m_num_signals_passed == 0) {
	/* yes, the first signal is two-way red signal => DEAD END. Prune this branch... */
	Yapf().PruneIntermediateNodeBranch(&n);
	n.m_segment->m_end_segment_reason |= ESRB_DEAD_END;
	Yapf().m_stopped_on_first_two_way_signal = true;
	return -1;
}
while the "deny" path is using this:

Code: Select all

if (out.flags & TRPRF_DENY) {
	n.m_segment->m_end_segment_reason |= ESRB_DEAD_END;
	return -1;
}
I then had a look at the function PruneIntermediateNodeBranch and found this comment:

Code: Select all

	/**
	 * In some cases an intermediate node branch should be pruned.
	 * The most prominent case is when a red EOL signal is encountered, but
	 * there was a segment change (e.g. a rail type change) before that. If
	 * the branch would not be pruned, the rail type change location would
	 * remain the best intermediate node, and thus the vehicle would still
	 * go towards the red EOL signal.
	 */
So adding Yapf().PruneIntermediateNodeBranch(&n) to the "deny" path might be a good way to "enforce" the deny, otherwise it seems only to heavily discourage a path instead of really preventing it (as the train still thinks it cannot reach its destination after passing the "deny").

I could also supply screenshots of my setup if that helps illustrating the issue.
Thanks for the consideration!
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 7 guests