[railguy]

I have successfully coupled a player train to a stopped AI train in OR. It's tricky but can be done. One can also do it in "MSTS Binned" MSTS, but it is a very hit and miss proposition there--fairly often the sim will just crash. I've designed activities, for example, where an AI train passes as set of player locomotives sitting on a siding, then stops with a waiting point. Then, I take the switches to manual operation, take the player locomotives out of the siding and up to the AI train, then couple up to it. The rub is that the sim has to stay in manual switch operation from then on because it thinks that the player train is now off path. But one can shove the combination of player locomotives and AI train up the hill. I don't see OR being able to have an AI train independently execute switching moves on its own, but executing something like a saw-by should be doable in a multi-player session.


As for the "saw-by" that I described, I really wasn't looking for OR to be able to accommodate it in a single-player session--a saw-by is just a way that short sidings are handled in real railroading. Even if it were possible in the sim, accomplishing one with adherence to real railroading rules for brake tests, etc. could take a couple of hours to accomplish.

I'm going to re-write my activity and see if I can "trick" the AI dispatcher into holding my player train at a siding long enough to meet its long opposing train--essentially replicating what I did by taking the switches to manual operation and holding my player train at that siding to make the meet. If I can do that, it will make things workable.

[roeter]

One way to solve this, for now, is to create paths which are adjusted to the length of the AI train by simply not setting alternative paths for those sidings which are not long enough. This will mean different paths for different lenghts of train, and will obviously only work if trains stay the same length throughout.
It may be possible (in the long term) to make this automatic, i.e. that passing path definitions are ignored if the siding is not long enough to hold the train.

Regards,
Rob Roeterdink

[markus_GE]

I think, that would be exactly the solution that has been asked for :lol2:

Cheers, Markus

[roeter]

railguy, on 25 December 2013 - 01:54 PM, said:

I've been playing around with activities for Northwest Route V6--my activity on the signaled single track Canadian Pacific portion. My player train is an 85 car westbound manifest that meets a bunch of eastbound trains, some long and some short. My AI Dispatcher buddy--I call him "Hal"--isn't very bright about meets where the siding is too short for either train, though. If I set up the activity with optional passing paths at the sidings, good ol' Hal will set up a meet at one of the sidings, even though neither train will fit between switches. Hal should hold one or the other opposing trains at a siding where at least one train will fit, so that the meet will be successful. If I do this manually--by taking the player train out of automatic switches--I can pull the meet off at a longer siding without an issue.

I still like the OR dispatching system way better than MSTS, but this is one "quirk" that probably merits some attention. Thanks.

Could you please try the attached experimental version?
It's been a fairly extensive change to the deadlock processing so I have not yet committed these changes, so your help in testing would be very welcome.

File :  RunActivity_testPL.zip (601.62K)
Number of downloads: 191

Regards,
Rob Roeterdink

[railguy]

Rob,

I'll try testing the RunActivity.exe . My only concern is that I've been using the RunActivityLAA to get extra memory. I don't know how well the activity will run if your .exe isn't LAA. I'll give it a shot, though.

Thanks for all the hard work that all of you do. To echo what others have said, the great thing about the OR team is that they actually look at and act on suggestions or issues.

[railguy]

Well, the results are interesting. Unfortunately, I did not get to completely finish the activity because, as I suspected, OR ran out of memory without the extended RunActivityLAA.exe . AI trains starting showing up with missing textures and about 3/4 of the way through the activity OR crashed.

Let me explain the activity. I have an 85 car long westbound train that meets 8 eastbound trains of varying length during the activity. Only a few sidings along the player path have enough length to meet a the player train with a couple of the long AI trains. All the AI trains use the same path--set up with passing points at some but not all sidings and no optional path sections. The player train is set up with passing points and optional passing paths at some but not all sidings.

Well, the good news is that Hal (the AI Dispatcher) set up the meets of the long player train and the long AI trains at the sidings where they could successfully pass each other. Here is the REALLY interesting thing, though. I had to go back to the Activity Editor to check this for sure, but I confirmed it. Even with all the AI trains having the same path--with no optional path sections--a shorter faster eastbound AI train overtook and passed a longer slower eastbound AI train that was ahead of it. I wasn't watching the Dispatcher HUD closely enough to see this happen, but it obviously did. Rob, you apparently wised up Hal a lot.

I may go back to a previous save and see if I can finish the activity without a crash. I don't think it will change my conclusions because the last 3 trains the player train had to meet were all short.

All in all, an exciting day with OR. What it does confirm, though, is running that amount of AI trains, especially long ones, requires the RunActivityLAA. Running with it, I haven't "choked" OR with missing textures or crashes, even on memory-intense routes like Horseshoe.

[roeter]

Quote

Well, the good news is that Hal (the AI Dispatcher) set up the meets of the long player train and the long AI trains at the sidings where they could successfully pass each other. Here is the REALLY interesting thing, though. I had to go back to the Activity Editor to check this for sure, but I confirmed it. Even with all the AI trains having the same path--with no optional path sections--a shorter faster eastbound AI train overtook and passed a longer slower eastbound AI train that was ahead of it. I wasn't watching the Dispatcher HUD closely enough to see this happen, but it obviously did. Rob, you apparently wised up Hal a lot.

The new definition of paths will allow trains to use optional paths at a location even if these paths are actually defined for the opposite train. So, in your case, the AI used the optional path as defined for the player train.
The plan is to take this further : the intention is to have optional paths (and yes, that can be multiple paths) defined per location rather than per train.

By the way : regarding the memory problem : if you encounter 'gray' wagons due to lack of memory, save and restart will likely restore the proper situation, and you might be able to finish the activity that way.

Regards,
Rob Roeterdink

[Csantucci]

Rob, what you're doing there is great! :good:

[railguy]

Rob,

I knew about the save and restart trick, but I wanted to run the activity without exiting if I could.

So, a question: With this new coding, for OR-specific activities, is it even necessary to specify optional paths for the AI trains, or just for the player train? If those optional paths are not necessary for the AI trains, it would save a lot of time in writing an activity. Also, does one have to (as recommended in MSTS) set the optional path sections before, between switches, and after the passing siding, or just between switches at the siding itself?

Here's another interesting thing that I mentioned in another post that I confirmed yesterday when I was experimenting. Apparently, OR does somehow randomize sunset times when one restarts an activity from a save. The activity that I was using yesterday starts just before sunset, the sun usually setting about 5 minutes into the activity. So, on one of my runs, the sun had set, the "dark" cab had turned on (and the streetlights) and had been on for about 10 minutes or so (approximately 15 minutes into the activity). I saved the activity, then started it from the save. When it loaded, the sun was still up and the day cab was still in "day" mode. About 5 minutes into the activity, the sun set. Interesting.

[roeter]

railguy, on 10 January 2014 - 07:01 AM, said:

So, a question: With this new coding, for OR-specific activities, is it even necessary to specify optional paths for the AI trains, or just for the player train? If those optional paths are not necessary for the AI trains, it would save a lot of time in writing an activity.

I have not tried it yet, but it figures that indeed it will work that way.
However, you must make sure that both trains have the same MAIN path through the siding - if you accidently give the AI train the path through the siding which is the alternative path for the player train, and the player train does take the alternative path, you have created yourself a very nice deadlock.

Quote

Also, does one have to (as recommended in MSTS) set the optional path sections before, between switches, and after the passing siding, or just between switches at the siding itself?

You've lost me here. The only way to set up an alternative path (as far as I know) is to select "start passing path" in the MSTS path creator, and that can only be done on the starting switch of the path. The path creator automatically assigns the end of the path.

Regards,
Rob Roeterdink