Single Line Section Lengths

I have noticed before people asking about problems with signals not working due to the distance between them.

I have recently been modifying a route for AI opertaions and have had similar problems.

The route is 'Avery - Drexel' by 'tume'.

This route is a must see for the great scenery work and details.

The result is I have been testing the distance for signals and trackmarks.

Both seem to have a distance limit of around 24km (15m).

Although the loops were close enough for the trains I had set up as they had markers in the crossing loops, the motorised fettler trolley would not proceed because I was using markers too far apart.

Solution is to put markers along the line at no more than 24km apart and drive via them. Or to use the other loop markers and drive via them.

So if you have 'Unsignalled' or 'Line closed' problems, shorten the distances.

Dennis

to be honest, i never even imagined my route ever having that much between two signals, 24 km's, ouch. Ok, advice taken... and this gives me some ideas too

Or place several "Signal Invisible" along the line.You don't see them in Driver but they keep the AI drivers happy.

Dennis et al,

We have to remember that signal distance is usually driven by the number of trains on the line along with train length. If you're going to run long freights and few short trains, then you want your signal distances longer to accomodate the length of the train. If you run a lot of short fast trains such as commuter trains, then you want your signals closer together. The closer signals with the faster trains allow the operator to pack more trains on the line and still keep them moving quickly.

John

Hi Lewisner:
Invisible signals will help AI trains, but it also creates the old 'cornfield meet' problem.

Hi jcitron:
What you say is correct for double line. On single line working their are only signals at each end of the section. The length of crossing loops is the main factor due to problems with trains too long for the loop approaching from both directions.

My original problem was trains would not proceed because the sections were too long. I have since added extra loops to shorten signal distances, and give 'navigate via' commands to closer markers and it is now running perfectly with 8 AI trains.

Keep signal & marker distances under 24km and no problems.

As I said in the original post, have a look at the 'Avery - Drexel' route, it is very well done. Good work 'tume'.

Dennis

Hi Dennis,

Thank you for your very timely thread on this topic.

As Craig & my "Narrandera_Tocumwal" branch line project is a single track over-100 mile route, interspersed with fairly short loop spurs in cases possibly more than 24 miles apart, I find this invaluable!.

As an adjunct to the actual rail route, we have included the McIntyre Field WWII airbase at Tocumwal. Being 25 square miles, it was the largest in the Southern Hemisphere back then.
This airbase will have various aircraft in action, & some of the distances possibly could go beyond 24 miles. But my main concern is how to keep their speed up; on a single-flight-path circuit.
Can you advise please, is there any way of forcing the aircraft to continue flying at a reasonable pace, right up to initial touch-down?.
Some ELF's (Emergency Landing Fields) are just grassed paddocks of short length. Others are in reality a mile long (but we'll bring that back a bit, to say a kilometre). At present, I have a B24 bomber trying to fall out of the sky at about 80 km/hr, wheels down, about half a km away from touch-down!. Prefered touch-down is 90, presently more like 65-70 km/hr.
Is there a way of reducing this apparent 1km trigger radius, for I guess the landing placemark??.

Apologies for 'wordiness' :hehe:

G'day Noel

If you are using one direction only for the aircraft there should be no problem with invisible signals/markers along the invisible track. It's only a problem when both directions are used on one line.

Place the signals along the flight path about 20km apart and use markers to 'navigate via'. Don't forget the invisible speed boards.

The trains could be a problem though with keeping to a prototype line. The problem is mainly AI driving. Manual driving is not so much of a problem as you can have intermediate invisible signals.

I like the challenge of getting many AI trains to run without errors. Bit difficult with prototype routes though. The computer/AI sees the section a bit differently to a human. Once you get you head set to understand how it works it is a bit easier.

Looking forward to seeing your finished route.

Dennis

hi dennis

i use block signalling on my sometimes very long single sections and they run very well

the route is with the beta testers at this time and i hope to release the 2006 tc version by the end of the month

09-10 needs to have rolling stock and locos exchanged to some that work

email me if you need specifics
cheers
ron

This problem affected my Scottish routes in TRS2006, the Mallaig line in particular, but I had been kind of led to understand the improved signalling scripting from TC3 onwards had improved matters.

There are many real world instances on single lines where crossing loops can be up to 20 or 30 miles apart, where traffic is light or the infrastructure has been rationalised. Certainly in the UK or where traditional staff or token working is in operation, it's very rare for single line sections to be split by intermediate signals for traffic control purposes.

on my Kettle Valley Railway route I have signals at passing track locations and intermediate signals on upgrade track only. This allows slow moving freights to follow more closely together or for faster trains to catch up to the slow freights. The distance between passing tracks is rarely more than 15-20 miles and I have yet to have a problem even if I assign a train to drive to a trackmark over 250 miles away. all of my signals are invisible as my route runs on TT&TO. I just use the signals to keep the AI happy

Many thanks to everyone for your valued assistance with this, I really appreciate it & will bear in mind the excellent advice given.

My main concern at present is getting aircraft to remain 'at speed' until on final landing approach. Presently their speed on approach & touch-down is forced to a too-slow one.

I reiterate here:-
"Can you advise please, is there any way of forcing the aircraft to continue flying at a reasonable pace, right up to initial touch-down?.
Some ELF's (Emergency Landing Fields) are just grassed paddocks of short length. Others are in reality a mile long (but we'll bring that back a bit, to say a kilometre). At present, I have a B24 bomber trying to fall out of the sky at about 80 km/hr, wheels down, about half a km away from touch-down!. Preferred touch-down is 90, presently more like 65-70 km/hr.
Is there a way of reducing this apparent 1km trigger radius, for I guess the landing place-mark??."
:wave:

hi nbrettoner

have you gone to the item in surveyor with the ?

i use that to reduce all the radius of the trackmarks and signals

should also work for you

maybe an invisible signal or two before where it needs to come down so that it doesnt see the caution signal before coming in to land
cheers
ron

Hi Ron,

Thanks for your advice. I've inserted blue italics comments/queries amongst your following quote:-

misterchugg said:

hi nbrettoner

have you gone to the item in surveyor with the ?
I'll check these out again. Forgot what radii various things had. I think some didn't show a radius setting??

i use that to reduce all the radius of the trackmarks and signals
OK. Thanks for this jewel Ron.

should also work for you
Hope so, & will get back later today once I have time to try it out.
Thanks mate.

maybe an invisible signal or two before where it needs to come down so that it doesnt see the caution signal before coming in to land.
I take it Ron, that we can place signals away from junction points?.
They don't have to be associated to a particular points set, nor within a certain distance from a set of points then?. I didn't know this, & it will help immensely!
cheers
ron

Click to expand...

Many thanks Ron, & the various other learned contributors here. Much appreciated.