[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 »

Valle wrote:May I suggest a restriction based on a train's power to weight ratio or tractive effort to weight ratio? As far as I can tell, there are only independent restrictions for power and weight so far.
Individual restrictions on power and weight were in the original TTDPatch implementation, but I've not implemented them in the OpenTTD version because they weren't that useful on their own.

I'm open to the idea of power/weight or tractive effort/weight conditions, but I'm not really sure about some aspects of how the UI would work, units in particular.
It may be useful to add those ratios to the train info window as well to provide some reference.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
ISA
Tycoon
Tycoon
Posts: 3384
Joined: 17 Oct 2005 20:56
Location: Estonia

Re: [patch] Routing Restrictions - port from TTDPatch

Post by ISA »

JGR... Thank You bringing it into OpenTTD! But first I must to figure out exactly how to add patches to the game... sort of ended up nowhere all the time (lately haven't tried tough)
User avatar
Valle
Transport Coordinator
Transport Coordinator
Posts: 284
Joined: 15 May 2007 11:35
Location: Germany

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Valle »

Nice! Is it possible to expand this patch to disallowing/allowing trains to turn around for specific orders? As of now, it's only possible to toggle this for all trains in non-terminus stations through the extended settings. Setting whatever is picked there as default and allowing the player to adjust it for individual orders could improve the gameplay of complicated networks with a limited number of high-throughput station designs a lot, I think.
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 »

ISA wrote:JGR... Thank You bringing it into OpenTTD! But first I must to figure out exactly how to add patches to the game... sort of ended up nowhere all the time (lately haven't tried tough)
At some point I'll have to set up a cross compiler environment or a VM to make Windows builds.
Having users try to get a useful Windows dev environment going is not a good solution.
Valle wrote:Nice! Is it possible to expand this patch to disallowing/allowing trains to turn around for specific orders? As of now, it's only possible to toggle this for all trains in non-terminus stations through the extended settings. Setting whatever is picked there as default and allowing the player to adjust it for individual orders could improve the gameplay of complicated networks with a limited number of high-throughput station designs a lot, I think.
I think that's a bit too out of scope for this patch really.
That may be something that could be implemented as a sperate patch though.


On an unrelated note, has anyone got any thoughts on possible sprites for restricted signals?
I've been pondering this for a bit, but am a bit limited in that I can't draw; so creating loads of sprites is somewhat problematical.
Ex TTDPatch Coder
Patch Pack, Github
Eddi
Tycoon
Tycoon
Posts: 8254
Joined: 17 Jan 2007 00:14

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Eddi »

JGR wrote:At some point I'll have to set up a cross compiler environment or a VM to make Windows builds.
Having users try to get a useful Windows dev environment going is not a good solution.
you could ask the openttd team to compile binaries for you. all that is needed is a publicly accessible repository (for example at openttdcoop)
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 »

Eddi wrote:you could ask the openttd team to compile binaries for you. all that is needed is a publicly accessible repository (for example at openttdcoop)
No need, in the end. I got it built by cross-compilation with less difficulty than I was expecting.
(Helpfully OpenTTD has human-readable configure scripts, and the dependencies were mostly well-behaved).
Everything is on github already, I'd rather not manage another repo unnecessarily.
Attachments
openttd-custom-g29c4f244-tracerestrict-MINGW.zip
Win32 build
(7.46 MiB) Downloaded 227 times
openttd-custom-g29c4f244-tracerestrict-MINGW-win64.zip
Win64 build
(7.8 MiB) Downloaded 226 times
Last edited by JGR on 16 Aug 2015 11:53, edited 3 times in total.
Ex TTDPatch Coder
Patch Pack, Github
Eddi
Tycoon
Tycoon
Posts: 8254
Joined: 17 Jan 2007 00:14

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Eddi »

... a github repo should be fine.
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 »

I've updated the patch to add a graphical indication of which signals are restricted.
The signal posts of restricted signals are coloured blue (except for semaphores and custom signals GRFs). This requires the GRF which is attached to this post.
Windows binaries are also attached. The source is on GitHub and in the first post.
Attachments
openttd-custom-g46817994-tracerestrict-MINGW-win32.zip
Win32 build
(7.46 MiB) Downloaded 223 times
openttd-custom-g46817994-tracerestrict-MINGW-win64.zip
Win64 build
(7.8 MiB) Downloaded 217 times
tracerestrict.grf
GRF
(526 Bytes) Downloaded 244 times
Ex TTDPatch Coder
Patch Pack, Github
Eddi
Tycoon
Tycoon
Posts: 8254
Joined: 17 Jan 2007 00:14

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Eddi »

i had this thought recently that in order to escalate the number of visually distinguishable signal types, without equally exploding the number of sprites needed, there could be a mast sign in company colour blue/green pattern, and the player can select recolourings for this pattern to indicate different types of restrictions.
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 »

I've updated the patch again, additions include:
  • Program GUI changes to make 'or if' conditions easier to add, remove and use.
  • Add a 'reserve through' program action.
    If a restricted PBS signal sets this action, PBS reservations which would otherwise stop at this signal instead continue through it to the next signal/waiting point. In effect this allows the 'safe waiting point' property of a PBS signal to be conditionally turned off.
  • Improvements to the correctness and thoroughness of the program validator.
Attachments
openttd-custom-g73b69c55-tracerestrict-MINGW-win64.zip
Win64 build
(7.8 MiB) Downloaded 240 times
openttd-custom-g73b69c55-tracerestrict-MINGW-win32.zip
Win32 build
(7.47 MiB) Downloaded 223 times
Ex TTDPatch Coder
Patch Pack, Github
OokamiChan
Engineer
Engineer
Posts: 7
Joined: 23 Nov 2015 18:15

Re: [patch] Routing Restrictions - port from TTDPatch

Post by OokamiChan »

Hi!

I have downloded both the code and the patch and tried to compile both. I did patch latest build of OpenTTD, and the code was yours from github.
But both times I get the same error message. After some looking around I think I have found at what part it is complaining about and its in rail_cmd.cpp file.

Code: Select all

4>------ Build started: Project: openttd, Configuration: Release x64 ------
4>rail_cmd.obj : error LNK2001: unresolved external symbol "unsigned int _opengfx_grf_file_index" (?_opengfx_grf_file_index@@3IA)
4>rail_cmd.obj : error LNK2001: unresolved external symbol "unsigned int _first_user_grf_file_index" (?_first_user_grf_file_index@@3IA)

static void DrawSingleSignal(TileIndex tile, const RailtypeInfo *rti, Track track, SignalState condition, SignalOffsets image, uint pos)
{
	<Code cut for clear reding>

	} else {
		/* Normal electric signals are stored in a different sprite block than all other signals. */
		sprite = (type == SIGTYPE_NORMAL && variant == SIG_ELECTRIC) ? SPR_ORIGINAL_SIGNALS_BASE : SPR_SIGNALS_BASE - 16;
		sprite += type * 16 + variant * 64 + image * 2 + condition + (type > SIGTYPE_LAST_NOPBS ? 64 : 0);
	}

	uint origin_slot = GetOriginFileSlot(sprite);
	extern uint _first_user_grf_file_index;		<<----  LINK 2001 error
	extern uint _opengfx_grf_file_index;		<<----  LINK 2001 error
	if (!is_custom_sprite) is_custom_sprite = origin_slot != _opengfx_grf_file_index && (origin_slot >= _first_user_grf_file_index);

	<Code cut for clear reding>
}
When I read the information on MSDN page that one is directed to. I can't find any clear information on what the problem can be.
Im running windows 10 and VS 2015, is this a wrongly set or missing compiler setting? Or is it some thing differerent?

A point in the right direction is gratly appreciated.

Regardes
OokamiChan
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 »

OokamiChan wrote:Hi!

I have downloded both the code and the patch and tried to compile both. I did patch latest build of OpenTTD, and the code was yours from github.
But both times I get the same error message. After some looking around I think I have found at what part it is complaining about and its in rail_cmd.cpp file.
Edit: looks like a type mismatch, I will update this soonish.
In the meantime replace 'extern uint' with 'extern int'.
Ex TTDPatch Coder
Patch Pack, Github
OokamiChan
Engineer
Engineer
Posts: 7
Joined: 23 Nov 2015 18:15

Re: [patch] Routing Restrictions - port from TTDPatch

Post by OokamiChan »

Thank you!

Its's now working. :mrgreen:

Regardes
OokamiChan
User avatar
leeus
Engineer
Engineer
Posts: 8
Joined: 21 Feb 2006 22:17
Location: Campana
Contact:

Re: [patch] Routing Restrictions - port from TTDPatch

Post by leeus »

Hi there, :bow:

First, I have to say that I'm loving this patch... has really brought new life to OpenTTD for me... I've been playing a relatively large map[1] for the last month and a half that I'd have abandoned[2] long before that if it weren't for the features in this code patch :mrgreen:

As I said, one month and a half playing a big map (for me) and I didn't have a single crash/issue ever (not playing MP, though).

I was never been able to create a complex transport network without it becoming something ugly (due unrealistic constructions mostly) or really tedious to manage (for me at least)... but thanks to some of the awesome features in this patch, I found that it's really easier to grow in scale and manage your network to the point where it works with minimum tedium.

Two things I wanted to ask/comment:

1. Where I should relay some issues I noticed due to some different patches not playing well together (specifically, about hierarchical groups and template train replacements.)
2. I'd want to know how to use the "slots" feature in the routing restriction signals... at least, I'd want to know what is its intended use, so I can check if it will help me in enhancing my network or I can ignore it... ((I will probably end up checking the patch code in the end, if nobody knows/has time to explain, but I was hoping to get some answers first before getting to that... even a summary would do :) ))
3. Is there any guidelines/information on how to better use the new signals (both types) in good ways? (without overdoing it... I'd prefer some simple basic constructions and expand from that...) I'm mostly interested in traffic control/balancing and freight/passengers separations... has anyone here come up with interesting solutions yet that are somewhat easy to manage/implement? [3] I haven't found too much information on using those yet, nor here in this forums nor wiki, nor anywhere else :(


Thanks for your work integrating all these awesome patches and to the authors of those, of course! :bow:

Best regards!
------------
Notes below (feel free to ignore, mostly off topic... just wanted to explain my points in case someone was curious):
[+] Spoiler
  • [1] Just for the record, in case it matters, or serves to give a base for comparison: my current save scale is ~600 trains/~1700 road vehicles/~200 ships and ~100 aircraft ((which is way bigger than anything I was able to build and maintain before!)) in a 1024x1024 map, covering about ~60% of the serviceable towns for passengers and somewhat less than ~50% of cargo industries... using FIRS industry set temperate basic (I wish I had known about the Extreme setting with I started!). And also, using cargodist enabled for all cargoes, including freight.
  • [2] Mostly due to the way some patches change the way the game feels (for me):
    • I was only able to cover a small area of a map before the date was already 2000 (daylength patch) and I always ended abandoning the games once the date reached the end-of-line for end-game vehicle availability with only a small portion of a map covered.
    • I tend to like having somewhat realistic network layouts/setups, and having hundreds of trains and road vehicles was always to bothersome to maintain, hierarchical groups greatly reduces giving orders to a full set of vehicles and having them as granularly organized as needed, and template replacement is simply awesome!
    • The signals on bridges/tunnels also changed the way I can layout routes.
    • Routing restriction signals rock :)
    • Multiple cargo load/unload orders also rock :)
    • And the timetable automation also rock... and it works, I have never ever bothered with timetables before myself :)
  • [3] Specifically talking about routing restrictions signals and or programmable signals... not interested in the old way in which those issues used to be solved by combo signals and that sort of stuff!
(((Sorry if this is just mostly off topic, I just wanted to give my reasons... and there are others too, but don't want to extend too long!)))
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Wahazar »

What is difference between "reserve through" and "long reserve"?
If I understand properly, long reserve is trying to reserve current and next section, if it is not possible, only current section.
Is "reserve through" used for "reserve both sections or deny"?
Formerly known as: McZapkie
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
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 »

leeus wrote: First, I have to say that I'm loving this patch... has really brought new life to OpenTTD for me... I've been playing a relatively large map[1] for the last month and a half that I'd have abandoned[2] long before that if it weren't for the features in this code patch :mrgreen:
Many thanks :)
leeus wrote:1. Where I should relay some issues I noticed due to some different patches not playing well together (specifically, about hierarchical groups and template train replacements.)
Probably the patchpack thread.
The template train replacement patch ignores group nesting at the moment.
leeus wrote:2. I'd want to know how to use the "slots" feature in the routing restriction signals... at least, I'd want to know what is its intended use, so I can check if it will help me in enhancing my network or I can ignore it... ((I will probably end up checking the patch code in the end, if nobody knows/has time to explain, but I was hoping to get some answers first before getting to that... even a summary would do :) ))
It's a general purpose mechanism to assign and remove trains to "slots", which are analogous to dynamic groups.
A train can be in any number of slots at once.
Trains acquire/join and release/leave slots at signals, or by manually moving trains in the slot management panel.
Slots have a capacity (number of trains), when a slot is full and a train is trying to acquire it at a PBS signal using an "acquire or wait" it will wait until another train releases it. If a train used a "try to acquire" it will continue without waiting or acquiring the slot.
"Release (front)" releases a slot when the front of the train passes the signal, and "release (back)" does the same when the back of the train passes the signal. It's important to remember to use these, as otherwise you could jam your layout if a train which is holding a slot which is blocking other trains manages to leave the area without releasing it.
You can use the "train in slot", "slot occupancy" and "slot occupancy remaining" conditionals for more complex setups. These are particularly useful with the "wait at PBS signal" restriction.

You can use it for things like: bidirectional layouts with more than one train heading in the same direction, queueing sidings and programmable train regulation, preventing deadlocks when using junctions/movements with special requirements (e.g. reversals or complex layout), simpler signalling of single-train branch lines, etc.
I primarily use it for queuing sidings (i.e. diverting trains into holding areas if their destination slightly further ahead is full, so that they don't cause an obstruction by waiting across a junction or on the mainline).
leeus wrote:3. Is there any guidelines/information on how to better use the new signals (both types) in good ways? (without overdoing it... I'd prefer some simple basic constructions and expand from that...) I'm mostly interested in traffic control/balancing and freight/passengers separations... has anyone here come up with interesting solutions yet that are somewhat easy to manage/implement? [3] I haven't found too much information on using those yet, nor here in this forums nor wiki, nor anywhere else :(
I'm not aware of any tutorials at the moment, I may look into drafting some at some point.
Programmable signals are somewhat less useful than they originally seemed before I integrated them into the packpack. I tend to stick to only using routing restrictions.
McZapkie wrote:What is difference between "reserve through" and "long reserve"?
If I understand properly, long reserve is trying to reserve current and next section, if it is not possible, only current section.
Is "reserve through" used for "reserve both sections or deny"?
Yes pretty much.
"Reserve through" means that the reservation can't terminate at the current signal, it must continue until it finds somewhere else suitable to terminate. It is as if the signal was not there at all.
"Long reserve" tries to also reserve the next section, but if that's not possible the reservation up to the signal is still kept.
Both reserve through and long reserve can extend over multiple blocks (more than two).
Ex TTDPatch Coder
Patch Pack, Github
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Wahazar »

This "long reserve" feature is very useful, because it allow to make priority junctions without much effort in comparison to all these entry/combo/exit signals.
Moreover, it is probably the best way to make priority junction in case of bidirectional branch connected to dual track line (block signals are not useful, they lock both tracks).
The only issue is, that user need to insert this block each time.
Separate signal with such intrinsic "ready to use" long reserve function would be welcome (my dream is to have it in vanilla openttd together with newgrf support).
Formerly known as: McZapkie
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
michael blunck
Tycoon
Tycoon
Posts: 5948
Joined: 27 Apr 2005 07:09
Contact:

Re: [patch] Routing Restrictions - port from TTDPatch

Post by michael blunck »

leeus wrote: 3. Is there any guidelines/information on how to better use the new signals (both types) in good ways? (without overdoing it... I'd prefer some simple basic constructions and expand from that...) I'm mostly interested in traffic control/balancing and freight/passengers separations... has anyone here come up with interesting solutions yet that are somewhat easy to manage/implement? [3] I haven't found too much information on using those yet, nor here in this forums nor wiki, nor anywhere else
There´s some info for JGR´s "restricted" and "programmable" signals from TTDPatch times:
http://uwe.s2000.at/ttdx/signal/restric ... hp?lang=en

And an example for using programmable signals with use of certain tracks in stations:
http://www.ttdpatch.de/grfspecs/PatchMa ... Alpha.html

HTH
Michael
Image
User avatar
leeus
Engineer
Engineer
Posts: 8
Joined: 21 Feb 2006 22:17
Location: Campana
Contact:

Re: [patch] Routing Restrictions - port from TTDPatch

Post by leeus »

Heya!
michael blunck wrote:<snip>
There´s some info for JGR´s "restricted" and "programmable" signals from TTDPatch times:
http://uwe.s2000.at/ttdx/signal/restric ... hp?lang=en

And an example for using programmable signals with use of certain tracks in stations:
http://www.ttdpatch.de/grfspecs/PatchMa ... Alpha.html

HTH
Michael
Thank you very much Michael! I didn't found that last URL before... so thanks for it, new stuff to read! The first one I had already found posted here in the forums before, but for some reason at that time that URL was dead to me.... I tried it again and now it worked! So I'll keep it open on one browser tab until I have some time to read it :) Thank you again!
JGR wrote:
leeus wrote:1. Where I should relay some issues I noticed due to some different patches not playing well together (specifically, about hierarchical groups and template train replacements.)
Probably the patchpack thread.
Yeah, I'm sorry! I wrote that original post late late at night before going to bed, and I posted it in the wrong thread lol. I totally intended to post it in the Patch Pack thread, but I had open multiple tabs with multiple repeats of both threads and I just simply made a mistake, and when I realized it was already too late :)
But in the end it seems to have been OK, since I got too much good information relating the signals that would have been a bit off-topic in the patch pack thread, I think :)
JGR wrote: The template train replacement patch ignores group nesting at the moment.
Yeah, I noticed that... but no problem for me, it didn't bothered me too much... it only adds some extra scrolling :mrgreen:

What I found is a very minor usability issue with the way the template replacement window areas are sized (I assume)... and I guess it's either related to the hierarchical groups or to the number of total groups... i.e. it could just be the fact that I have too many groups myself (the hierarchical nodes add a lot to have a larger group list than normal)

The issue is it gets confused when the list of groups is too long and you can't reach the end of the list for both the groups panel and the template selection panel. I'll try to capture some images from my game and post them on the correct thread during today or tomorrow!
JGR wrote:
leeus wrote:2. I'd want to know how to use the "slots" feature in the routing restriction signals... at least, I'd want to know what is its intended use, so I can check if it will help me in enhancing my network or I can ignore it... ((I will probably end up checking the patch code in the end, if nobody knows/has time to explain, but I was hoping to get some answers first before getting to that... even a summary would do :) ))
It's a general purpose mechanism to assign and remove trains to "slots", which are analogous to dynamic groups.
A train can be in any number of slots at once.
Trains acquire/join and release/leave slots at signals, or by manually moving trains in the slot management panel.
Slots have a capacity (number of trains), when a slot is full and a train is trying to acquire it at a PBS signal using an "acquire or wait" it will wait until another train releases it. If a train used a "try to acquire" it will continue without waiting or acquiring the slot.
"Release (front)" releases a slot when the front of the train passes the signal, and "release (back)" does the same when the back of the train passes the signal. It's important to remember to use these, as otherwise you could jam your layout if a train which is holding a slot which is blocking other trains manages to leave the area without releasing it.
You can use the "train in slot", "slot occupancy" and "slot occupancy remaining" conditionals for more complex setups. These are particularly useful with the "wait at PBS signal" restriction.

You can use it for things like: bidirectional layouts with more than one train heading in the same direction, queueing sidings and programmable train regulation, preventing deadlocks when using junctions/movements with special requirements (e.g. reversals or complex layout), simpler signalling of single-train branch lines, etc.
I primarily use it for queuing sidings (i.e. diverting trains into holding areas if their destination slightly further ahead is full, so that they don't cause an obstruction by waiting across a junction or on the mainline).
Awesome!! Thank you for the very clear explanation! I kinda thought it was something like that from the way it was worded and the types of operations you had available (they sounded a bit to me like the Semaphores primitive in concurrent programming! Full circle, trains are threads and now signals are "semaphores" lol :P) and I managed to find the slots management window and played around a bit with it, but I didn't want to commit to using it without actually knowing what I was doing... since, I have many trains around, and a mistake can cause me to lose some (big) time afterwards cleaning the mess if they get confused and start to jam :) I already did that with the routing restrictions twice, and I preferred to load an earlier save rather than unlock the knot lol
JGR wrote:
leeus wrote:3. Is there any guidelines/information on how to better use the new signals (both types) in good ways? (without overdoing it... I'd prefer some simple basic constructions and expand from that...) I'm mostly interested in traffic control/balancing and freight/passengers separations... has anyone here come up with interesting solutions yet that are somewhat easy to manage/implement? [3] I haven't found too much information on using those yet, nor here in this forums nor wiki, nor anywhere else :(
I'm not aware of any tutorials at the moment, I may look into drafting some at some point.
Programmable signals are somewhat less useful than they originally seemed before I integrated them into the packpack. I tend to stick to only using routing restrictions.
As a first approximation (and without putting too much thought into it,) when I updated my mainlines to six lanes, and decided to test putting some penalties on the inner lanes for cargo trains and in the middle lane for slow trains (something like <201Km/h that was the best cutpoint for me according to the trains I'm running atm.) and it seems to work OK. I also started sprinkling long reserve signals for passengers trains in areas where they are approaching a junction, so they have the right to pass... and that works OK too.

I've mostly only used Long Reserve, Reserve Through, Deny, Add Penalty and the conditions for checking train speed, cargo and entering from the back of a signal.

That last item is awesome for reserving a station platform for some type of train (like a goods trains getting into a city station.. I mostly want that train to use a single platform, just for the looks... i.e. the platform has a different station style than the rest and it wouldn't make sense to have passengers trains in it.) I also made a single use of the current order condition to apply a Deny to avoid trains using a stretch to track reserved for waypoint reversing.

But nevertheless, this is the first time of me playing with them, and I can see much usefulness to be had in the future from the extra operations! :mrgreen:

I still haven't found (but I really didn't spend too much time thinking) a good way to prevent cargo trains from blocking a junction entrance when they gain access to it earlier than the fast train (without using an accessory pre-signal stretch at the side entrance, like in the past... I tried using programmable signals for that, but I really couldn't find a way to do it properly but that's on me... I'll read a bit on the info provided and maybe I can come up with something) but as I said, I didn't spend too much time into it, the long reserve feature solves the 90% percent of the cases and for the rest, there's no real harm in having fast trains waiting a bit at the ML entrance from time to time :)

Now, from the sound of it... it sounds that the slot function *could* be used to solve this... I have to think about it and maybe make a test game and try it to see how you'd go about solving that... it's much easier than testing it on a real game with temperamental trains all around :P

On the topic of different restrictions... What I would wish I had (operative word wish, not asking or requesting... just throwing an idea :))) is some panel window that listed all the different type of restrictions already in use. I.e. the distinct programs you already made and that are shared by different signals around your network (and I wish you could name them too... but that's another matter :)))

What I thought about doing, is making some rail yard somewhere off and putting there one of each signal restriction I used in one signal there with a sign above it telling this one is this, that one is that. etc.

But it would be awesome to have that already available from the in-game information at some point :)
You could also make that window responsible for highlighting the signals on the track (using the already existing Zoning mechanism, for example... which btw., is awesome!) so you can have a more fine-grained look at where'd you put each type of restriction and/or where are they shared... and it's important to know which signals share a restriction when you thought about making a change to it, to see if all the signals you applied it before are "compatible" with the new restriction or you'd want to un-share them first (specially important when you want to make a restriction more 'restrictive' in any way... you have to check if there are enough alternative paths already existing everywhere.)

Also, I wish the signal panel would stay open after you used it to apply a restriction... I kinda suspect that's on the way the base game works though, and not on the way your patch is implemented, but it would certainly reduce the clicking/repeating required to apply restriction to signals over long stretch of tracks. Also, a way to reuse the last restriction applied (or, maybe, a way to share *from* an open signal restriction panel, instead of having to open the target signal panel and chose share on it) would certainly reduce the clicking a lot! But I'd totally understand if it's not feasible to do atm., or if it requires much more work than it's worth ((unless, of course, there's a way to do that that I missed... that could totally be the case too!))
JGR wrote:
McZapkie wrote:What is difference between "reserve through" and "long reserve"?
If I understand properly, long reserve is trying to reserve current and next section, if it is not possible, only current section.
Is "reserve through" used for "reserve both sections or deny"?
Yes pretty much.
"Reserve through" means that the reservation can't terminate at the current signal, it must continue until it finds somewhere else suitable to terminate. It is as if the signal was not there at all.
"Long reserve" tries to also reserve the next section, but if that's not possible the reservation up to the signal is still kept.
Both reserve through and long reserve can extend over multiple blocks (more than two).
I found Reserve through very useful in junctions to be put in signals you normally have to either leave out or live with a bit of mess that sometime happens, but you would want to put there to avoid trains from selecting the wrong track (i.e. a one directional stretch reserved for entering or leaving) but you don't want to have trains wait on it blocking the rest of the junction connections if they can't get past that particular signal... so I normally left that signal out and lived with the mess sometimes happens, now I can have both :)


Thank you all for your awesome responses :)

Best wishes to all!

PS: Sorry for the humongous post... it started small, but it kept growing! Too much stuff to mention/praise and comment :)

EDIT: misused word
messismore
Engineer
Engineer
Posts: 2
Joined: 04 Mar 2015 13:51

Re: [patch] Routing Restrictions - port from TTDPatch

Post by messismore »

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
Attachments
Bildschirmfoto 2018-03-02 um 16.12.44.png
(529.8 KiB) Not downloaded yet
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 5 guests