[mauried]

One minor additional feature regarding AI trains and coupling would be worth considering, and thats what to do with an AI train gets to the end
of its path, ie when it hits its end point.
Currently, the AI train just dissappears which is what happens in MSTS.
It would be helpful if another option was available, which is instead of the AI train just dissappearing, it simply stopped and became a static consist, which could then be picked up later by other trains.
Using the methodology of waiting point times similar to the idea behind the 40000+ concept for AI train uncoupling, could a similar idea work for something like this.
ie place a waiting point of 50000+ just before the AI trains end point , to indicate that its not to dissappear, and to become a static consist.
Is this sort of thing easily implementable.
Thanks

[Csantucci]

With release 2615 Extended AI Train Shunting has been upgraded by introducing the possibility to AI trains of uncoupling any number of cars.
As always this option works if the related checkbox in the Experimental Options is selected, and only if also Enhanced compatibility with MSTS activities is selected.
To have all info together, already available and new functions are here described and demonstrated.
Resuming all that is possible now:
Already available:
1) AI train can couple to static consist and can remain alive, that is it can restart and go on in its path;
2) AI train can couple to other AI train or to player train, with three possibilities:
2a) coupling AI train melts with the other AI train
2b) Coupling AI train cars pass to the other AI train, and coupling AI loco(s) revert(s) and go(es) on in its path; this happens if the coupling train has cars between its loco and the coupled AI train.
2c) Coupling AI train steals all cars to the other AI train, and reverts and goes on in its path; this happens if the coupling AI train couples directly with its loco to the coupled AI train.
New:
3) AI train can uncouple any number of cars, that become a static consist. With the same function it is also possible to couple to a static consist and to get only a part of it.

A demo for this behavior is available in this upgraded packaged and zipped USA2 activity, that uses only standard trainsets
 Show_AI_shunting_enh.zip (8.05K)
Number of downloads: 364

It is the same demo that was already shown, with the addition of the new functionalities in the second part of it.
It is suggested to use camera 8, F7 to see train names, dispatch monitor and to accelerate a bit time to see things run faster (press three times CTRL-ALT-9(NUM)).
Again the suggested view:


PS: In order to get the activity working correctly, file us2bnsfcar.wag within the folder of same name has to be replaced with the attached one: the original one has an error that prevents the car from being shown in recent releases of OR.
 us2bnsfcar.wag (5.02K)
Number of downloads: 338

Following can be seen in activity (new parts in bold):

12:2:33 Shunter1 couples loose consist and restarts
12:3:01 Shunter2 couples loose consist and restarts
12:5:13 Shunter1 couples to AI train and leaves to it the cars
and restarts
12:5:49 Shunter2 couples second loose consist and restarts
12:6:50 AI train starts with cars coupled by Shunter1
12:7:27 Shunter1 couples to loose consist and later restarts
12:9:18 Shunter2 couples to player, leaves to it the cars and restarts
12:11:50 A long AI train arrives. It has a defect first tank car near the end of the train. It uncouples the tank cars and proceeds few meters further.
12:12:17 Shunter2 couples with Shunter3, and melts with it
12:12:45 Shunter5 moves to couple the 5 tank cars
12:12:50 (about) Shunter3 restarts together with coupled former Shunter2
12:14:35 Shunter3+former Shunter2 couple to player.
12:14:40 Shunter5 couples the 5 tank cars, in order to leave the defect one in a siding.
12:15:59 A short passenger train arrives. A loco runround takes place (loco is uncoupled, moves around train and couples at the other side)
12:17:48 Shunter 5 leaves the defect tank car, and returns the other 4 to the long AI train.
12:19:23 Passenger train restarts in opposite direction.
12:20:50 The 4 tank cars are returned to the long AI train. Shunter5 returns to the defect one.
12:23:12 Long AI train restarts without defect car.
12:23:32 Shunter5 couples to the defect tank car.


The activity has been designed with the MSTS Activity editor.

How to implement the already available features was described in post #14 of this thread.
Here short instructions on how to implement the new feature are given.
To uncouple a predefined number of cars from an AI train, a waiting point has to be inserted.
The format of the waiting point (in decimal notation) is 4NNWW, where NN is the number of cars in front of the AI train that are NOT uncoupled, loco included, and WW is the duration of the waiting point in seconds. It must be noted that "front" of the AI train is the part which is in front of the train in the actual direction. So, if the consist has been created with the loco at first place, the loco will be at the front up to the first reverse point. At that point, "front" will become the last car and so on.
Following possibilities arise:
1) AI train proceeds and stops with loco at the front, and wants to uncouple and proceed in the same direction: a WP is inserted where the AI train will stop, with the above format, counting cars starting from the loco.
2) AI train proceeds with loco at the rear, and wants to uncouple and proceed in reverse direction: a reverse point has to be put in the point where the train will stop, and a WP has to be put sequentially after the reverse point, somewhere under the part of the train that will remain with the train, formatted as above. As the train has changed direction at the reverse point, again cars are counted starting from the loco.
3) AI loco proceeds and couples to a loose consist, and wants to get only a part of it: a reverse point is inserted under the loose consist, and a WP is inserted sequentially after the reverse point, somewhere under the part of the train that will remain with the train, formatted as above.

What is NOT possible as of now is to couple the AI train to the player train or to another AI train, and to "steal" to it a predefined number of cars. With the already available functions it is possible to steal only all cars or to pass all cars. If it is desired that only a certain amount of cars is passed from an AI or player train to the other, the first AI train has to uncouple such as described above in point 1, has to move a bit forward, and then the second AI train couples to those cars, as it is shown in the demo activity with the tank cars.

[mauried]

Fantastic.
This covers just about all AI shunting scenerios I can think of.
I had to move very slightly one reverse point for AI shunter5 where it first couples onto the oil cars
as it was reversing slightly too early, but worked fine afterwards.
Really makes this Sim worthwhile now.

[Csantucci]

Nicolò Lovato has created a short video about a small activity using one AI shunting functionality.
It shows the shunting in Verona Porta Nuova related to the Eurocity 85 Munich-Bologna. In such station the train changes direction, and changes loco too.
As what happens is not completely clear from the video, here a small legend:
0:0 The train enters station arriving from the Brenner.
0:24 The new loco starts from a siding.
1:52 The new loco couples to the stopped train at its former rear side.
1:53 The old loco from the other side leaves the train and runs to a siding.
3:00 The train restarts in opposite direction and with new loco.
Youtubevideo

In the meantime a new feature is under way, which had been available for some time in OR: the possibility of defining absolute time of days in waiting points (some code lines for that are still there in AIpath.cs). Under the extended AI shunting flag and provided that timetable mode is not active, waiting points with waiting time >=30000 and <40000 are interpreted as 3HHMM, where HH and MM are hours and minutes in decimal notation. If the time of day had already passed when the train arrives to the waiting point, the waiting point delay is set to 1 second.
This feature can be useful to better schedule meets and takeovers, as well as to schedule trains stopping outside platforms (e.g. stopping in sidings).

[cjakeman]

Csantucci, on 04 November 2014 - 03:20 AM, said:

waiting time >=30000 and <40000 are interpreted as 3HHMM, where HH and MM are hours and minutes in decimal notation.

I've not looked into "waiting time" but encoding time of day like this doesn't seem right. Isn't there a better way?

[Csantucci]

Hi Chris, it depends on how it is decoded and transformed into the internal OR format. If this happens correctly nothing is wrong. If you look at AIpath.cs, where the original code was maintained, you see how it is decoded.
The advantage of coding it this way is that the activity developer does not have to make calculations to insert the time he wants into the waiting point parameter.
Moreover with four digits you arrive only at 9999, which is nevertheless less than the number of seconds in a day. So you can't have a higher definition than the minute.

[Genma Saotome]

I think it is quite clever to get this working with the existing AE.

Further down the road, when OR has its own AE, would there be any advantage to developing such complex behavior by the AI train by simply running the same train at that location, and then making use of the commands in the replay file?

[Genma Saotome]

A misunderstanding... I was asking whether there would be any advantage for the activity designer to run a train (as his own) and then take the commands from the replay file and use them for an AI train in an activity. The reply commands would provide a perfect record of the movements, throttle, brakes, coupling and uncoupling.

Seems if it were feasible then anything could be done w/ Ai trains... it would only take the activity designer to run a train for that purpose.

Perhaps not for everything... that would take a lot of time, but for a lot of switching it might be useful.

Just a thought.

[Csantucci]

Thanks Dave.
Your suggestion is attracting, and in fact as far as I know this technique is used in robotics.
In the specific case, however, there is a problem as of now: the saved commands are tagged only with time, but not with position: as it happens that e.g. braking has not the same effect during run and during replay, you end up with trains that do not stop where they should.

[cjakeman]

Csantucci, on 05 November 2014 - 06:41 AM, said:

Your suggestion is attracting, and in fact as far as I know this technique is used in robotics.
In the specific case, however, there is a problem as of now: the saved commands are tagged only with time, but not with position: as it happens that e.g. braking has not the same effect during run and during replay, you end up with trains that do not stop where they should.

You are right to say that Replay commands record changes to the driver's controls and so replay the opening of the throttle to the same setting at the same time. They don't record the position of the train at all.

However, we did some tests with a commuter train stopping and starting at a series of stations and were surprised at how repeatable the journey was, so maybe there is some potential in this. So, yes, an activity designer could drive a train and record the commands, then designate that train as an AI one and specify the file of commands to be replayed.

Currently the commands are stored in a binary format, though I did experiment with a text version so that the file could be edited.