PDA

View Full Version : switch resets early



mikeaust
February 11th, 2012, 08:31 PM
I have had this problem for a long time in various versions of the game.
What happens is that the switch lever reverts to the latent state as the last wagon passes over it and causes the train to derail.
Sometimes the problem can be solved by changing the latent state of the switch, but often this just moves the problem to the other track.
I am just wondering if anyone else has had the problem before.
I tried searching the forum but found nothing to help.
Cheers,
Mike

William0d0
February 11th, 2012, 09:29 PM
I had this problem when I put signals on a separate layer in a route I'm building. Merging the layer solved it.

Had the problem another time with a session, had a trigger resetting a junction. Solution was to move the trigger further away from the junction. I think that may also be a layers related thing, since the trigger was on a session layer.

mikeaust
February 11th, 2012, 11:22 PM
Thanks for the info. Didn't work unfortunately.
cheers,
Mike

llebrez
February 12th, 2012, 12:10 AM
An old problem. You have to do some investigative action here. Try to change the car that does this. Also turn the offending car around. Ultimately you'll discover that the problem happens to some cars and not to others. Almost impossible to see is where is the car attachment to the guide of the track. Basically this happens because somebody many years ago decided that the points should change to default possition after the train goes over them, and so, Trainz was born! (with these bugs..) If you set the switch in defult so that it woud not change, you'll discover that sometimes, after you do some switching, the problem comes back. My idea is that NV3 should look into this (so far, even with me bringing some hell time ago they haven't done anything), and delete this "feature" that serves no practical purpose. Any comments anyone?

JCitron
February 12th, 2012, 12:13 AM
An old problem. You have to do some investigative action here. Try to change the car that does this. Also turn the offending car around. Ultimately you'll discover that the problem happens to some cars and not to others. Almost impossible to see is where is the car attachment to the guide of the track. Basically this happens because somebody many years ago decided that the points should change to default possition after the train goes over them, and so, Trainz was born! (with these bugs..) If you set the switch in defult so that it woud not change, you'll discover that sometimes, after you do some switching, the problem comes back. My idea is that NV3 should look into this (so far, even with me bringing some hell time ago they haven't done anything), and delete this "feature" that serves no practical purpose. Any comments anyone?

I agree! I've been burned more than once while switching because the program decided to flip a turnout on me. This is particularly painful when backing up along freight into a yard siding.

John

mikeaust
February 12th, 2012, 04:11 AM
I have been getting peeved with 100 car coal trains entering the main line from a mine and the last car cops it. The train copes with entering the main track, it rdes over the switch, but when leaving the last car diverts. I use two switches to cross the down track to reach the up track.
Trying not to have the unrealistic trains crossing through each other, by just crossing over the main track.
I often get over the problem by using a flyover to get to the other side. In this case I have another entrance doing a flyover nearby and really cant place another one.
All the coal wagons I have seem the have the problem. will try reversing the last units.
cheers,
Mike

shaneturner12
February 12th, 2012, 04:58 AM
The Check Turnout Alignments rule sometimes sorts this issue out.

Shane

JohnnyC1
February 12th, 2012, 11:12 AM
I don't run super long consists so this has not happened to me, however what has occurred were derailments caused by the junction controller if you manually reset a junction and there is a consist over the junction on the flyover section.

John

llebrez
February 12th, 2012, 12:19 PM
Check turnout alignment does not fix the problem. That was the first thing I tried.. years ago.

shaneturner12
February 12th, 2012, 01:10 PM
Sounds like it's got a bug in it. Apart from that, shorter trains is probably going to be the answer.

It's the bug that that rule is supposed to fix.

Shane

mikeaust
February 12th, 2012, 01:43 PM
Thanks for all your advice, nothing seems to work.
Doesn't make any difference what length the train is.
I have beaten it this time by reversing the direction through the mine and using a normal crossover to swap tracks.
I am able to have the switches preset for the direction I need to go.
cheers,
Mike

JCitron
February 12th, 2012, 02:05 PM
Sounds like it's got a bug in it. Apart from that, shorter trains is probably going to be the answer.

It's the bug that that rule is supposed to fix.

Shane

I agree this is a bug, and it seems to be worse with TS12.
Running short trains is great for commuter trains, and long distance passenger trains, but what about a modern North American freight? These are 50-plus cars long normally. The effect is as though the program forgets the length of the consist and resets after a certain amount of time instead of waiting until the consist completely clears the turnout.

John

shaneturner12
February 12th, 2012, 02:15 PM
The bug is normally characterised by the last two vehicles in the consist de-railing, usually if an AI train has changed the points for it's own use. There is a way around it though.

The driver commands ControlJunction and FreeJunction , are probably useful for this. ControlJunction can be used to lock a junction in favour of the train until the latter command is used to unlock it.

Both commands are TRS2006 and above, and are by user atilabarut.

Shane

JamesMoody
February 12th, 2012, 07:03 PM
Can someone please post a consist definition for a consist that suffers from this reliably? Preferably using either built-in or DLS sourced assets :)

mtldrm38
February 12th, 2012, 08:34 PM
have ya looked at the type switch your using as Ive come across some that went haywire at times and theyre scripted and hence then a portal manager or rule can also clash with some switches I ve discovered.......just a thought of mind if ya run out of solutions.......also are you using cant recall the name exactly but it was a type trigger that aligns xover switches and dang if it didnt always derail the last car..........

mikeaust
February 12th, 2012, 10:48 PM
I have only had third party rollingstock give me the problem in T012.
The only builtin units were in TS2010 and they were the UP Hopper 3 bay kuid2:58442:15220:1.
The Units giving me problems in Ts012 were, HO5BBNSF 651000-651386 H2 JAC AFIII, kuid:6421:651000, from RRMods, 100 car consist, the other was Bethgon KCLX, kuid:64083:15891, from TPR, 100 car consist.
Both units ran elsewhere on the route with no problems, except for the pair of switches that were causing the problem.
The switch leading onto the mainline was changing early but the car stayed on the track. when the consist left the mainline the switch changed just as the front trucks passed the switch, causing the rear trucks to divert.
sorry I cant be more helpful,
cheers,
Mike

mikeaust
February 12th, 2012, 11:14 PM
Hi mtldrm38,
I run very simple controls using the Trackside Point Motor QR with ordinary signals controlling the train.
Thanks for your input.
I can see that it is just another thing that requires a workaround for the system to operate efficiently.
As I said in a previous post my workaround was to reverse the entry and exits from and to the coalmine. this has solved the problem.
I like to run my routes with a lot of freight trains in a despatcher type role.
This one has 13 100 hopper coal consists, with 1 being emitted from a portal every 30 mins,1 50 hopper coal consist supplying a powerstation, and 1 40 tankcar consist emitted from a portal every 45 mins.
So you see it can get quite busy.
The AI drivers cope well with a few minor hiccups every so often.
I thank all who have tried to help, just another learning experience..
cheers,
Mike