Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Tue Sep 26, 2017 4:29 pm

All times are UTC




Post new topic  Reply to topic  [ 33 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Thu Jul 30, 2015 2:14 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1689
Location: Ipswich
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:
Attachment:
File comment: Example 1
4.png
4.png [ 397.07 KiB | Viewed 4172 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.

Attachment:
File comment: Example 2
3.png
3.png [ 7.62 KiB | Viewed 5251 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.
Attachment:
File comment: SVN-style diff
tracerestrict_r27386_7.diff [184.33 KiB]
Downloaded 37 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).

_________________
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Last edited by JGR on Sat Feb 13, 2016 11:05 am, edited 6 times in total.

Top
   
PostPosted: Thu Jul 30, 2015 2:39 am 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 6918
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

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Thu Jul 30, 2015 2:58 pm 
Offline
Transport Coordinator
Transport Coordinator

Joined: Wed Jul 16, 2003 6:33 pm
Posts: 256
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:


Top
   
PostPosted: Thu Jul 30, 2015 6:14 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1689
Location: Ipswich
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, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Top
   
PostPosted: Thu Jul 30, 2015 6:32 pm 
Offline
Moderator
Moderator
User avatar

Joined: Mon Dec 26, 2005 8:19 pm
Posts: 17037
Location: Harringay, North London
Superb work JGR.

_________________
Albion: A fictional Britain

Official TT-Dave Fan Club
Dave's Screenshot Thread! - Flickr


Why be a song when you can be a symphony? r is a...


Top
   
PostPosted: Thu Jul 30, 2015 7:12 pm 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 6918
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.

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Thu Jul 30, 2015 7:51 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Jan 22, 2005 7:31 pm
Posts: 6019
Location: Wakefield, West Yorkshire
Fantastic work JGR. One of the features i missed when I abandoned TTDP all them years ago (good god, time flies).

Cheers!

_________________
Image
Worst Behaved IRC Member of 2008, 2009 & 2010 - Go Me!


Top
   
PostPosted: Thu Jul 30, 2015 10:13 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1689
Location: Ipswich
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, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Top
   
PostPosted: Fri Jul 31, 2015 9:06 am 
Offline
Chief Executive
Chief Executive
User avatar

Joined: Mon Jan 14, 2008 3:51 pm
Posts: 644
Location: PL
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


Top
   
PostPosted: Fri Jul 31, 2015 2:52 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1689
Location: Ipswich
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, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Top
   
PostPosted: Fri Jul 31, 2015 3:47 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Sun Sep 09, 2007 5:03 am
Posts: 4470
Location: home
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 OpenTTD developer does not mean I know what I am doing.
Also, other OpenTTD developers may have different opinions.


Top
   
PostPosted: Fri Jul 31, 2015 5:21 pm 
Offline
Chief Executive
Chief Executive
User avatar

Joined: Mon Jan 14, 2008 3:51 pm
Posts: 644
Location: PL
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.

_________________
:] don't worry, be happy and checkout my patches


Last edited by adf88 on Fri Jul 31, 2015 5:39 pm, edited 1 time in total.

Top
   
PostPosted: Fri Jul 31, 2015 5:37 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Nov 27, 2004 3:05 pm
Posts: 4984
Location: Canada
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. :(

_________________
wallyweb on tt-forums: Screenshots - Projects - Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016


Top
   
PostPosted: Mon Aug 03, 2015 7:59 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1689
Location: Ipswich
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, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Top
   
PostPosted: Mon Aug 03, 2015 8:24 pm 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 6918
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.

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Mon Aug 03, 2015 8:41 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1689
Location: Ipswich
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, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Top
   
PostPosted: Tue Aug 04, 2015 1:13 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Nov 27, 2004 3:05 pm
Posts: 4984
Location: Canada
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".

_________________
wallyweb on tt-forums: Screenshots - Projects - Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016


Top
   
PostPosted: Tue Aug 04, 2015 6:23 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1689
Location: Ipswich
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, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Top
   
PostPosted: Wed Aug 05, 2015 6:46 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Nov 27, 2004 3:05 pm
Posts: 4984
Location: Canada
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:

_________________
wallyweb on tt-forums: Screenshots - Projects - Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016


Top
   
PostPosted: Sat Aug 08, 2015 7:09 pm 
Offline
Traffic Manager
Traffic Manager
User avatar

Joined: Tue May 15, 2007 11:35 am
Posts: 252
Location: Germany
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.

_________________
My screenshots


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 33 posts ]  Go to page 1 2 Next

All times are UTC


Who is online

Users browsing this forum: Google Adsense [Bot] and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000-2017 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2017.
Hosted by Zernebok Hosting.