Occasionally, when encountering a station with platform chose signal, the vehicle is likely to take some very odd and very daft paths.
(http://i1207.photobucket.com/albums/bb463/Junnapon/simscr231_zpsbaddfd5b.png)
I do not think this is strictly a bug, but it is something that ought to be revised, at least for experimental, as it causes some delays when the vehicle takes such a stupid path and slows to a halt as it navigates these mind-boggling zigzags. The path choosing for the PC-signals is less than optimal. This is odd because it generally works well without these signals.
Ahh, I have been looking into this recently. Things are better in 11.16 than in previous versions, but, as you have noted, still not quite right. The reason that this is different with choose signals is that the routing with choose signals is different: for the section following a choose signal, convoys are routed using Dijkstra's Algorithm, whereas, otherwise, they are routed using A*. The reason for the difference is that, with a choose signal, there is no single tile that is the destination, as any free tile belonging to the correct stop will suffice, so there is no workable heuristic.
This means that it is more important for the cost function to be accurate (that is, the function that returns the value that counts as the cost of traversing a certain tile). Diagonal tiles have a lower cost than straight tiles because they are shorter (in previous versions, an error caused this to be rounded down to zero, causing all sorts of perverse results: this was fixed in 11.16). Unfortunately, what counts as a diagonal is opaque when, as in the mouth of a station here, there are lots of tiles with both straight and diagonal ways. More significantly, there is no penalty in this cost function for turning a corner as distinct to going straight, which does, of course, give rise to a penalty of speed. This is difficult to implement because it requires knowing from what tile that the convoy has just come and in what direction that it is heading, which data, if I recall correctly, are not passed to the function for calculating the cost, so this would probably need some substantial changes in the code to improve further.
This data shoudl be available to the routing, and is calculated in the find_route. But the above situation can still occur, if a slow convoi leaves the station and that path is the first to become available. That can happen easily with double switch routes.
Ahh, yes, did these problems occur when another convoy had occupied the exit path just as the route was being selected?
Quote from: jamespetts on January 22, 2014, 10:47:50 PM
Ahh, yes, did these problems occur when another convoy had occupied the exit path just as the route was being selected?
Typically, this is the case. However, occasionally - when there are a lot of crossing points within a small area, the trains might try to pass a reservation in a way that makes them take even more convoluted paths. There ought perhaps to be some check to avoid too much of that?
Just throwing in a proposal:
Would it not be quite cool if the player got the choice to 'draw' the routes from the choose signal to the platforms?
When the player first put down the choose signal, he is given the choice to draw the paths from the sign towards the different platforms that trains should use. If nothing is drawn or if some platforms has not been getting a specific route, the normal procedure takes place to those platforms.
This would be helpfull in mostly big stations, where trains tend to get in the way of each other but also like in Junnas example where the computer maybe dont know which route actually is the best.
These are interesting ideas, but modifying routing code (in a way that does not make the game unplayably slow, at least) is extremely difficult, and, at the moment, I cannot see a practical way of achieving either of these things. It might be that a better programmer than I comes up with an ingenious plan, but, until then, this is probably a limitation of the system that is not practicably avoidable.
Do I recall that typically the trains choose the nearest platform? I.e. if you want to control the preferred platform choice you make the path to platform B longer than to platform A ?
I seem to recall messing around once with a 3-platform station on a double track line on this basis:
->--C-------=======---S------->-
\ /
--S---=======---S--
/ \
-<-----S---=======-------C--<--
C=choose signal, S= stop/home signal. (With the middle line being a bidirectional platform).
The current algorithm does indeed mean that trains will tend to choose the nearest platform at which to stop, unless it is occupied. This is an interesting idea.