simonjackson1964 Posted September 30, 2022 Share Posted September 30, 2022 Apologies to anyone who has already figured this out on their own, or has actually got a better way of doing it. Something I have noticed while travelling by train is that on modern railway networks it is normal for the signals on the main line to default to "Clear", green, "drive" or off (all meaning the same), unless there is a train in the block they are protecting. This is to avoid unnecessarily slowing an express train. I can't say this for certain but I can imagine that in the days of hand pulled signals, the signalmen would want to clear the express through as far as possible too. One way to try and simulate this on MBS v7 would be to have a single route containing all the block sections you wish to clear at once. The problem with this is that the route will not fully release and thus will not allow another train into the first block, until the last block is empty. Obviously this kind-of defeats the object. The ideal way to set routes is a one-to-one correlation between block sections and routes. A better way to simulate the route of the train being cleared as far as possible is to "cascade" or "domino" the individual routes. Each route will have a variable on it, naming the next route in sequence. There can also be a keyword if you wish but it's not strictly necessary. An event "When any route is activated/deactivated", holds the condition: "If Trigger Route is Active", and the action: "Activate Route (Trigger-Route.Next-Route)". Defer Request is important, as at some point you will have a route that cannot be activated immediately due to a train being on it. I have tested this and it works perfectly on a straight track between two depots and on a continuous circuit. Set one route to clear and the rest cascade all the way around. On a continuous loop with a single train it will clear the entire loop except the one with the train on, but that will be deferred until the train leaves, allowing the train to run indefinitely on the loop with no intervention. But what about junctions? What if there is more than one possible route for my train to take? For this we require a slight modification: On any route where there is more than one possible next route, do not add the "Next Route" variable to it. Instead, place a track contact at the earliest place a train will encounter it - this will usually be immediately after any preceding junction, inside the first block after that junction. This track contact should have a keyword "Junction" (or similar), and a list variable holding the routes available for that junction. While this would normally be two, a multiple junction for sidings would be treated as a single junction. NB: This solution does not cater for choosing the First Free Siding. I leave that for people to figure out on their own! But if each train always goes into the same station platform, for example this works just fine. So: Track contact in place. Now each locomotive that will pass through the junction will need a list of routes it will take at each facing junction it comes to. If the train will only go through one facing junction, still use a list, as this cuts down on coding. A list of one element is still a list. Now we need an event, activated when a track contact with Keyword "Junction" is triggered upon entering The keyword is important and can be added to any track contact including a signal, as long as it is in the right place and has the list of available routes on. Within this event we have two nested iterations, one for the triggering contact and the other for the triggering vehicle. It doesn't matter which order they are in, but I usually put the track contact one outside because usually (not always) it will have the fewer iterations. Within the inner iteration, the condition "If Iter1 = Iter2" will say "This train is taking this route", and if the condition is met, set the route active-deferred. Important: This is not necessary on trailing junctions, only facing. The route immediately before the junction is the one that does not have the "Next Route" variable and is the last possible place that the "Junction" track contact can be. The routes that start at the junction should each have their own "Next Route", so that when the junction is set, the cascade/domino will continue Terminus routes, including those ending at a virtual depot or fiddler yard, will not have a "Next Route". This should work, in theory, if routes for more than one junction are placed within the same available list on a single track contact, thus cascading past multiple junctions. However I've not tested this on an actual layout, only on a test-bed. I hope someone finds this useful. Cheers. Simon Link to comment Share on other sites More sharing options...
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!Register a new account
Already have an account? Sign in here.Sign In Now