PDA

View Full Version : Interlocking Towers



pw3r
January 29th, 2016, 12:46 AM
I'm splitting this discussion off from another thread to avoid interleaving two unrelated discussions. Original posts and context can be found here: http://forums.auran.com/trainz/showthread.php?128204-Route-Load-Save-Changes&p=1483833#post1483833

I've attempted to address each concern as Chris and I have interpreted them, but there is not a lot of detail so apologies if my assumptions are incorrect. Please read through each point and provide feedback or further information where appropriate.


As for Interlocking towers, i can't see there per-junction path release

Interlocking Towers internally support the ability to have the path "clear" as it is driven. This is done by setting the path clear state to ITP_CLEAR_ON_DRIVE. Once in this mode, the junctions will revert to their original directions as soon as the train clears them, rather than waiting until the train has cleared the entire path.

It's worth noting there is no UI to enable this mode for the example tower, and as such it has not been heavily tested.

Is this the behaviour you are after?


the direction of path occupation (it is worth to prevent two paths lead towards single curcit point)

I'm not sure what the concern is here, you'll need to provide more detail. For clarity, our implementation gives every Interlocking Tower Path a clearly defined direction, as set by the entry signal facing. Paths are by definition uni-directional and the concept of a bi-directional path is not supported and not protected against internally. (i.e. Nothing prevents a player or AI train from travelling down the path in the 'wrong' direction. It's up to the session creator to protect against this where appropriate.)


automatic generation of path

I'm not sure what you mean by this. Path generation in Surveyor is as automatic as it can be while meeting the goals of the Interlocking Towers system. By that I specifically mean that Interlocking Towers are supposed to provide clear structure to an area of track. Their purpose is to ensure that certain track stretches/junctions/signals behave in certain ways, and only grant passage to certain areas. As such, the available paths must be clearly defined in advance. We've tried to make this path generation as straightforward and automatic as possible but they usually require some interaction in the interface. I don't see any way to avoid that.

If this level of restricted travel is not desirable for a section of track then you probably do not want it controlled by an Interlocking Tower, and can make do with the existing signal system.


impossibility of "shunt path" (when all tracks are free, but the last one is occupied)

Again, I'm not sure what you mean by this.

Areas where you need to do a lot of shunting (such as a yard) are best left uncontrolled in most circumstances. Interlocking Tower Paths can be used to override signal states and allow entry into a yard while it is occupied by other trains but the yard itself is best to not have any Paths defined within it.


automatic selection of clear tracks to prepare path

Automatic path assignment isn't really possible for player trains, but it is already performed on AI trains, so I'm not sure what this refers to. See below for an overview of the path assignment logic.

By default our implementation automatically assigns paths to AI trains based on their destination (extracted from their schedule) and using a priority queuing system. As it is not possible for the tower to know the destination of a player train, players are prompted to select a path themselves. It is also possible to manually set paths using a number of builtin session rules.

For situations where this default path assignment logic is not desirable we have provided a listener interface in script which will allow scripters to define their own assignment logic. See the "Interlocking Tower Manager" script for more details.


And mid-station block direction switching (yes, block system also has ability to change its direction !).

I'm not 100% clear on what you mean here so apologies if this is completely wrong. I think what you're after is to have a train stop at a station and then reverse direction. There is nothing preventing this with careful path creation, but currently the best way to do it is to not have the station itself within the path (i.e. use a path into the station, and a separate path out).

Beyond that there are ways to do this in script but you will need to be careful to ensure that the system remains safe against derailments. The basic process would be this:
* Start listening for any train movement. If the train moves before this process completes, trigger a panic state.
* Assign the train to the desired path in the other direction, making sure it gets inserted into the front of the activation queue.
* Remove the train from the currently assigned path using InterlockingTowerPath.RemoveTrain().
* Cancel the currently active path, waiting for the completion message before continuing ("InterlockingTowerPath","Cancelled").
* Activate the new path, and manually set the path entry signal to red to reflect that the path is already occupied.

This would be a very delicate operation and you would need to be extremely careful to ensure that no other trains interfered with the process, but it's not impossible to implement on a third party tower as some manual operation. If you were to implement it, it would also be wise to ensure that player control of the train is disabled during the process, or possibly even disallow it if the train has a driver assigned.

Terry Palmer
Programmer
N3V Games

WindWalkr
January 29th, 2016, 02:10 AM
.. our implementation gives every Interlocking Tower Path a clearly defined direction, as set by the entry signal facing. Paths are by definition uni-directional and the concept of a bi-directional path is not supported and not protected against internally. (i.e. Nothing prevents a player or AI train from travelling down the path in the 'wrong' direction. It's up to the session creator to protect against this where appropriate.)

I'd clarify this further. Firstly, there's nothing preventing the creation of two paths which are the exact reverse of each other in terms of direction. Secondly, the train will likely be unable to reverse very far due to signalling- I would expect that any signals facing against the path's direction would be held at "stop" while the path is active. Third, I'm pretty sure our example tower doesn't allow the concept of a direction reversal within the path itself (meaning that you can't specify a path which goes A->B->C1->B->C2.) I'm not sure that this is anything fundamental in the Interlocking Towers system itself, just our default UI. (Terry?)



* Cancel the currently active path, waiting for the completion message before continuing ("InterlockingTowerPath","Cancelled").
* Activate the new path, and manually set the path entry signal to red to reflect that the path is already occupied.
...
..it would also be wise to ensure that player control of the train is disabled during the process..

1. Are you still talking about the case where the station is outside the paths? If so, wouldn't the train be outside the entry signal of the second path at the time it is activated? In which case you wouldn't need or want to set the entry signal to red. You also wouldn't need to cancel the path that you just left, would you?

2. I don't understand why you would need to activate the new path manually; if you put a regular request in then the tower would typically activate it automatically at the first legal opportunity?

3. Again assuming that we're talking about the case where the station is outside the path, I don't understand the need to disallow control of the Train. For the user to do something inappropriate, they'd have to cross into controlled territory where they would have a signal set against them?


chris

pw3r
January 29th, 2016, 02:51 AM
I'd clarify this further. Firstly, there's nothing preventing the creation of two paths which are the exact reverse of each other in terms of direction.

By definition, you cannot create two paths which are the exact reverse of each other, as the signals define the path and their facing defines the path direction. I think what Chris means is that you could create two similar paths with alternate direction, if you wanted to. This would obviously require extra signals, and may not be appropriate in some scenarios.


Secondly, the train will likely be unable to reverse very far due to signalling- I would expect that any signals facing against the path's direction would be held at "stop" while the path is active.

There's no guarantee of this, but it's reasonable to expect that if the Interlocking Tower area is well configured by the route/session creator then it will be true. (Either due to conflicting paths in the other direction of travel, or just because of the default signal logic.)


Third, I'm pretty sure our example tower doesn't allow the concept of a direction reversal within the path itself (meaning that you can't specify a path which goes A->B->C1->B->C2.) I'm not sure that this is anything fundamental in the Interlocking Towers system itself, just our default UI. (Terry?)

As already mentioned, the idea of a "direction reversal" doesn't make any sense because of the way we define paths. Furthermore, the Interlocking Tower edit UI will detect and reject any path configuration that results in a path looping back on itself. I haven't checked but I believe Chris is correct in stating that this is only protected against at the UI level. I cannot guarantee things within the tower would work as expected if that restriction were bypassed though.


1. Are you still talking about the case where the station is outside the paths? If so, wouldn't the train be outside the entry signal of the second path at the time it is activated? In which case you wouldn't need or want to set the entry signal to red. You also wouldn't need to cancel the path that you just left, would you?

No. This was suggested as an alternative approach that could be implemented to allow one path to be assigned to a train while it was already occupying another conflicting path. This would need to be handled internally within the Interlocking Tower script, probably as some manually triggered action, and with a lot of protections.


2. I don't understand why you would need to activate the new path manually; if you put a regular request in then the tower would typically activate it automatically at the first legal opportunity?

In this scenario you would have manually cancelled an occupied path. If you allow the normal path assignment logic to run then there's a chance the tower may assign some other random train to a conflicting path, hence the need for immediate manual reassignment.


3. Again assuming that we're talking about the case where the station is outside the path, I don't understand the need to disallow control of the Train. For the user to do something inappropriate, they'd have to cross into controlled territory where they would have a signal set against them?

Again, I'm not. If this kind of manual path reassignment were to be supported then any kind of movement from the train mid-process is obviously going to be problematic, as the state of the path objects is unknown. Even with preventing/detecting train movement it's possible the train is going to find itself in trouble if it is, for example, on top of a junction when all this happens. This is why it's unlikely to be a supported action, it's simply too dangerous and is more easily overcome by placing the station outside of the paths.

Terry
N3V Games

WindWalkr
January 29th, 2016, 03:32 AM
By definition, you cannot create two paths which are the exact reverse of each other, as the signals define the path and their facing defines the path direction. I think what Chris means is that you could create two similar paths with alternate direction, if you wanted to. This would obviously require extra signals, and may not be appropriate in some scenarios.

Yes; paths as in the track occupied, not as in the actual signal states. If the reversed signals simply aren't present, then this isn't possible (but also not necessary as far as I see it, because without signals there's nothing stopping the player simply driving off in that direction.)



As already mentioned, the idea of a "direction reversal" doesn't make any sense because of the way we define paths.

This is true; even if it is possible to define such a path, it would be impossible to lock it in since it would require the B-C junction to be in two different states. Since we lock the entire path in to start with (not as the train progresses) this won't work.



No. This was suggested as an alternative approach that could be implemented to allow one path to be assigned to a train while it was already occupying another conflicting path. This would need to be handled internally within the Interlocking Tower script, probably as some manually triggered action, and with a lot of protections.

Fair enough. In that case, it sounds like a good opportunity for a completely different mechanism; we'd want to cancel the existing path (which may not actually complete, because there's still a train on the path?) and then lock in the new path (without the usual wait for the original path to fully cancel?) We could raise the priority of the new path so that it's serviced as soon as possible, but we can't ensure that it will be serviced immediately because there might be other conflicting paths. So I think there's more than just a sequence that you need to run through, and instead we might need additional state.

(I discussed this a bit with Terry offline and it seems that the idea of cancelling a path while a train is actually on it is poorly defined in the spec, so it's unclear what this would actually do- I don't recommend third-parties dabble in this area until we get the spec cleaned up in this area.)

In the worst case you may even have a deadlock scenario here, since you're failing to cancel the existing path and simultaneously blocking to create the new path.



If this kind of manual path reassignment were to be supported then any kind of movement from the train mid-process is obviously going to be problematic, as the state of the path objects is unknown. Even with preventing/detecting train movement it's possible the train is going to find itself in trouble if it is, for example, on top of a junction when all this happens. This is why it's unlikely to be a supported action, it's simply too dangerous and is more easily overcome by placing the station outside of the paths.

I think this is an interesting discussion to have, and it really hinges on how much of the existing path can be cancelled and how much can be reused. As long as the train can't move out of the area that will be reused, you don't have a problem- and since you're cancelling the rest of the existing path, my gut feeling is that the train shouldn't be able to move out. It's certainly a complex topic, and probably not worth going into further here- you're right that simply locking out the train controls temporarily works (as long as the user understands what's going on, which is a session-creation problem, not really an Interlocking Towers problem.)

chris

TRam__
January 29th, 2016, 04:04 AM
Areas where you need to do a lot of shunting (such as a yard) are best left uncontrolled in most circumstancesIn the case when the juctions are not automatic and switched by driver/condutor/driver assistant. In case of centralised control from tower automatic/semiautomatic path locking and signals with white light used (in ex-USSR railroads).


>Are you still talking about the case where the station is outside the paths?
> This would need to be handled internally within the Interlocking Tower script, probably as some manually triggered actionThough on one-track lines the direction changes of mid-station blocks are automatic. In case of my path system it take two protections: that the span between entry signals is clear, and there are no path from opposite station in the direction of our.


Their purpose is to ensure that certain track stretches/junctions/signals behave in certain ways, and only grant passage to certain areas. As such, the available paths must be clearly defined in advance.In my case i've implemented "track searching barrier objects" (directional and absolute one) and added a property of "lower/higer priority tracks" (in fact saved in signals, because from different direction the track has different priority to occupate, the range 0 - 30 ). And an action of "automatic comparation of generated paths and clearing long unefficient paths". Yes, for long and complicated stations it leads to "timeout" errors when more then hundred of paths have generated, but that fixed with mentioned barriers. In case of "shunt paths" i'm searching for first fount path to destination, in sace of "train path" = all exist paths.

In both cases search is recursive with first check of initial junction direction, so sometimes the results are not as good as it can be with none-recursive. Though, in case of recursive search we able not to save all intermediate search results, only the last one and the database of already checked junctions.


but currently the best way to do it is to not have the station itself within the path (i.e. use a path into the station, and a separate path out)Yes, and they are separated with entrance and exit signals. It is correct. But i mean that there can be multiple trains between stations (and even more then one train per block in case of pushing loco decoupled from the train), so the exit paths can lock immidiatly after all their junctions are free, or when the nearest block to the station become clear. In case of station track there should perfomed a check if there is a junction between the end of this path and other oncoming path (or "special" track curcit, when the track is specially divided into two parts for short EMU/DMU from opposite directions, and this mode of track separation is switched on).