Atomic Systems

Hi folks,

I've been working for a while on my first go at route building - extending DTG's St Pancras - Bedford northwards, including secondary routes such as Bedford - Northampton, Northampton - Market Harborough (as much for practice as anything before I put much time into the MML itself.)

Having laid a fair amount of route mileage, I'm now snagging and signalling - I settled on AndiS's scripts (driving the Kuju Wooden Post UQ semaphores, as supplied) since they work for me better than anything else I've tried, without disconcerting stuff like signals cleared against you on single track sections!

Testing the route to check that all works as intended has thrown up a rather startling glitch - when running a scenario the player train is diverted off path at VERY short notice - I can be approaching a junction at line speed and have the peg for the main line path put back in my face and diverted into a siding at high speed, resulting in either derailment, a successful emergency stop, or a rapid coming together with the stop blocks. This is becoming extremely frustrating!!

This originally showed up in only one specific location, but as I continue this is showing up in several other locations, and a bit of a pattern is starting to emerge. Not knowing what's causing this, I'm not keen to spend time ripping up track layouts and reworking them with no confidence that I'll get rid of the problem!

A bit of background may be helpful at this point.

My starting point for all this was a clone of the DTG route.

As the era for the new work is early '60's, I added an appropriate track type (RSC's SC_track03) to the MML track rule so that I could work northwards without scrapping the original route. (in the fullness of time, I may gradually move the "time warp" between my work and the original route southwards from Bedford but for now I've got more than enough to keep me occupied!)

All of the problem locations involve a slip crossing, and a valid alternate path through sidings and back onto the main line.
(I think) all of the slips involved are ones that I've reworked in the course of my snagging - It's taken me some little while to realise what has been causing some pointwork not to render the frogs - as in, don't lay points over the little red triangles! I've eliminated all such examples now (the sim would let me drive over such junctions, it just looked naff!) Also, I finally figured out what was causing large parts of a crossing to disappear when I clicked on the grey "Weld" cube - I hadn't been paying close enough attention and TS was invoking the default track type because I'd not overridden it. This, I presume, is a side-effect of my tacking bits onto an existing track rule.

All of the slips involved were ones I originally laid the "hard way" before I found out what the second presentation of the "Weld" cube over a crossing was for (!)

Another peculiarity is that if I approach these locations under a certain speed, I'm not thrown off-path. At 20mph or under, I'm never diverted, and at 30mph or over I always am. This allows of a "work around" of introducing loads of 20mph TSR's - Hatfield style - but it's a sticking plaster and not a solution.

So:- Has anyone come across such or similar behaviour before?

Does anyone have suggestions as to how to eliminate it?

Also, is there a way of only creating a single slip crossing, as the auto "Weld" cube seems to give double slip and like it. ? This would be prototypically correct for at least some of my problem spots.

Waiting in hope for some feedback with this one,

Memphis

Some of your questions are answered below
Firstly, have you checked your path on the 2D map - if you have set the links incorrectly, it can appear that you have the mainline path by the signal, but the points are set for the siding/branch. If this is the case, swop the links (1 and 2).
You can change all the original track in the MML to the track of your choice using one of Mike Simpsons excellent tutorials (see http://www.rstools.info/ go to RWTools Tutorials). It will also show you how to get rid of the OHLE on the MML.
With slip crossings, the first weld gives you the diamond, flat crossing. As you have already found out, if you click again, you get a double slip. However, if you hold the LMB down, and maneouver over the crossing, you will see an outline that shows both slips when you are in the centre, or a single slip when you are at either side. Choose the one you wish, and release the LMB. Igf it is the wrong one, then just "undo" and try again on the other side. When doing welds, check the track rule/line type in the flyout menu. Always choosing "yard" ensures that you can get a slip.

Any more questions, just ask

Nick

Perhaps putting a 'go via' location marker on the main line might do it?

Some thoughts, with some overlap with others' thoughts.

The dispatcher loves to divert you in slips. It must appear the more favourable route in the internal path search algorithm. You need a go-via instruction beyond every slip to keep your train on path. Sad, but not much to do. (Of course, "every" is not really true, you can try and find out at which slips there is no derouting tendency and save a view markers.)

Are you saying the dispatcher changes the points only when you are near? Which AI trains precede your train? Are you really so close to them? The dispatcher waits some 5 seconds after a junction is cleared before changing points. But that should not be a problem and you should not get a clear signal approaching such a place anyway.

When the points change, the signal must reset while the path is broken. If this does not happen, the placement of the links is wrong. Be sure to have link 0 in front of the divergence of the track ribbons, not the points of the track model. What matters are these yellow or red outlines around the track and ballast shape. Likewise, be sure to have the numbered links beyond the convergence of the last points. Again, the place is defined by the track ribbons (i.e., yellow/red outline) and not by the 3D model of points.

Your description of creating the slips sounds a bit suspicious. Creating something that looks not too wrong but is not understood by the game for what it should be is a sure recipe for trouble with AI/signalling/dispatcher.

I would run the service as AI and sit at the problem location, carefully keeping an eye at points and signals to find out what exactly happens, in which sequence. Doing so, you also establish that the game sees the path as valid. Running AI all over the place, i.e., have it take all possible paths through a junction is a good way to establish that all points and slips are formed correctly and understood by the game.

Thanks for the quick replies folks,

- Brysonman46 - thanks for the how-to on forming single slips: I suspected there must be a way, but had not seen it described. I'll try that shortly. V.Useful.

- AndiS - thanks for the detailed analysis of how things are handled.

As regards AI, I'm still running Free Roam scenarios with the player train only - couldn't see the point of writing loads of scenarios until I'm sure that the signalling is at least working for the player train, as (I understand) any changes made will invalidate scenarios made previously.

In fact, the problem first manifested itself before I'd positioned signals at the affected locations - I was running Free-Roams to check on gradients, etc to iron out any shortcomings with that before putting other components in place. In fact,the first couple of times it caught me out, I thought I'd not set the route correctly, and it wasn't until I'd commissioned some of the signalling, and SEEN the sim lower the signal as I (player - and only - train) approached that I started to realise what was going on.

So it would seem that the signalling is not the fundamental cause of this, since the problem pre-dated it.

Running a Free-Roam and approaching a problem location, and toggling rapidly between 2D map and cab view shows the route remaining as set until I'm about 200 yards from the peg, at which point the peg drops on, the 2D map shows the changed route, and the path ribbon in the HUD display changes to reflect the changed route. All apparently simultaneously.

Can't comment on what it would do with AI trains as I've not been there yet...but I'll certainly follow your suggestion & set up some AI and see what the dispatcher does it it! And I'll try putting some more markers down to force the route with Go-Via's & see if it does as its told.

Speaking of markers, I've a question regarding those, but I think it best if I start a new thread for that.

Thanks people,

Memphis

memphis455 wrote:Running a Free-Roam and approaching a problem location, and toggling rapidly between 2D map and cab view shows the route remaining as set until I'm about 200 yards from the peg, at which point the peg drops on, the 2D map shows the changed route, and the path ribbon in the HUD display changes to reflect the changed route. All apparently simultaneously.

Since you have such a clear observation of the path change without any AI, I would get rid of these spooky trackwork. I never heard of such behaviour; you must have created something unique, and may I say, not to the better.

I don't know how much work would be undone by relaying these parts but placing markers and watching AI before altering the trackwork would just add to the time lost.

But wait, are you saying that there is no marker at all. I.e., that the only train does not have a destination? That could explain a lot. I never tried that and it could be that in such a case, the dispatcher gets into spontaneous mode, not knowing at all what goes on. So just put a destination marker somewhere at the far, add a destination instruction to your only train, and sit back and watch on the map. No effort needed.

Re. markers, the way I do it is this. I make sure there is an extra length of track (the 500 m straight that you get just by extending towards the horizon). There, I place a destination marker more or less on the far end. When the train reaches that, the scenario is over but I always quit before. Not having the marker near the junctions means I can stop it and go back and forth with the player train as long as I wish.

To be on the safe side, I make these markers longer than my test trains, but I am not 100% it is critical for destinations. I had cases where the dispatcher said it cannot make the path because the marker was shorter than the train. But I cannot remember which marker that was and this lies in the distant past. I just make my markers longer than the trains since then, as a general rule. This does not hold for go-via instructions.

As soon as the train has a destination, it will start off automatically, so it is AI by default. I generally put the scenario markers where I can see the trains in their initial location (just one end of the junction, of course), so I can grab the one that is to become player train easily. But nowadays, I us AI all the time, saving the energy for operating the train.

AndiS wrote:Since you have such a clear observation of the path change without any AI, I would get rid of these spooky trackwork. I never heard of such behaviour; you must have created something unique, and may I say, not to the better.

Yes, I'd kind of gathered that...

I've reworked all of the problem spots and some that had the potential to be, removing superfluous slips created by my not knowing how to constrain TS to single slip mode.
Now that I know the trick to doing it, getting rid of those unwanted facing connections has improved things enormously, as well as simplifying the signalling layout required.

Bit of a fiddle - interestingly, in some locations TS would render a double slip correctly, but not single. I think this occurs when the track layout is close to the boundary condition of whether a slip is possible or not.

In one location TS absolutely refused to render a single slip, displaying all kinds of weird ghost images. That one I left as a plain diamond crossing, since an alternate crossing between up and down mains existed fairly close by, so I was giving little away by simplifying the layout.

In others, I noticed that although TS had rendered a slip and no red "this ain't right" rectangles were being displayed, the frogs had not formed. Mindful of AndiS' warning about confusing the sim with things it can't properly interpret, I eased the geometry to make a shallower crossing and this did the trick.

Taking out pointwork and relaying with plain line can be a struggle if a long gentle curve is involved - snap to straight seems to override snap to track(and putting it into snap to track mode rather than using <ctrl> to force the snap didn't seem to be playing at all), so I had to remove quite a length before the amount of curvature allowed it to snap to the exising layout. Got there in the end though, and another lesson learned..

I'll have a play now & see if all I've done is OK before I tackle the complex layouts at Market Harborough and Blisworth - left those till last as they could be an absolute nightmare...

Thanks for the help people,

Memphis

I have experienced last minute "pointwork changes" notably on ECML South at Welwyn Garden City heading south from the fast line to the slow line, and WCML Over Shap heading south at Carnforth. These were all free roam scenarios.