[KiwiPeter]

Thanks for the clarification. As my version doesn't have the shunting check box I'm downloading the nightly version now.

Another curious thing I noticed: as I appraoched Shunter 3 that had stopped on the track parallel to the one it took off from there was a backpacker standing on the track between the two locos. As he refused to move when I blew the horn I ran through him. As soon as I did that the shunter started to move towards me. It seems it had stopped because of the person on the track.

When I tried to reverse the emergency brakes came on, status Splipped. What does that mean?

Thanks,
Peter.

[KiwiPeter]

It works, great stuff.

A couple of notes:

The coupling is a little rough. My loco indicates wheel slip from the bump.

Once the Shunter 3 duo has coupled up to the player the reversers are in N, but the wheels keep turning on both of them.

Thanks for creating this. I think we can have a lot of fun with this.

Cheers,
Peter.

PS: I have run over the same backpacker again in almost the same spot.

[Csantucci]

Hi Peter and others,
thanks for appreciation.
Yes, it's true that coupling is rough. I will have also a look at wheels, it should easy to stop them turning.
Refinements have to be introduced...

[Csantucci]

Here a description on how to proceed to create activities using this option.

Here some indications on how to design the activity.

First of all, it is not desired that AI trains couple to other trains in case they were designed to run separately, and only because of e.g. timing problems. So, coupling is activated only if some conditions are met.
The first condition is that there are no facing signals between coupling AI train and coupled train, when the coupling train path linking the two trains has no reverse points in between (reverse point under the coupled train excluded, see further down). Such facing signals are, as standard in this case, red. There is not (yet) a request for permission as there is for the player train.
Coupling with static consist is not subject to other conditions, as if the activity designer decided that the path would lead an AI train up to against a static consist, he also wanted that the AI train coupled.
Coupling with another AI train or with the player train is subject to following conditions, that is
1) either coupling happens in the last path section of the coupling AI train, and the path end point is under the coupled train or beyond in same section
2) or coupling happens in the last section before a reverse point of the coupling AI train, and reverse point is under the coupled train or beyond in same section.
This way undesired couplings are avoided in case the AI train has his path running in same direction beyond the coupled train.

Just after coupling there is another check to define what happens.
In case the coupled train is static:
1) If there is at least one reverse point further in the path or if there are more than 5 track sections further in the path, the coupling train couples with the static train, and then the so formed train restarts following the path of the coupling train
2) if not, the coupling train couples with the static train and becomes part of the static train itself (is absorbed by it), stopping movement.

In case the coupled train is a player train or an AI train:
1) if there is at least one reverse point further in the path, the coupling train couples with the coupled train, leaves to it all the cars between its loco and the coupled train, decouples and moves further in its own path (it can only reverse due to above conditions). The coupled train follows its own path.
2) if not, the coupling train couples with the coupled train and becomes part of it (is absorbed by it). The coupled train follows its own path.

Now on how to design paths:
1) if one wants that the coupling train is absorbed by the coupled train: simply put the end point of the path of the coupling train below the coupled train
2) if one wants that the coupling train moves further on in its path after having coupled with the coupled train: put in the path of the coupling train a reverse point below the coupled train. If one wants also that the coupling train does not immediately restart, but that it makes a pause, a waiting point has to be added in the path of the coupling train , subsequently to the reverse point. Such waiting point has to be put below the coupled train if this is a static consist, and below what remains of the coupling train just after having coupled with the coupled train, in case the latter is an AI train; in this case the position of the WP can be a bit difficult to be determined, because in the standard case what remains of the coupling train after coupling/decoupling is only the loco.
If the coupled train is an AI train, obviously it must be stopped on a waiting point when it has to be coupled by the coupling train.

I hope that these explanations together with the study of the demo activity are sufficient to proceed creating activities.

[mauried]

Great explanation.
Just one question.
Is it possible for an AI train consisting of loco and cars , to simply uncouple the cars from the loco and leave them as a static consist
but the loco continues on as the AI train by itself, and can then pick other cars as per the demo.

[Csantucci]

Hi Mauried,
this is not possible in this moment, because in this case an explicit indication must be set in the path to perform the action. However I hope to add this function in a not so far future.


There are instead good news referring to the red signal issue. At least in a case I was able to develop an activity where the red signal can be put to approach by the dispatcher monitor (no news up to here) and the shunting AI train passes such signal and performs its task as required (the news).
A new demo activity is attached here, that is equal to the previous one, with the very one difference of the red signal. This concerns Shunter1a. A pop-up window appears indicating to the player to switch the signal to approach with the dispatcher monitor.
 Show2_AI_shunting.zip (5.83K)
Number of downloads: 372

As usually there are signals in the shunting area, this is good news. However maybe there are cases where even switching the signal the activity does not perform as desired. This has to be investigated further.

This new demo activity does not modify the previous one, that remains available and working as it previously was.

[mauried]

I built a complex shunting activity with signals involved, and the problem thats most likley occurring is because all the original MSTS signals have a block check as part of the condition of allowing the signal to clear.
All that needed is to edit the sigscr script for the offending signal , and / or slightly modify the route.

Heres a typical example in the sigscr script.
----------------------------------------------------------
If required, show the appropriate 'stop' indication.
if (!enabled || // Not enabled/cleared to show natural state?
block_state() !=# BLOCK_CLEAR || // Block ahead not clear?
!route_set()) // Switch not set as per link?
{
state = SIGASP_STOP;
}
-----------------------------------------------------------
This is the usual way of determining whether to clear a signal or not and this line here
block_state() !=# BLOCK_CLEAR is what prevents the signal from clearing if the track ahead is occupied, which is the case if there is a consist or an AI / Player train ahead.

If this line is removed or commented out ,the script now functions as
If the signal is not enabled or the route is not set , show red,
or conversly if the route is set and the signal is enabled show something other than red.
I simply picked a dwarf shunting signal ,removed the block check and placed it at the entrance to any yards where AI shunting will occur.

In MSTS , block checking was important as AI trains would crash into each other if they ended up in the same block, but as OR wont allow crashes like this , its not so important.

[Csantucci]

mauried,
I'm happy you are trying the new functionality.
Referring to your precious contribution, I think that with time OR could provide the facilities to distinguish when a train does "train" movements and when it does shunting movements, having each one different signals with different logic to follow.
Maybe you remember that, if you want to have co-existing sigscr and sigcfg files for MSTS and OR, you simply have to create an Openrails folder within your route folder, and you can put the OR version of sigscr and sigcfg in such folder. OR would take the files from such folder, while MSTS will continue taking the files from the root folder of the route.

In the meantime with release 2580 I have added a further AI shunting functionality. Now an AI train that couples itself with another AI train or player train, and has its loco that directly couples with the coupled train, can "steal" all wagons (loco excluded) from the coupled train and run away.
This can be seen in following demo activity for route USA1:
 Passivecoupling4_AI_ruba.zip (3K)
Number of downloads: 383
At about 12:2:0 the Dash9 couples to the waiting AI train, and at about 12:2:20 the dash9 reverses with the cars of the waiting train, that is so shrinked to the single loco. Here the situation just after restart of the two AI trains:


This way for an AI train coupling to another AI train or to the player train there are three possibilities:
1) if its path finishes under the coupled AI train, it merges with the coupled AI train
2) if its path has a reverse point under the coupled AI train, there are two possibilities:
2a) if its coupling trainset is a car, it will "donate" to the coupled train all its own cars up to its own loco (excluded)
2b) if its coupling trainset is a loco, it will "steal" from the coupled train all its car up to its loco (excluded).

[Csantucci]

With release 2585 I have reduced AI coupling speed down to about 1.5 Km/h, starting from 8 meters distance from train to be coupled. Now coupling is quite softer. The change has not been inserted for timetable mode by the moment.
As activity timings are a bit delayed this way, I re-uploaded the two show activities of this thread, correcting their timings.

[railguy]

The AI shunting function sounds like a very wonderful addition to OR. When I get some free time (at a premium at the moment), I want to try some things with it. Here is one thing that I would like to try, but I don't know from what has been explained if it is possible. I would like to have an AI train pull to a stop in the yard, bring my helper locos out of a siding, couple up to the AI train, then help it to the summit of the grade, uncouple from the AI train, then have it (after a minute or two) continue on its way. Would that be possible? Thanks.