[bristle]

Not sure if this is the right area to post this topic in?

I have an activity for Europe2 route (Innsbruck to St Anton) where the player train stops to collect AI helper locomotives at Zams to help the train up the oncoming hill.

Player train departs from Innsbruck and eventually stops just a bit past Zams to allow AI helper locomotives to couple to player train. Then the entire new consist arrangement continues on up the hill to St Anton where the activity ends.

The problem is to get the timing right so the AI helper locomotives only move to couple to player train when the player train has stopped at or near a certain location just past Zams. The actual coupling part (of AI helper locomotives to rear of player train) is no issue, just use a wait point with a value of 60001 in the player (and AI helpers) path just a bit before the rear of player train.

It appears that there has to be some sort of "test" to check that the player train has stopped in about the right location (just past Zams) and then enable AI helpers to move to couple to the rear of player train.

Using set (waiting) times for the AI helpers before their movement will not work, as there is no guarantee that the player train will be in position and stopped to receive the AI helpers. Player train could be late, with the helpers already gone after waiting time expired. And the player train could be early and would have to wait for awhile before AI helpers move; but there is a problem with this last option!

If the AI helpers "appear" (in Zams siding) before player train reaches Zams area, then the AI helpers will have priority over player train, even if the AI helpers have a waiting time before movement. The signal prior to Zams will stop/block player train from advancing and switches/signals will be set up for the AI helpers only. So the player train can't proceed to the coupling location just a bit past Zams!

So how to set up this activity to work properly please!?

That is -

player train should have priority and be able to advance and stop at the intended coupling location regardless of AI helpers "appearance" and waiting time

AI helpers will only move to couple to player train when player train is at the correct location and has stopped

Anyone?

Screenshot of Zams area taken from MSTS Activity Editor which may be of help is enclosed also.

 Zams_helpers_annotated.jpg (58.39K)
Number of downloads: 2

[scottb613]

Hi Folks,

Welcome aboard.
:)

Looks like the correct place for the post to me.

Also curious how you do a meet with an "AI Helper" when the arrival time of the player train is uncertain.

Regards,
Scott

[railguy]

I have yet to personally try this option, but you might read Section 10.16.10 in the OpenRails Manual--"AI train Waiting Point modification through event". It would seem that this might solve the problem described above.

[scottb613]

railguy, on 07 January 2022 - 06:04 AM, said:

I have yet to personally try this option, but you might read Section 10.16.10 in the OpenRails Manual--"AI train Waiting Point modification through event". It would seem that this might solve the problem described above.

Hi...

Looks like the answer - like you - I haven't tried this.

It's a shame we have no way to incorporate it into a tool that builds activities.

While for me - editing text files like this is no big deal once I figure it out - MOST will probably not delve this deep.

I'll have to give this a try when I get some time.

Thanks...

Regards,
Scott

[bristle]

Thanks for the comments, so far.

I have had a look at Open Rails manual and the relevant section with regard to my activity does appear to be section 10.16.10.

Although there is a "sample" extension act file, it is still not clear what specific arguments should be used in my activity. Also what other "commands" should be used and with what arguments and where should they be placed (if applicable)?

The issue of giving priority to player train to enable it to get to the AI helper coupling location without delay just past Zams siding (regardless of when the AI helpers "appear" at the siding) is still not clear however. Should the AI helpers "appear" at the siding before player train is near Zams, and as it is at present, priority seems to be given to the AI helpers, and the player train will have a stop signal at the signal about one and half miles before Zams! So some means must be made to override this so that the player train has priority until it reaches the coupling location.

So what to do?

[Weter]

If one use drawad key for TS editors&tools shortcut, he will be able to see, how signals work.
About train's priority suppression, I've seen some articles in Russian. If you are free to use translators, I can share you the link.
http://zaborin.ru/msts/mstso/?id=14
http://zaborin.ru/msts/mstso/?id=15
http://zaborin.ru/msts/sovet/

[bristle]

Thanks for the links Weter!

I'm looking at the link content at the moment.

[bristle]

I have had a look at the links mentioned previously. But I am still not clear about how to setup the activity so that when the player train reaches a certain location and stops, then the AI helper train moves to couple to the player train.

There has to be some event (AI helper train moves) activated when player train stops at predefined location. There has to be some sort of logic test for this, surely!?

So how to set this up? What commands are required?

Or, is it impossible for this scenario (AI train moves to couple when player train stops at location) to be presently done due to limitations of Open Rails??

[R H Steele]

It's all about the specialized waiting points used for the extended shunting function....it has been a while since I've made an activity using them...but I'll try. First off...when you use either the MSTS AE ( which--again I haven't used in a while ) or the Trackviewer that comes with OR when you place a waiting point you can use a special waiting point to define train behavior.
[Note---if I remember correctly when using the MSTS-AE you actually had to enter the specified format such as 41015 or whatever, you do not have to do this using the trackviewer...again it has a couple of years actually since I've built a complex path.]

From section 10.13 Extended AI Train Shunting:

Quote

The format of this waiting point (in decimal notation) is usually 4NNSS, where NN is the number of cars in front of the AI train that are NOT uncoupled, locomotive included, and SS is the duration of the waiting point in seconds.
The 5NNSS format is also accepted. In this case the remaining AI train is formed by NN cars (locomotives included) starting from the rear of the train. Of course there must be at least one locomotive in this part of the train.

...and from another paragraph, same section, applies to player train:

Quote

Manual decoupling (for player trains) occurs using the F9 window; automatic decoupling occurs with the 4NNSS and 5NNSS commands (see previous paragraph); the first one has to be used when the part to be decoupled is at the rear of the train, and the second one where the part is at the front of the train.

You'll have to read and study this section in the manual and use the learn how to use the trackviewer...see screenshot below of trackviewer waiting point window...this is where the special waiting points are entered in the path.

One More Item: you should take the time to read through this thread, it has ALL the information about extended shunting when Carlo first coded it...Extended Shunting

Attached File(s)

•  bandicam 2022-01-28 08-23-45-019.jpg (252.43K)
  Number of downloads: 0

[bristle]

Thanks for your detailed reply, Gerry!

Yes, I have had a look through the linked forum topic, I have also used Trackviewer for activities, and I've downloaded some sample activities and ran them and examined their activities using MSTS Activity Editor and Trackviewer.

Unfortunately, despite all of this above, the activities all seem to be based on times, and not on train location and train status (running or stopped).

I believe for my activity to work, there has to be a conditional test for the player train to be stopped at or near a certain location, and only then allow the AI helpers to move forward to couple to the back of the player train.

I don't believe there is an option under both MSTS AE and Trackviewer that carries out a test for (player) train location before enabling another event to be performed.

My activity can't be time based as it is impossible to predict the arrival time of the player train at a certain location as this depends on how fast the player train is driven.

In summary, this activity appears to require a conditional test to determine when the player train has stopped at or near a specific location. This activity can't be time based.

[R H Steele]

So a player train location event that would fit into the enhanced shunting special waiting points scheme? Hmmm...maybe you should bump the Extended Shunting thread with a suggestion? Reference this thread.