[Csantucci]

Only the first part is possible. Your AI helpers can couple to the AI train and help it to the summit, but you can't uncouple them.
If they are player helpers, they can couple to the AI train and help it to the summit, they can uncouple and return back, but the AI train won't move further from the summit.
In other words a train can't be split in two different moving trains.

[alexmorph3us]

How about the scenario where you put a waiting point greater than 40.000 seconds that allows the AI to uncouple from the front of the train.Does this method still work?

[Csantucci]

alexmorph3us, on 25 October 2014 - 12:30 AM, said:

How about the scenario where you put a waiting point greater than 40.000 seconds that allows the AI to uncouple from the front of the train.Does this method still work?

That function has been cancelled a while ago. I'm thinking to reintroduce it.

[alexmorph3us]

I am mentioning it because this way it might work for an AI train to split in two and both continue in separate ways each with it's own engine.The original manual says that a value of 4NNSS is required where NN represents the number of cars you want to be uncoupled and SS the time after which an AI loco will move again.I think it's worth reintroducing it :)

[Csantucci]

Even reintroducing the option, after the split only the not-uncoupled part can continue on its path; the uncoupled part becomes a static consist and can't continue (it hasn't a path).

[alexmorph3us]

Csantucci, on 25 October 2014 - 08:24 AM, said:

Even reintroducing the option, after the split only the not-uncoupled part can continue on its path; the uncoupled part becomes a static consist and can't continue (it hasn't a path).

I was thinking at a scenario where a train arrives at a station and needs to leave some of its cars to a second engine with it's own path that will couple from behind and steal the number of cars needed to continue on another track let's say one that's not electrified.Together with Extended AI Shunting option this will open up possibilities to create activities with more complex AI movements at terminus stations for example.

[markus_GE]

Pls consider this as some sort of predecessor to an idea, á la just thinking aloud.

Waiting points are specific to a path, which is usually specific to one train in an activity, especially when used to trick AI trains into something special. That said, maybe waiting points could - now that ORTS is getting its own very good path editor - be expanded, to work as something like "action points". Add various possibilities to them, what could be done there. Say, setting them up works like the event management for MSTS location events. You choose how many things should happen, if triggered, and define the type of each such "sub-event". Say, for example, first I want my train to stop for 45 seconds, then to apply handbrakes on cars 13, 14 and 15, uncouple between car 12 and 13 (after car 12) and then proceed after another 100 second wait.

Would something like that be possible? (Before even calling this an idea :) )

Cheers, Markus

[mauried]

With the current AI shunting capabilities, I really cant think of much else thats needed, other than the ability for an AI train to uncouple cars
and leave them as a static consist.
The original idea of long waiting point times(>40000) seems a simple fix if it can be easily done.

[Csantucci]

There are of course thousands of shunting possibilities in real world, but I too think, as Mauried, that the ability for an AI train to uncouple a configurable number of cars is somehow the missing brick.
So, if there aren't strong objections against that and if I won't have problems, I will try to implement this as it was already originally foreseen in OR (see actual lines 412 to 414 of AIpath.cs, that I attach here):

                // Uncouple if a wait=stop point
                // waitTimeS (in decimal notation) = 4NNSS (uncouple NN cars, wait SS seconds)
                //                                or 5NNSS (uncouple NN cars, keep rear, wait SS seconds)

In a first phase, this would be possible only for an isolated AI train. In a second phase this could become possible also after a coupling of an AI train with another AI train or player train or static consist.

That won't be a fast thing.

[markus_GE]

That was more or less what I was thinking about, only that the definition of what the train should do could be made a little bit less numerical. More work to be done that way, of course, and it will require a standalone ORTS Activity editor. Thus, I know it can´t be implemented at the time, but maybe it´s something to think about.

Cheers, Markus