[steamer_ctn]

I am trying to get an activity running which requires the attachment of a bank (helper) locomotive, and then for the bank locomotive to "drop off" once it reaches the summit of the hill.

I am using the Join / Split function, but not having much luck at the moment despite studying the manual and the original "AI Extended Shunting" thread.

I tried to study the example activities, but I can't unpack them at the moment, as MSTS is not working seamlessly on my OS (Win 8). AE is working and I can create activities, but not unpack them.

So firstly is it possible for somebody to translate the activities into a zip file, in their normal folder structure? I understand that RR can do this quickly and easily.

Secondly I am assuming that the only option that is mandatory for this function to work is the "Extended AI train shunting" feature. I have this ticked and am able to use "timed absolute waiting" points, so this feature is working for me.

My join scenario has the player train arriving at a signal and waiting for the bank locomotive to attach. I have inserted a WP 60001 in the Bank locomotive path (always within the same track section).

Depending upon where this WP is located I get different results:
i) If the WP is a reasonable distance from the train, it appears that the banker slows down at the waiting point, and then speeds up to run through the train.
ii) If the WP is under the player train, it stops about 20m behind the player train and its mode changes into FOL, but it then sits behind the train and does not couple

Can somebody confirm where the wait point needs to be placed for successful operation? And are there any other pitfalls that I might have fallen into?

I am able to provide more info if needed.

Thanks

[Csantucci]

Hi Peter,
attached you have a .zip file with 7 join and split activities for routes USA1 and USA2. They are the ones published in this thread plus a new one, where both train sections reverse on two different paths after split.
 joinsplitacts.zip (33.75K)
Number of downloads: 233
Referring to your problems: case ii is OK, because the helper must reach the 60001 WP before coupling; case i is bad, and it would be nice to get more info from you (route? activity? screenshot with dispatcher info hud before train melting).
In parallel I suggest you to put the WP in a track section preceding the one where the coupling occurs. In fact for the 60001 WP there is no rule requiring that it must be in the same track section where the join occurs; on the contrary, practice shows that the contrary is better. Instead where the decoupling occurs (in the split phase) WPs should be in the same track section, although I have lowered this requirement.
I hope this starts to help you.

[scottb613]

Hi Peter,

Yeah - don't know if looking at complex activity files with helper service would assist but here is one I made and works like a champ - it's for a payware route (Cumberland) so you probably don't have it... The "Helper" performs complex switching activities both before and after its time in service as a helper... I didn't see it mentioned - but I believe the "Helper" path has to mirror the path of the the train it is helping - while it is coupled to come back to life after uncoupling at the top of the hill...

The only time I still see one train run through another train is when I am using Time Compression - - - I make sure I switch back tom 1:1 well before the events or strange things do happen...


 SCO-CMBL-ACT02-8.zip (14.96K)
Number of downloads: 234

PS: Carlos - you're a genius in my book - thanks for all you do...
:bigboss:


Regards,
Scott

[steamer_ctn]

Hi Carlo,

Thanks for the feedback.

Csantucci, on 13 June 2015 - 01:50 AM, said:

attached you have a .zip file with 7 join and split activities for routes USA1 and USA2. They are the ones published in this thread plus a new one, where both train sections reverse on two different paths after split.

Thanks for that.

Csantucci, on 13 June 2015 - 01:50 AM, said:

Referring to your problems: case ii is OK, because the helper must reach the 60001 WP before coupling; case i is bad, and it would be nice to get more info from you (route? activity? screenshot with dispatcher info hud before train melting).

The route is the Great Zig Zag.

This route is designed to be a completely self contained route to generate some interest in train simulation in Australia. I am currently creating a number of activities to demonstrate the variety of operations over the Zig Zag.

In this particular activity, I am trying to demonstrate how long trains were moved through the Zig Zag. It will ultimately require two joins and splits (I am hoping that this is possible).

I have attached a test activity with just the player service and the bank (helper) locomotive set for the first join split. (The downloaded route has all the rolling stock included in it). Please note that the activity will not be able to be edited in AE. Use track viewer to change the paths as appropriate. In this activity the join wait point is approximately halfway along the train.

Csantucci, on 13 June 2015 - 01:50 AM, said:

In parallel I suggest you to put the WP in a track section preceding the one where the coupling occurs. In fact for the 60001 WP there is no rule requiring that it must be in the same track section where the join occurs; on the contrary, practice shows that the contrary is better. Instead where the decoupling occurs (in the split phase) WPs should be in the same track section, although I have lowered this requirement.

I have moved the wait point to the proceeding track section (between the point and the reversing point), and it appears to now couple with the player service.

By moving the wait point it appears that different outcomes will be achieved.

So as a rule, are you suggesting that it should always be in the preceding track section?

I have used autopilot (which is a great aid in testing, so thanks for creating it) and the fast clock, so I am assuming that this will not contribute any errors to the train operation in regard to join and split.

Second Challenge - Wait Points

The other challenge that I am facing is that I use absolute WPs to control the signalling operation. So for example I use WPs to hold signals at stop for the player service until the timetable departure time is reached. The player service currently has a WP to hold the signal in front of it at stop until after the banker is attached. The WP works if the banker does not attach. However, it appears to not work if the banker attaches (ie the signal does not clear at the correct time). I think that the manual says something about not using WP with "incorporated" trains. Does this mean that WPs cannot be used to control the combined player and banker service? If so, are there any other options to control the players train movements?

Thanks for your help.

Attached File(s)

•  bank_test.zip (8.67K)
  Number of downloads: 183

[Csantucci]

Hi Peter,
I tested your activity. I inserted the 60001 WP of the helper before its 16:34 WP and the helper coupled. So keep the rule that the 60001 WP must be inserted in a section before the one where coupling occurs (any one section before). When I will have time, I will check why there are problems when the WP is put in the same section where coupling occurs.
Referring to the two WPs of the player train, I distanced them a bit more (about 15 meters more) from the signals, and so the player train and its coupled helper started at the desired hour. When I will have a bit of time, I will tell you what the limit is and I will check why there is a limit (I believe I had removed it).
Attached you have the two modified paths.
 PATHS.zip (3.71K)
Number of downloads: 175
As a rule, WPs work the same on a normal train and on a train with a joint helper.

[steamer_ctn]

Hi Carlo,

Thanks for the updated paths, joining now appears to work.

I am having a problem with the split now.

The scenario is as follows, when the train gets to Bottom Points, the player should split the train in half (behind wagon 19) manually using the uncoupling window (F9). The front half of the train should then proceed to the top of the Zig Zag, just past the Top Points. It will then be held at a signal.

The second half of the train (including the bank locomotive) should then proceed to Top Points as well, and the train should then join up again.

The issue is that when I try to manually try to split the train, the first time that I click on the coupling between car 19 and 20, the bank locomotive is uncoupled from the rear of the train, rather then splitting the train in half. Clicking on the coupling again seems to put the second half of the train into bank mode, and thus the second half will not move.

I have attached an udpate of the activity todate.

When you have a chance could you please review the attached activity and give me any thoughts on how to correct the problem?

Thanks

Attached File(s)

•  bank_test_2.zip (9.01K)
  Number of downloads: 207

[Csantucci]

Peter,
to me the split works. This is how I proceeded (but it should be not the only way to do it): arrived up to the closed signal before Bottom Points in autopilot mode. Passed to player driven mode. Waited until the signal became green. Opened F9 and uncoupled between cars 19 and 20. Passed to autopilot mode. The first half of the train moved, reversed, started running upwards, arrived to the second reverse point, reversed, and stopped before the red signal as foreseen. The helper part moved, arrived to the first reverse point, reversed, and then stopped in front of the signal before the second reverse point. There is a reason for that. The first half of the train is too long and still occupies the switch at its back, and so the signal for the second part does not clear. See picture. It should be easy for you to solve this by reducing the train length.
By the way: a great application of join and split!

[steamer_ctn]

Hi Carlo,

Csantucci, on 15 June 2015 - 06:56 AM, said:

to me the split works.

Thanks for checking this. I am struggling to get the train to uncouple cleanly in the F9 menu (the train seems to split into a number of different parts). I will persevere to try and work out how to get it to work.

Csantucci, on 15 June 2015 - 06:56 AM, said:

The helper part moved, arrived to the first reverse point, reversed, and then stopped in front of the signal before the second reverse point. There is a reason for that. The first half of the train is too long and still occupies the switch at its back, and so the signal for the second part does not clear. See picture. It should be easy for you to solve this by reducing the train length.

Thanks, I will have a look at this.

Csantucci, on 15 June 2015 - 06:56 AM, said:

By the way: a great application of join and split!

This route has a number of interesting operations.

[steamer_ctn]

Hi Carlo,

Csantucci, on 15 June 2015 - 06:56 AM, said:

to me the split works.

I think that there is a problem, and I think that your screenshot supports it.

I followed the procedure outlined in your post. It appears that the bank locomotive tender is uncoupled whilst the bank locomotive remains coupled. If you look at the screenshot in your post the bank locomotive appears to be missing its tender, note the bright orange fire that normally won't be as visible if the tender was in place.

Can you please rerun the tests as follows:

i) Uncouple between wagon 19 & 20 and see if the tender is uncoupled?

ii) Try uncoupling between say wagon 17 & 18 - what results do you get? I find that it just uncouples the bank locomotive and tender.

Thanks

[Csantucci]

Hi Peter,
your activity is a severe test for activity running under OR, and helped me finding out and solving a first bug (the one that got your player train stuck at the signals with your original paths). I have uploaded release 3167 and now trains don't get stuck at red signals if there is a WP near the signal. If the WP is laid down near the signal, OR lets now the WP take place at clearing distance from the signal, and at WP expiration the signal regularly opens.

In the meantime I noticed the train splitting in three (instead of two) parts too, and now I will start examining this second bug.