[GTADon]

Thank you for the information. I am going to put it to good use.

The Activity M30131 is still mystifying me in that the first meet goes off without a hitch, but the rest will not function. From the information I am seeing from others they are having similar issues running Bala v2 in OR in reguards to AI trains.

I am at best a lower intermediate at all this Sim stuff, I am just breaking into repainting some simple items with Photoshop (not as easy as it looks!).

I really thought that a new route with new (relatively) programming would work fine in OR. The route itself is spectacular and the correctness of the buildings is first rate, a lot of hours went into producing this route.

Please don't take this the wrong way, but some of the fine Activity Builders here should be able to figure out a way of allowing these AIs in the activities to be where they are supposed to be without rewriting the whole scenario. I will keep plugging along and backing up everything is something I learned from experience. I have read that tutorial and keep it handy at all times, sometimes I just get ahead of myself.lol

[GTADon]

Thank you for the information. I am going to put it to good use.

The Activity M30131 is still mystifying me in that the first meet goes off without a hitch, but the rest will not function. From the information I am seeing from others they are having similar issues running Bala v2 in OR in reguards to AI trains.

I am at best a lower intermediate at all this Sim stuff, I am just breaking into repainting some simple items with Photoshop (not as easy as it looks!).

I really thought that a new route with new (relatively) programming would work fine in OR. The route itself is spectacular and the correctness of the buildings is first rate, a lot of hours went into producing this route.

Please don't take this the wrong way, but some of the fine Activity Builders here should be able to figure out a way of allowing these AIs in the activities to be where they are supposed to be without rewriting the whole scenario. I will keep plugging along and backing up everything is something I learned from experience. I have read that tutorial and keep it handy at all times, sometimes I just get ahead of myself.lol

[R H Steele]

Don, do try running the activity playback function in the AE. Watch the AI trains. It may provide a clue why the AI's after the first one get stuck. Could be a signal is triggered red and does not clear. Will keep watching this thread. MLT has a policy of no download if your purchase is coming by mail --- so I wait.

[GTADon]

Just as a note, I downloaded the new activities by Bob Pickering for BNSF Seligman 2.0. I am having meets with the AIs in the correct places. Either SLI's route authors and/or Bob have the correct coding for the Activities to function correctly in OR as well as MSTS.

So, there does not seem to be a problem with MSTS/OR install if other Routes and Activities function with the AIs. Maybe something to do with the placement or timing which was mentioned elsewhere in this post as a possible culprit.

Right now I am enjoying Seligman again for the time being, then back to work on Bala 2.0.

[railguy]

The Activity Editor in MSTS is pretty clunky in some regards. Over the years, to get around that, activity builders have developed a number of "tricks" to make an activity work. The OR dispatch logic is somewhat different than MSTS, and, from what I can see, usually works better most of the time. But, there are a couple of those MSTS "tricks" that may break an activity in OR because of that different behavior. Whether or not that is the problem with the Bala activity discussed here, I don't know, but it could be.

Here is an example of a couple of those tricks and how they can foul up in OR. This activity I built for the MLT Soldier Summit route and is based on a real life situation that some of my railroader friends encountered when working that route. The route is double-tracked with crossovers at several points and a center siding accessible from both ends from both mains at Gilluly. In the real life incident, an eastbound train broke a knuckle on the EB main between switches at Gilluly. The second EB train (my player train in the activity) was switched over to the westbound main at the next crossovers west of Gilluly and ran east "wrong main" to the east switch at Gilluly, stopping there so the crew could assist the EB train with the broken knuckle. Meanwhile, a hy-rail truck ran westbound down the westbound main to the east switch at Gilluly, taking the center siding there and stopping across from the knuckle break on the EB train. After its arrival, the EB crew on the player train could get on board and proceed east. After some time, the "broken knuckle" train would depart Gilluly behind the EB player train and follow it to Helper where it would eventually overtake the player train in the yard.

So, here is how I made the thing work in MSTS. The "broken knuckle" AI train I set up to run on a path to about a quarter of a mile west of the east switch at Gilluly. There I placed a waiting point with a long wait time--say, 2 hours. Beyond that, I placed a "double reverse point"--two reverse points very close together--just west of the east signal at Gilluly. Then I ran the path to Helper and east on the main, setting another waiting point of about 5 minutes at the depot. The AI broken knuckle train's path then continued east on the main for another 10 miles or so to its end point. Here is the MSTS waiting point/double reverse point trick. In MSTS, the train stops where the waiting point is set and, well, waits until the waiting point time elapses. Beyond the waiting point is the double reverse point. A double reverse point interrupts the train's path until the train passes over it, thus the MSTS AI dispatcher will give opposing trains a green signal. Because the EB train was stopped by the waiting point, it can't reach the double reverse point to "trip" the AI dispatcher to resume its path and get a green signal. With me so far?

OK, for the player train, I set its path to crossover onto the westbound main west of Gilluly, and set a double reverse point for it just west of the east signal on the westbound main at Gilluly. Because my player train won't trip the double reverse point until it's ready to leave Gilluly, it gets a red signal at the east switch. Meanwhile the westbound hy-rail truck is pathed down the WB main to the center siding at Gilluly, where I set a very long waiting point (like 4 hours) for it right across from the broken knuckle train. After the hy-rails wait time has expired, it continues west for a few hundred yards to the end point of its path on the center siding. As for the player train path, it continues east from Gilluly, crossing over to the EB main at Summit, thence proceeding to Helper where it switches onto a siding in the yard. I set the end point of its path well east of where I will stop the train on the siding, but the end point is placed before the train would get back on the main track. Still with me?

So, how does it play out in MSTS from the player train perspective? Well, the player train proceeds east with the AI broken knuckle train ahead of it. When the broken knuckle train reaches its waiting point, it stops. I continue EB on the player train, encountering approach signals and a crossover onto the WB main below Gilluly. I get approach signals coming into Gilluly, with a red signal at the east switch. I stop at the knuckle break on the EB train. After awhile, the WB hy-rail truck trundles down the WB main, enters the center Gilluly siding and stops right across from where I'm stopped. I "get back on" my EB train and begin to slowly move eastward toward the red signal. When I pass over the double reverse points, I get a green signal and can proceed east. I cross over onto the EB main at Summit and proceed east to Helper, where I enter the siding. I go get a cup of coffee for an hour or so. When I get back, it isn't long before the "repaired" EB broken knuckle train pulls into the depot on the main and stops for a crew change. After about 5 minutes, it proceeds east. That ends the activity. Yes, it does all work in MSTS.

Now, here is why this activity won't currently work in OR. OR, regrettably, doesn't handle waiting points like MSTS. When a train encounters a waiting point in OR, it doesn't stop until the next signal. First, in my activity, that isn't where I wanted that broken knuckle train to stop. More importantly, it means that AI broken knuckle train will pass over the double reverse points west of that east signal and will get a green signal. I'm not even sure that the double reverse point functions the same in OR as MSTS, but the waiting point disparity would have already broken this activity.

The point of this is that I'm sure that the waiting point/double reverse point trick is used in a lot of MSTS activities. It has been a hot topic of discussion for years and I learned about it from those discussions several years ago. I don't have a clue how the OR dispatcher could choreograph an activity such as what I just described. Maybe the OR developers can shed some light on that.

[Buttercup]

These threads may help.


http://www.elvastowe...__fromsearch__1

http://www.elvastowe...__fromsearch__1

[roeter]

For starters, COMPATIBLE is NOT the same as EQUAL.
Compatible means files can be read and processed correctly etc., but there may be (and will often be) differences in the way things are run. This is partly inevitable as the exact MSTS logic is not known, partly deliberate to get rid of some of the MSTS troublespots, and partly because some things just proved a bit to difficult to implement in a similar way.

For the example detailed above, there are two specific items : waiting point and (double) reversing point.

Waiting points differ in that trains do not stop at that location as such, but at the end of the 'section' (delimited by switch or signal). The reason for this is that train-control is based on these sections. It was difficult enough to get the AI train to stop at the correct location at the end of a section - to stop it at an unmarked position somewhere along a section was just one problem too much.
Waiting points also differ in that, unlike to what happens in MSTS, any signal ahead of the train will be kept at danger until the wait time is over.

Reversing point processing differs from the processing in MSTS quite deliberately. The most striking difference is that the location of the actual reverse marker is not important, but the location of the 'diverging point' (that is where inbound and outbound route diverge) is leading. As soon as the train is clear of this point (or clear of the first signal controlling it), reversion is applied when the train stops - regardless of whether it actually passed the reverser marker.
Problem with double reversing points is that there is no diverging point. But, those points are ofcourse never intended to actually reverse the train, only as a 'trick' to stop the signal ahead from clearing. So, OR recognises this 'trick' and interprets this as a 'break' in the train's route, and not as a reversal.

And here is where things go wrong. The 'break' in the route due to the double reversal point overrules the signal hold for the waiting point. So, the 'trick' used in MSTS to keep the signal from clearing actually negates the proper way in which OR would have processed the waiting point.

So, for OR you would have to remove the double reversing point - the train will not wait at the waiting point itself but it will wait at the next signal.

Regards,
Rob Roeterdink

[GTADon]

These scenarios are very interesting in that the explanation for the processing of information by OR and MSTS are different and seem to be quite dependent upon which style the writer of the Activity chooses. This would explain why certain Activities work and some don't. The bit about the "double reversing point" seems to explain the issue with the AI trains in the new Bala.

The timing is such that neither train should actually be stopped waiting, allowing of course that the Player Train keeps to a very tight schedule and both do a rolling pass at the sidings. In the AE the movement is all but nonstop, no waiting, but while in the Sim, acceleration, brake release etc all have a hand in delaying the player train.

What Rob said makes sense, just let the train go to the next signal and behave correctly. What do the "DRPs" look like in AE? Are they the green slash "/" or one of the circles or one of the red shapes?

Thank you for some clarification. While running Seligman 2, all the meets so far are rolling passes, OR seems to work well when that happens.

[markus_GE]

I assume with DRPs you mean doble reversing points. These look just like two times a normal reversing point: A little circular arrow placed on the track. To remove reversing points from a path, however, you will either have to manually edit the .pat file, or completely relay the path, since it´s not possible to remove a reversal point in the MSTS Path editor (at least AFAIK). On manually editing the .pat file, I also don´t have any clue what to do... sorry.

Cheers, Markus

[roeter]

It is not necessary to rebuild the full route - but it will be required to rebuild the route from the double reversing point onward. Placing an "End of Path" just before these points, and then removing this again, will clear them.
As for manually changing the path file : DON'T !! You've more than 99.9% chance of ending up with a 'broken path', or invalid path-file. Syntax and complexity of the path file are simply horid.

Regards,
Rob Roeterdink