[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

[patch] Routing Restrictions - port from TTDPatch

Post by JGR »

This patch adds routing restrictions to OpenTTD. This is based on a feature that was originally implemented for TTDPatch.
(For an overview of the original implementation see: here)

This works by attaching programs to signals, which the pathfinder will run when determining the cost of a path through that signal for a particular train.
A program is a list of instructions which are executed in order. Instructions can be either conditionals (test something) or actions (do something).
The program can test various properties of the train, and the direction through the signal that we are going.
Programs can be shared between multiple signals, or copied from one signal to another.
Restrictions on a set of signals apply in both directions. For the case of path signals, restrictions apply in both directions even though there isn't a physical signal in one direction (this is in fact quite useful).
Tiles with two sets of signals (i.e. up to 4 physical signal heads) can have separate programs for each of the two sets.
Restricted signals are visually indicated by having a blue signal post, when using electric signals from the default set or OpenGFX GRF, or when the setting to show restricted electric signals using the default sprites is enabled.

Outputs that programs can have are:
  • Deny
    The pathfinder will treat this signal as a dead end. (There is also an option to cancel deny commands earlier in the program).
  • Add penalty
    The pathfinder will add the penalty to the "cost" of paths through the signal
  • Reserve through (as of patch 6/commit 73b69c55)
    If a PBS signal uses this command, 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. (There is also an option to cancel reserve through commands earlier in the program).
  • Long reserve (as of patch 7/commit 82cab7f3) (by KeldorKatarn)
    If a PBS signal uses this command, trains which make reservations which end at the signal will try to reserve through to the next signal where possible. If no further reservation is possible the reservation ends here as normal. (There is also an option to cancel long reserve commands earlier in the program).
Conditions that programs can test are:
  • Train length
  • Train maximum speed
  • Train current order (station, waypoint or depot)
  • Train next order (station, waypoint or depot)
  • Train last visited station
  • Can train carry a particular cargo
  • Which direction is the path entering the signal from (front, back, or the compass directions of the tile edge: north-west, north-east, south-west or south-east)
  • Entered tile of PBS signal block (as of patch 2/commit a0520b8)
Conditions can use the operators "is" and "is not", and also for the integer conditions: train length and max speed, less than, less than or equal, greater than and greater than or equal.
Conditions can be in the form of "if", "else if", "or if" or "else".
Conditions can be nested.

The idea of using linear programs with nestable conditionals and commands is based on the Programmable Signals patch.
The GUI for this patch is very strongly based on that from the Programmable Signals patch. (It's not completely plagiarised, but the base layout and much of the boilerplate is copied from there). The non-GUI code however, is completely different.

Caveats:
  • This requires the use of YAPF as the train pathfinder
  • Programs are only evaluated within the YAPF lookahead distance (this defaults to about 10 signals away), this is to avoid damaging pathfinder performance and/or require changing the pathfinder too much
  • This is not a replacement for waypoints
    This is in part a result of the previous caveat. Trying to use this patch for long distance routing may not have the desired effect and will probably be more difficult to manage than waypoints.
  • This patch does not actually stop trains passing signals where a Deny actions is in force. If no route at all can be found the pathfinder may choose to use a path that ends at the signal anyway, like it would any other dead end.
  • This is not the same as the programmable signals or logic signals patches, though this path can happily co-exist with those
Use cases:
Most of the specific use cases that I've thought about so far have involved station platform allocation without needing waypoints at the ends of platforms or awkward track layouts, though it's generally applicable to a number of scenarios. For example:
  • Handling mixed bay/though platform stations, based on next order
  • Platform allocation based on train type (e.g. cargo type, speed, etc.)
  • Finer grained prioritisation of which platform to use when more than one is unoccupied, by using pathfinder penalties, for example to reduce conflicting moves when the train later leaves the station
  • Access control, e.g. to stop slow trains going onto high-speed lines
  • Preventing long trains from stopping at places where they overhang and block junctions
  • In the more general case: to stop trains going to places where they should not, and encourage trains to go where they should
Examples:
Example 1
Example 1
4.png (397.07 KiB) Viewed 35124 times
This is a possible way to implement a combined bay and through station. The example assumes that only bay-platform traffic calls next at "Southerly Station", which is to the south-east.
The two signals in front of the bay platforms share the program in the upper window.
The signal in front of the north/west bound through platform has the program in the lower window.
The bay platform signals deny access if the train is entering from the back of the signal and the next order (the order after the call at New Bedtown) *is not* Southerly Station. This has the effect of stopping trains which need to continue north/west from using the bay platforms. The "train is entering from the back of the signal" test is to avoid restricting trains trying to leave the platforms.
The through platform signal adds a pathfinder penalty if the train is entering from the back of the signal and the next order (the order after the call at New Bedtown) *is* Southerly Station. This has the effect of adding a penalty for trains which could use the bay platforms, such that those trains will always use a bay platforms if one is available. However if all the bay platforms are full or otherwise unreachable, it can still use the through platform, and reverse out again afterwards.
Example 2
Example 2
3.png (7.62 KiB) Viewed 36203 times
This is a contrived example to show as many program features in one screen-shot as possible. It is possible to create quite complicated programs, however for almost all use cases something much simpler will be sufficient.

Notable changes from the original TTDPatch implementation:
  • Using a linear program instead of a binary operator tree
    User feedback at the time suggested that the binary operator tree was not very intuitive. It also doesn't work very well when you have more than just a binary output.
    A linear program is more flexible.
  • "Train weight" and "train horsepower" tests are not implemented
    I'm not sure how useful these actually were in real life, they didn't seem to get used much, as far as I can tell
  • "Number of tiles from signals" test is not implemented
    This was somewhat unintuitive to use and probably isn't necessary, given the overall better state of pathfinding in YAPF relative to that in TTDPatch
  • "Signal Status" test is not implemented
    People at the time found this very confusing, and it didn't seem to get used much
  • Binary XOR is not implemented
    Nobody seemed to use this, and there aren't any use cases that I'm aware of
  • "Number of Days Since Last Service" and "Train Currently Searching For Depot" tests are not implemented
    I'm not sure how useful these are in OpenTTD, given the improved handling of depots/servicing.
  • Programmable signals is not implemented
    Use the Programmable Signals patch instead
Windows Binaries:
See this post for most recent Windows build.

Source:
The source is on GitHub. This is currently based on r27386.
Alternatively an SVN-style diff is attached below, and the required GRF can be found here.
tracerestrict_r27386_7.diff
SVN-style diff
(184.33 KiB) Downloaded 505 times
Patch boilerplate:
This is not an official OpenTTD release, therefore bug reports, suggestions, questions and so on should be posted in this thread.
As currently implemented, savegames created using the patched source will not be loadable on trunk versions or other patched versions except where indicated otherwise.



I've had somewhat of a break from working on TTD, but it's been nice to get back into things a little.

Post edit changelog:
  1. Initial post: 2015-07-30
    Upload patch 1: from r27346 to commit 2c5bfc5
  2. Edit 1: 2015-08-04
    Upload patch 2: from r27346 to commit a0520b8
    This adds "Entered tile of PBS signal block" test. post
  3. Edit 2: 2015-08-04
    Upload patch 3: from r27346 to commit 76707fb
    This changes the GUI for pathfinder penalty values and adds preset values
  4. Edit 3: 2015-08-15
    Upload patch 4: from r27386 to commit 29c4f244
    Add link to post with win32 binary
  5. Edit 4: 2015-08-20
    Upload patch 5: from r27386 to commit 4681799
    Implement graphical display of restricted signals by recolouring the signal post to blue (except semaphores and custom signal GRFs).
    Add/update links to post with Windows binaries and GRF.
  6. Edit 5: 2015-09-03
    Upload patch 6: from r27386 to commit 73b69c55
    • Program GUI changes to make 'or if' conditions easier to add, remove and use.
    • Add a 'reserve through' program command.
      If a restricted PBS signal uses this command, 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.
    • Update links, documentation text and example image 1
  7. Edit 6: 2016-02-13
    Upload patch 7: from r27386 to commit 82cab7f3
    • Add 'Long Reserve' feature (by KeldorKatarn)
    • Add setting to show restricted electric signals using the default sprites.
    • Fix attempt to recolour signal sprites from GRFs (except OpenGFX).
    • Fix minor issue when deleting stations/depots/waypoints.
    • Fix newly copied or unshared programs not being activated until the next edit action.
    • Fix copying an unrestricted signal making an empty program.
    • Fix GUI issue with picker button raise/lower states: When a picker button was selected, clicking on a different picker button would cause both buttons to be raised, instead of just the previous.
    • Fix compilation on legacy compilers (pre C++11).
Last edited by JGR on 13 Feb 2016 11:05, edited 6 times in total.
Ex TTDPatch Coder
Patch Pack, Github
Eddi
Tycoon
Tycoon
Posts: 8257
Joined: 17 Jan 2007 00:14

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Eddi »

JGR wrote:This works by attaching programs to signals
the problem i always have with attaching this feature to signals is that with the path signals, there might not be a signal in the place where you need to make this decision. there's also the suggestion/patch to add this to waypoints, but that is equally bad, as waypoints need additional space
TrueSatan
Transport Coordinator
Transport Coordinator
Posts: 291
Joined: 16 Jul 2003 18:33

Re: [patch] Routing Restrictions - port from TTDPatch

Post by TrueSatan »

Nice to see this feature now for OTTD as well :)
Hope I can manage to implement it on cirdans new map features branch. That would be nice.

Since we are no longer limited to signals, maybe it would be nice to have something new
like a building along the tracks or some switching signals (like here)
because the main reason to use the patch is to lead the train one direction or another and
that you would normally do with switching the tracks to the right direction.

In a way that would be an addition to signals and waypoints.
So you can click the building or whatever and you will get the programmable "track" window at once.

Anyway I loved that patch on ttd-patch, its so nice to build complex track layouts with it then and send the
trains the proper way. For example high speed or low speed tracks without having a waypoint
in the orders of every train you make.

Thanks JGR for the patch :bow:
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'm open to the idea of enabling restrictions for other rail tiles than just signals, however I'm not really sure what those would be.

Having a building on/beside the track would pretty much be the same as using a waypoint, which would probably be fairly straightforward to implement, though does use up a whole tile.
I'm not so keen on the idea of putting restrictions on junction tiles themselves, as it would then be overly cumbersome for users to write a single program to return different results for pathfinding over the different track pieces on the same tile, and it would be difficult to find somewhere to draw a visual indicator (which would be a necessity as otherwise you'd never find the restricted tile again).

One slightly different idea that I've been pondering for a while is adding a way to (conditionally) turn off the "signal is valid reservation end-point" aspect of the front side of path signals. You could then plop the signal in the middle of the layout, add restrictions to it, and have trains make reservations *through* it, rather than up to it. This could potentially also be useful as a one-way limiter that isn't a waiting point in the forward direction.
Alternative you could add another signal type that can be used to put restrictions on but otherwise has no effect (or maybe has a one-way effect if that'd be useful), but I'd be a bit wary of using up one of the two free signal types for a fairly niche feature, particular when other patches are already using them.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
Dave
Moderator
Moderator
Posts: 17243
Joined: 26 Dec 2005 20:19
Location: North London

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Dave »

Superb work JGR.
Official TT-Dave Fan Club

Dave's Screenshot Thread! - Albion: A fictional Britain
Flickr


Why be a song when you can be a symphony? r is a...
Eddi
Tycoon
Tycoon
Posts: 8257
Joined: 17 Jan 2007 00:14

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Eddi »

JGR wrote:a way to (conditionally) turn off the "signal is valid reservation end-point" aspect of the front side of path signals.
i'd imagine that would be more fitting into programmable signals.


a version that i was imagining was that, from a signal at the beginning of the junction, you draw a set of paths through the junction. the pathfinder will continue at the end of these paths, adding the penalties attached to these paths. effectively this would override (or amend) the "follow track" function of the signal tile. and upon choosing one of these paths (should it be the first in the pathfinding decision of the train), the reservation will be fixed as this path, and then regular pathfinding will continue until the next safe waiting spot. this may be tricky to implement both in terms of GUI and internal handling.
User avatar
Redirect Left
Tycoon
Tycoon
Posts: 7238
Joined: 22 Jan 2005 19:31
Location: Wakefield, West Yorkshire

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Redirect Left »

Fantastic work JGR. One of the features i missed when I abandoned TTDP all them years ago (good god, time flies).

Cheers!
Image
Need some good tested AI? - Unofficial AI Tester, list of good stuff & thread is here.
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:i'd imagine that would be more fitting into programmable signals.
I'm not sure about that, having it conditional on the train making the reservation would IMO seem more useful than on the red/green state of other signals.
Eddi wrote: a version that i was imagining was that, from a signal at the beginning of the junction, you draw a set of paths through the junction. the pathfinder will continue at the end of these paths, adding the penalties attached to these paths. effectively this would override (or amend) the "follow track" function of the signal tile. and upon choosing one of these paths (should it be the first in the pathfinding decision of the train), the reservation will be fixed as this path, and then regular pathfinding will continue until the next safe waiting spot. this may be tricky to implement both in terms of GUI and internal handling.
Having the user draw paths sounds a bit tricky, but I would suspect that having the user pick a tile which the route must pass through would be simpler and still work. Then the pathfinder changes can be changed to discarding routes to the next signal which don't pass through the specified tile, which is not quite as invasive.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
adf88
Chief Executive
Chief Executive
Posts: 644
Joined: 14 Jan 2008 15:51
Location: PL

Re: [patch] Routing Restrictions - port from TTDPatch

Post by adf88 »

Eddi wrote:the problem i always have with attaching this feature to signals is that with the path signals, there might not be a signal in the place where you need to make this decision. there's also the suggestion/patch to add this to waypoints, but that is equally bad, as waypoints need additional space
I don't understand people complaining about "lack of space" and wanting to pack things even more densely on the map. Elements require some space, just cope with it. Instead of making elements smaller you can simply make the map bigger and/ore more sparse, the effect will be the same. Custom bridge heads, double tracks on single tile etc. don't give extra fun IMO. Size of elements, as such, doesn't matter. What matters is balance between elements. Would this extra tile for route restrictions (waypoints instead of signals) be an imbalance? I don't think so.

Waypoints have advantage over signals because they allow to separate the two functionalities (signalling and route restrictions). They have also another advantage - they can occupy multiple tiles, you would be able to put route restrictions on many tracks with a single waypoint. They are also some kind of visual indicators.


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".
:] don't worry, be happy and checkout my patches
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 »

adf88 wrote:Waypoints have advantage over signals because they allow to separate the two functionalities (signalling and route restrictions). They have also another advantage - they can occupy multiple tiles, you would be able to put route restrictions on many tracks with a single waypoint. They are also some kind of visual indicators.
I'm not sure I agree on your first point. The function of waypoints is not to restrict routes, but to be via points to put in vehicle orders. Putting restrictions on them would be as much a clash of functionality as putting them on signals IMO.
As for occupying multiple tiles, shared/copied signal programs are a convenient enough way to have a restriction across multiple tiles.
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.
Ex TTDPatch Coder
Patch Pack, Github
Alberth
OpenTTD Developer
OpenTTD Developer
Posts: 4763
Joined: 09 Sep 2007 05:03
Location: home

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Alberth »

There is an easy way to use the suggestion by adf88, and have your precision as well, namely, by adding an advanced/custom value that can be entered (much like the sea level in the world generation).
Being a retired OpenTTD developer does not mean I know what I am doing.
User avatar
adf88
Chief Executive
Chief Executive
Posts: 644
Joined: 14 Jan 2008 15:51
Location: PL

Re: [patch] Routing Restrictions - port from TTDPatch

Post by adf88 »

JGR wrote:
adf88 wrote:Waypoints have advantage over signals because they allow to separate the two functionalities (signalling and route restrictions). They have also another advantage - they can occupy multiple tiles, you would be able to put route restrictions on many tracks with a single waypoint. They are also some kind of visual indicators.
I'm not sure I agree on your first point...
What I meant exactly is that if you want to place a route restriction on some tile you are not necessary willing to place a signal there too. I was actually referring to the problem you brought up (...signal is valid reservation end-poin...) and other possible problems coming from the fact that a signal is bounded to every route restriction. These are two independent functionalities and should be separated.
JGR wrote:The function of waypoints is not to restrict routes, but to be via points to put in vehicle orders. Putting restrictions on them would be as much a clash of functionality as putting them on signals IMO.
Both signals and waypoints participate in pathfinding. However, signal are more like to make trains not fall into each other. Waypoints are to route trains through specific links, this seems a better fit with the route restriction concept.
JGR wrote:As for occupying multiple tiles, shared/copied signal programs are a convenient enough way to have a restriction across multiple tiles.
Waypoints have advantages because you reuse current functionality. Mechanism of multi-tile waypoints is well known to users, nothing new is needed. Also consider finding connected waypoints VS finding connected signals; waypoints have names and signs already, these things help.
Last edited by adf88 on 31 Jul 2015 17:39, edited 1 time in total.
:] don't worry, be happy and checkout my patches
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: [patch] Routing Restrictions - port from TTDPatch

Post by wallyweb »

Nice work JGR. :bow:

As a long time user of this feature in TTDP, I can assure the uninitiated that you will soon be unable to live without it.
One of the applications I found useful is the ability to direct trains of certain criteria to specific station platforms without having to waste a tile with waypoint clutter.

As with TrueSatan's Linux, I will be experimenting with my New Map Features Win32 compilations.

:D

Cirdan's branch is currently synced with openttd r27220. I will have to wait for his next release before patching into New Map Features. :(
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 »

Alberth wrote:There is an easy way to use the suggestion by adf88, and have your precision as well, namely, by adding an advanced/custom value that can be entered (much like the sea level in the world generation).
That could work. Then the question becomes what to use for those values.
On the other hand, so far in my use of pathfinder penalties, I've used exactly one value: 500. This is a sample size of one user, but if a single value turns out to be good enough for most use cases it might be simpler to just set that as the default value when creating a new penalty instruction instead.
JGR wrote: Notable changes from the original TTDPatch implementation:
  • "Entered tile of PBS signal block" test is not implemented
    This one actually is potentially quite useful. I've made a start on implementing it, but it's proved more fiddly than I initially expected, so I've held it back and may well add it at a later date.
This is now implemented, and it seems to work correctly though I may do some more work on it yet.
wallyweb wrote:Nice work JGR. :bow:
Cirdan's branch is currently synced with openttd r27220. I will have to wait for his next release before patching into New Map Features. :(
You ought to be able to rebase the branch onto his. As best I can tell nothing has changed between r27220 and r27346 that would cause merge conflicts.
adf88 wrote:
JGR wrote:The function of waypoints is not to restrict routes, but to be via points to put in vehicle orders. Putting restrictions on them would be as much a clash of functionality as putting them on signals IMO.
Both signals and waypoints participate in pathfinding. However, signal are more like to make trains not fall into each other. Waypoints are to route trains through specific links, this seems a better fit with the route restriction concept.
It still feels a bit odd to use waypoints which have "go via" functionality to implement "avoid this tile(s)", but I see what you mean.
On the other hand, the biggest use case is station platform control, where typically there are already signals where you want to apply restrictions and waypoints can be inconvenient.
adf88 wrote:
JGR wrote:As for occupying multiple tiles, shared/copied signal programs are a convenient enough way to have a restriction across multiple tiles.
Waypoints have advantages because you reuse current functionality. Mechanism of multi-tile waypoints is well known to users, nothing new is needed. Also consider finding connected waypoints VS finding connected signals; waypoints have names and signs already, these things help.
That is true, finding them/visual distinctiveness is an issue at the moment.
Ex TTDPatch Coder
Patch Pack, Github
Eddi
Tycoon
Tycoon
Posts: 8257
Joined: 17 Jan 2007 00:14

Re: [patch] Routing Restrictions - port from TTDPatch

Post by Eddi »

JGR wrote:
Alberth wrote:There is an easy way to use the suggestion by adf88, and have your precision as well, namely, by adding an advanced/custom value that can be entered (much like the sea level in the world generation).
That could work. Then the question becomes what to use for those values.
On the other hand, so far in my use of pathfinder penalties, I've used exactly one value: 500. This is a sample size of one user, but if a single value turns out to be good enough for most use cases it might be simpler to just set that as the default value when creating a new penalty instruction instead.
you could make a normal/small/large dropdown, and assign the values to them by (hidden) pathfinder settings.

assume that some [meaning most] people using this feature won't know what a pathfinder penalty actually is supposed to be.
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 make a normal/small/large dropdown, and assign the values to them by (hidden) pathfinder settings.

assume that some [meaning most] people using this feature won't know what a pathfinder penalty actually is supposed to be.
Adding hidden settings starts making life complicated again. A dropdown box with a custom option and a better default value would seem simpler IMO. I'll probably have a go at implementing that soonish.

Of the small subset of users who would use routing restrictions, I'm not expecting many to use the add penalty feature or know much about pathfinder penalties in general. It's there for people who do though.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: [patch] Routing Restrictions - port from TTDPatch

Post by wallyweb »

JGR wrote:
wallyweb wrote:Nice work JGR. :bow:
Cirdan's branch is currently synced with openttd r27220. I will have to wait for his next release before patching into New Map Features. :(
You ought to be able to rebase the branch onto his. As best I can tell nothing has changed between r27220 and r27346 that would cause merge conflicts.
Unfortunatly I do not have the knowledge to rebase. If I did, I would still be hesitant to rebase Cirdan's branch without knowing what has been done "under the hood".
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 »

JGR wrote:
Eddi wrote:you could make a normal/small/large dropdown, and assign the values to them by (hidden) pathfinder settings.

assume that some [meaning most] people using this feature won't know what a pathfinder penalty actually is supposed to be.
Adding hidden settings starts making life complicated again. A dropdown box with a custom option and a better default value would seem simpler IMO. I'll probably have a go at implementing that soonish.
This is now done, though the values are fixed.
wallyweb wrote:Unfortunatly I do not have the knowledge to rebase. If I did, I would still be hesitant to rebase Cirdan's branch without knowing what has been done "under the hood".
I just tried it and got enough merge conflicts that I decided to give it a miss for the time being.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: [patch] Routing Restrictions - port from TTDPatch

Post by wallyweb »

JGR wrote:I just tried it and got enough merge conflicts that I decided to give it a miss for the time being.
Thanks for giving it a go. :bow:
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 »

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.
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 12 guests