PDA

View Full Version : Problem with Couple At Trackmark command



ttownsend
June 2nd, 2012, 10:44 AM
Hello!

I'm having a problem using the 'Couple at Trackmark' command in TS 2012, although I'm not certain the problem is specific to that version. It's likely just 'user error'. Here's what's happening.

In the beginning of my session, a rather long freight train is emitted from a portal and heads into a switchyard. It navigates to a specific track and stops. After waiting 20 seconds, it decouples from its last 18 cars and moves forward into the next signal block, leaving the 18-car consist by itself. The very last car in that consist is positioned directly over a trackmark. This triggers a switcher engine (using the 'Couple at Trackmark' command) to approach from behind and couple to the end of the consist (with the intent of pulling it away in the opposite direction and onto another track). Here's what actually happens though.

When given the 'Couple at Trackmark' command, the switcher engine navigates to the correct track and as it approaches the target trackmark, it briefly stops and then slowly proceeds towards the consist to which it's supposed to couple. This is where the problem occurs ... it makes contact with the consist, but never stops. Instead, it just starts pushing the consist forward, right through the danger signal into the next block, eventually making contact with the end of the train from which it was uncoupled earlier. But wait ... it still doesn't stop. It continues to push the entire freight train forward onto the mainline and from there "into eternity', never stopping and still indicating that it's executing the 'Couple at Trackmark' command. I of course have to abort the session at that point.

I've tried making various adjustments ... adding/removing signals, imposing slower speed limits, moving the trackmark in relationship to where the 18th car is positioned, and even instructing the switcher engine to first navigate a few signal blocks away from the switch yard before issuing the 'Couple at Trackmark' command. The results are the same every time.

My session includes other coupling operations which are successful, but they all involve consists that exist at the beginning of the session as opposed to being emitted from a portal, and thus I can use the standard 'Couple' command for those.

I'm assuming the error is mine and that I just don't fully understand how the 'Couple at Trackmark' command should be used. Any thoughts or advice would be appreciated.

Thanks.

- Tom

llebrez
June 2nd, 2012, 12:05 PM
Well, welcome to the surprise alley. I have experienced pretty much the same thing. I came to the conclusion that trains expelled by the magic tunnels are not the same as the ones that you start the session. I have also experienced your problem if you save the session and tomorrow you continue it, at that point trains may miss triggers, not couple properly or ignore wait for XX time. I hope someone has more inputs on these subjects

Deano5
June 2nd, 2012, 12:51 PM
Ah, a fake AI, not a real AI. Try putting the consist in the session and not from the fake AI maker and see what happens. Just add the train from your saved consist list and plonk it down just outside the portal, give it the same command list then watch. ;)

ttownsend
June 2nd, 2012, 01:37 PM
Thanks for the replies! I had a feeling that it could be related to the fact that it's a portal-emitted train. I guess I'm going to have to do a bit reworking here. Unfortunately, the freight train in question is *not* the first train out of the portal, so it seems I'll have to create a different staging track. Too bad, it sort of ruins the illusion that the train has come from some other place. But I understand what's going on.

Thanks.

Dermmy
June 2nd, 2012, 04:55 PM
Try 'Couple to Vehicle Facing Trackmark', I find that one almost bombproof whereas 'Couple at Trackmark' often let me down. The only 'trick' is that the trackmark has to be right way around, the pointy end must face towards the consist. The consist can be anywhere beyond the trackmark, no need to get anything positioned 'exactly over'....

Andy

ttownsend
June 3rd, 2012, 08:15 AM
Thanks. I'm not aware of 'Couple to Vehicle Facing Trackmark'. I don't seem to have it, and I can't find it on the DS. But I'll keep looking.

trev999
June 3rd, 2012, 01:38 PM
The proper name is CoupleToVFacingTrackmark <kuid:131986:210015> build 2.0

You will find it if you search in CM for CoupleTo.

Trevor

ttownsend
June 9th, 2012, 10:25 AM
Hi Again Folks!

First of all, thanks to all of the replies. The people on this board are great. I'm posting again because now, a week later and after trying the various suggestions posted above, I'm still experiencing the same problem.

The first thing I did was to take Deano5's suggestion. I abandonded the use of the portal and created a staging track on which the full consist is parked at the beginning of the session. In other words, no 'fake' AI trains. Unfortunately, the behavior is the same. After the large freight consist decouples its last 18 cars and proceeds forward into the next signal block, the switcher enginer comes up from behind, momentarily stops, moves forward and makes contact with the previously decoupled cars ... and then proceeds to push them right through the signal block, never stopping.

Now that I was working with a 'real' AI train instead of a portal-emitted train, I figured I'd just go back to using the Couple command, which allows me to specify the exact car to which the switcher should couple. Unfortunately, I get the same results ... the switcher enginer just pushes and never really couples. (This is odd, because the couple command is working perfectly in earlier parts of the session.)

Next, I tried Dermmy's suggestion by using the 'CoupleToVFacingTrackmark' command. Interestingly, that didn't work at all. When the driver schedule reaches that particular command, the switcher engine just stops where it is and nothing more happens. The schedule just hangs at that one point. The only way to make the schedule continue is to drag the 'CoupleToVFacingTrackmark' command out of the sequence, at which point the schedule proceeds normally with the next command in line.

So, I'm still stuck, unable to get the switcher engine to couple to those 'abandoned' cars. The only difference I can see between that part of the session and the earlier parts in which the Couple command works fine is that in this case, those cars started off as part of a different consist and were decoupled. In the other cases, the cars to which the switcher attaches are already decoupled and parked on a siding. Well, that's the only difference I can see at the moment.

Regardless, it's not the end of the world here, but if anyone has any other suggestions or thoughts, that would be appreciated.

Thanks.

- Tom

jjanmarine3
June 10th, 2012, 12:15 AM
Have a look at 'vehicle physics' in 'edit session' , perhaps you have a problem with the 'coupler masks' feature and the said couplers are locked.

Deano5
June 10th, 2012, 03:04 AM
Have you got any direction markers in the area?
Check all track joints to make sure you don't have a break that you just can't see.
Check that all junctions have a lever.
What signals have you used in this area and are they set up correctly so they don't confuse the AI?
Are all your track ends properly signaled?
These are all little things that can make an AI get confused and do silly things. :wave:

ttownsend
June 10th, 2012, 08:50 AM
Thanks for the replies.

I'm not familiar with 'vehicle physics' (now's a good time to learn). It certainly sounds like something worth looking into. As for Deano5's additional suggestions, I have no direction markers, the track joints appear intact, and I'm not missing any junction levers. However, I'm going to go back and take a better look at the signalling. The switch yard is mostly signal-free, with only a few dwarfs on the outbound. The signal I've referred to above (when I say that the freight moves into the next signal block) is one that I placed in an attempt to correct this problem. (It obviously had no affect.) Regardless, it could very well be signalling issues.

I guess I have a bit of 'homework' to do. Thanks again for the suggestions.

- Tom