[markus_GE]

Didn´t know the end of path trick. :) for mentioning it, Rob.

Yeah, I know it´s a very difficult feat to try and manually edit a path file. Done it once and never again. That´s why I posted I have no clue about it :)

Cheers, Markus

[railguy]

Thanks to Rob for the explanation of how OR looks at waiting points and double reverse points. I am going to reiterate here, though, that not being able to have an AI train stop at point besides a signal or a siding switch and/or be able to be programmed by the activity designer to stop for some programmed time at a certain point is a MAJOR flaw in being able to create realistic activities in OR. In real railroading, things delay trains, unscheduled stops have to be made, breakdowns occur--all of which an activity designer should be able to "create" for AI trains. Does creating such a delay cause delays for other trains, etc.? Absolutely! That is the reality of railroading.

One of the things that I'm going to try in OR (which can't be readily done in MSTS) is to deliberately degrade the performance of an AI train running in front of me (that can be manually done in the AI train's consist file) and then see if my player train will overtake it at a siding when both trains on running on the same path, with passing paths set for both.

[Buttercup]

I have had some success removing double reverse points in the activity editor by marking them as "broken" and then reselecting them to remove them. You should only save the path after removing both reverse points. Doesn't always work so have a back up.

[roeter]

 railguy, on 18 January 2014 - 06:41 AM, said:

One of the things that I'm going to try in OR (which can't be readily done in MSTS) is to deliberately degrade the performance of an AI train running in front of me (that can be manually done in the AI train's consist file) and then see if my player train will overtake it at a siding when both trains on running on the same path, with passing paths set for both.

Well, you may try, but I can tell you straight away that it won't happen - you will be stuck behind.
The reason is quite simple : passing paths are only used for passing opposite traffic. Without opposite traffic, both trains will just follow the main path. And even with opposite traffic, trains will only stop for opposite trains and not for trains following behind.

It's also not very easy to work out : catching up with a train ahead doesn't mean it is necessary or usefull to overtake. It may be that the train ahead is just going through a low speed section, and once through it will run away from you again as you yourself now need to go through that low speed section. So apart from checking the train's speed it would also be needed to check on line speed over the sections ahead and estimate if passing is usefull. Such logic is not implemented.

You can ofcourse put it all on the wish-list. Work is still going on so who knows what will come out of the magician's head.

Regards,
Rob Roeterdink

[railguy]

Rob,

One way to accomplish the same effect of a waiting point for purposes of, say, delaying an AI train, might be to make the waiting point effectively take the AI train to manual switch operation until the waiting point elapses. If I understand the OR logic correctly, if one takes the player train to manual switch operation it essentially "interrupts" its path until automatic switch operation is restored--allowing both following and opposing trains to overtake or pass it if the player train is not fouling their path. Why couldn't this same logic be used for an AI train? Use the waiting point to interrupt its path and allow other traffic (including the player train) to overtake or meet it until the wait time elapses, then allow automatic switch operation to restore for the AI train.

As for stopping a train at a specified point with a waiting point, I'm not sure why that would be so complicated. The train stops and the signals for it and the AI traffic hold as they are--no different than if I stop a player train somewhere out on the line. Does this "stab" (US railroad slang for delay) other traffic? Yes, it does. Again, that is prototypical.

As I mentioned earlier, being a train dispatcher in real life, albeit on an unsignalled railroad, I have to deal with all kinds of these scenarios all the time.

[roeter]

I think you misunderstood some things here.

A waitingpoint will indeed 'break' the path for an AI train, and signals ahead will be held, and the train stopped for as long was indicated.
The only thing is that the train waits at the next node or signal following from the waitingpoint marker, and not at the waitingpoint marker itself. That has to do with the logic which makes an AI train stop at a required point - that logic is completely linked to the 'track circuit sections'.

The fact that it did not work in the example above was due to the combination of waiting point and double reversing point.

By the way, this 'breaking' of the path has one rather troublesome side effect at the moment : it creates problems with the deadlock processing, for deadlock 'traps' are not set beyond the waiting point because of this break. That is something which one day will have to change.

Regards,
Rob Roeterdink

[railguy]

I understand that the train will wait at the next signal, but that doesn't solve the issue if one wants the train to wait at something rather than at a signal or switch--for example, in the middle of the main train between signals.

Another question, I was just running another activity (not designed by me) in OR. In the activity, an AI train plowed right through the middle of a loose consist placed on its path. I assume that the AI train probably was not supposed to be there until after the loose consist was moved, probably because the AI train was supposed to wait with something (waiting point or double-reverse point).

Are we to assume that OR does not recognize loose consists placed in the path of an AI train? And, can we also assume that is true if AI dispatcher routes trains onto an optional passing path onto another track occupied by a loose consist?

Also, was the "fix" discussed a couple of weeks ago implemented in the X1944 release to have the OR dispatcher choreograph meets when one or both player and/or AI train is too long for a siding, or is that still a work in progress?

Where I'm heading with these questions is that I'm about to start designing some OR-specific activities to take advantage of what OR can (or, sometimes, can not) do.

Thanks.

[roeter]

An AI train should not run through a static consist. If that happens, something's gone wrong.
If it happened in a yard, one possibility is that either the AI or the static consist is on the wrong track, due to a known error in the path processing. Just yesterday someone provided a patch for that problem which is now under test.

The problem with too long trains trying to pass is also still under test. That version (which will be launched as experimental option) will contain much more changes to the way 'passing paths' are used.

If all goes well both these updates should be ready to be released sometime next week. But I need to test these quite extensive changes in a number of different routes and scenario's and that all takes time.

A bit of 'preview' to what the new passing path processing will provide :

• Passing paths defined for the player train will automatically be available to all trains, in both directions.
  
• AI trains can have different passing paths defined, these will only be available to that particular train.
  This means that multiple passing paths can be defined per location, but there are certain restrictions on what can be done.
  
• Length of trains will be taken into consideration in the process which works out where trains can pass.
  Passing is only possible if at least one train fits into the shortest available path.

Admittedly this new code has as yet only be tested on signalled routes, I can not yet garantuee it will also work on unsignalled routes - that still has to be verified.

Regards,
Rob Roeterdink

[GTADon]

Based on this information, would it then be advisable to make a new activity based on the published one, except in a form that OR understands?

I have completed one of the activities in OR for Seligman 2.0 by Bob Pickering, all of the meets and AIs performed properly including an end of activity message.

[R H Steele]

 GTADon, on 18 January 2014 - 05:16 PM, said:

Based on this information, would it then be advisable to make a new activity based on the published one, except in a form that OR understands?

I would Don, no harm in doing so. Eventually when the development team begins work on an AE designed for Open Rails all these activity problems will become academic. To my mind they already are. Sure, some problems point to "real" bugs, but usually the team is aware of them, no harm in reporting I suppose. The best way (at least for me also the most fun) is to work the activity and run it in Open Rails until you are satisfied with it. Just copy all relevant files/folders first and go for it. Learn the MSTS Acitivity Editor (and all it's strangeness) make new paths, make traffic, try out posted tricks (good one in this thread about the double reverse), read Rob Roterdinks posts - will help considerably in understanding signalling. I'm sure you'll be pleasantly surprised what Open Rails will do. I have some activities by Bob Pickering, and I am sure he has no magic playbook to make activities work in Open Rails - just considerably more experience than you or I in MSTS. Use all the tools currently available and see which provide information you can use. What had helped me was to run the same activity in MSTS and then Open Rails, noting differences, and not assuming they were bugs in Open Rails.