Junc. Signals

The MSTS Activity Editor allows you to make your own activities, or missions, for the player to complete. This is also how you can get lots of other trains running while you drive yours!

Moderator: Moderators

borthstation
Been on the forums for a while
Posts: 129
Joined: Wed Jul 25, 2007 11:11 am

Re: Junc. Signals

Post by borthstation »

Hi,
My own method is similar to Geoffrey's - take it a bit at a time, and create your AI paths over short stretches. Whilst this means that MSTS chugs through lots of paths, it seems far easier to operate than the long path system. You can then use simple to follow path names - I tend to use a format for path names of: place1-place2(P) or place1-place2X-place3(P), where the "X" is a path that facilitates a cross on (normally) a single track route - most of my activities are for such lines. My AI Service names will then be of the format place1-place2-1#, where the "-1#" shows it to be train variation number 1 over this path and the # shows it is an AI service.
I usually run the player path and note down the start / stop / passing times, taking the run as far as any complications (like a cross on a single track). I can then set in any easy AI to that stage and also set in the crossing AI. I then re-run and check that the crossing AI (or whatever the more complex event is) works and make any adjustments - e.g. to how long I wait to cross, or station load times. I then proceed, noting the times, and repeat the process.
Checking some AI events with AE can be useful, but, as Geoffrey has pointed out, this often fails. For example, it won't cope with an event like being held up by a player train or another AI interacting event. Don't use AE to check player running times - it just doesn't happen that way!
All I can say, Richard, is to keep plodding away at it. When I first started I had a lot of trouble with passing on single lines and converging junctions. You'll find some of my questions from way back, often concisely answered by the late Laurie Dickerson. With practice, I now find that 90% of planned passes work correctly first time, and you even get to be able to judge exactly when the event will happen - I rarely have to adjust times by more than a few seconds. My Bala "meeting" mentioned below involves a player, three AI trains and an invisible blocker. It also relies on an earlier cross to stop the player grabbing an AI path further down the line. All this on single track lines. It worked perfectly first time and I only needed to adjust one AI time by 15 seconds. You'll be able to do it too with practice - just keep bashing away and try to get the principles. (Then watch MSTS throw in a bit of a wobbly just to defy logic!)
Finally, I always find that explaining crossing / convergence, etc, is far more difficult than actually doing it!
Keep at it!
Chris.
borthstation
Been on the forums for a while
Posts: 129
Joined: Wed Jul 25, 2007 11:11 am

Re: Junc. Signals

Post by borthstation »

Hi,
Further to previous post, the following little summary may be of help.
Assuming that a standard signal scripting is used, I find these to be the most common occurances of signals not conforming to what is expected at junctions and on single track routes with loops, and where the 3-block rule has been obeyed:-
1. the AI passes through a loop before the expected passing place and waits there instead of proceeding to the logical crossing point. Only obvious solution is to make the AI path not pass throught the first loop. This means using fewer than 3 blocks. Will normally work, but if AI halts at loop starter, even when clear, make sure onwards path goes through next 3 or 4 signals.
2. AI has a wait point. Sometimes seems to give player priority, even though it shouldn't.
3. There is a diamond crossover / slips points on the path. This sometimes seems to baffle MSTS. Tends to result in both parties getting a green rather than a red that won't clear. The AI will normally "play safe" and stop before a collision occurs.
4. One I've had several times: a signal with no junction link protects a junction where player turnout NOT pathed would run into the AI path [see below for example].
5. Facing crossover points between lines that appear not to be protected by signals. Actually, they are protected by the previous signal, which probably has no junction link. (Similar to 4).
6. Signals occuring within a loop on a single track line. Sometimes you count them logically into the 3 blocks and sometimes it completely baffles MSTS. I have a solitary example where I've tried every single placement possibility for the AI, and none work!
In the case of 4 and 5, what often happens is that the AI train will pause until the player has cleared the points and will then proceed.
Doubtless there are other situations. Please see next post for example of 4, as this post is getting unwieldy.
Chris.
borthstation
Been on the forums for a while
Posts: 129
Joined: Wed Jul 25, 2007 11:11 am

Re: Junc. Signals

Post by borthstation »

Hi,
Moving on to the example of (4) above.
I have an activity with a Down Mail from Oswestry to Aberystwyth on Cambrian2. It waits at the converging junction at Buttington for a Shrewsbury - Welshpool local passenger which also conveys a GUV. The AI runs ahead and disappears out of player view at Welshpool. When player reaches Welshpool, stock from AI is standing at adjacent platform. Player collects the GUV from it and rejoins his own train. AI loco has a path set to take it from the points just beyond its (apparent) train to a headshunt siding. It then reverses on a parallel line to the stock to the water tower, where a suitable waiting point is placed.
Except... although the player and AI paths don't ever coincide here, the AI waits at the points that would take it back to its stock, even though they are set to the water tower line. The player, of course, is using this adjacent line to pick up the GUV. Once the player has cleared the potentially converging lines, the AI happily proceeds to the water tower. The AI has a clear disc signal throughout, and the player also has clear signals. Why does the AI wait at clear signals with a path that can't possibly allow a collision? Apparent answer: it passes facing points that, if set to the other direction, would cause a collision. It has only one signal to pass, due to the very short path. But... that signal is a non-junction (i.e. non-linked) disc that protects two possible paths. MSTS plays safe...
That situation is not uncommon, especially on sidings that have points to a mainline.
More confused than ever??!
Chris.
Richard604
Been on the forums for a while
Posts: 295
Joined: Sat Jul 14, 2012 7:25 am

Re: Junc. Signals

Post by Richard604 »

Thanks to you all, it is going to take my poor old brain a long time to digest all this.

Regards

Richard
User avatar
systema
Very Active Forum Member
Posts: 3819
Joined: Mon Sep 08, 2003 8:00 pm
Location: The Heart of Cheshire

Re: Junc. Signals

Post by systema »

Most problems occur when an AI path crosses the player path or runs along the player path for a short distance, especially if in the opposite direction.

A stand off will almost certainly occur if either of the crossing/joining paths has reverse points anywhere along its route especially if in opposite directions. The same applies to multiple waiting points which are sometimes used in place of reverse points.

Reverse Points and multiple wait points can however normally be used to successfully control one train passing another travelling in the same direction.

By far the best way to achieve what you need is to use use slow and/or faster invisible blockers with wait points on strategically placed short paths. Do not have any reverse points or multiple wait points on the paths in question. The wait points give you sufficient time to have the route blocked before anything arrives there. The wait point can be timed to release the route when you need it. Unfortunately even this is not infallible and problems can still occur depending on the situation. It can help to have static blockers where there are multiple exits from a signal. These can be actual trains or invisible blockers. You will have to experiment with the blockers and timings.

Mick Clarke
MEP
Heading North and East
[album 86570 OR_Supporter_Logo_Red.jpg]
Locked

Return to “[MSTS1] Activity Creation”