No announcement yet.

EB Priority Z

First Prev Next Last
  • Filter
  • Time
  • Show
Clear All
new posts

    EB Priority Z

    Stock SLI activity with timings adjusted slightly and lots more AI added.

    Just out of Needles at 10AM with one of the NS heritage units third in line.

    Crossing the big bridge at Topock.

    Power catching its breath before the lengthy climb up to the Arizona Divide starts. With proper OR adjusted maxpower values, I am able to maintain 61-66 mph uphill with the lite train. Thats up from about 55-58 mph with the MSTS butchered values.

    Progress stopped at Yucca waiting on approaching traffic. Head end of opposing movement we are waiting on passes at 10:44:10

    Rear-most DPU clears the interlocking at 10:45:07

    Adding the effect of prototypical code line delay THAT OPEN RAILS DESPERATELY NEEDS, the combined effect of dispatcher actions and CTC transmission delays from Beehive Dispatcher Central out to remote East Desert Patch still has the signals red at 10:46:34

    The transmission delays finally over as the switches throw and signals clear at 10:46:36. Total code line delay of 00:01:29. I added a card over at the Trello roadmap site to add this code line delay feature to the program. Go vote for it so we can stop having to 'rig' activities to produce the realistic effect.

    Last edited by geepster775; 02-01-2017, 08:53 PM.
    My Open Rails videos


    On the move again at Yucca. Total delay was less than 5 minutes.

    Approaching Griffith

    Traffic jam at Griffith

    Overtaking two lower priority heading my way, and meeting one.

    Overtake, crossing over again, and threading the needle

    My Open Rails videos


      That's some great activity work on that later leg.
      Still something I need to educate myself on; making complex activities that mimic high traffic situations, such as your above example.

      Chicago Railroading Fan


        Very nice.


          Looks great have you or are you going to release this activity?


            Nice upgrade to a plain old activity.

            Regarding the signal delay, I agree that it is important to finally have it, but I disagree with having the code randomize the wait. I would prefer to have the activity creator define the signal delay at various points in the activity. If the system randomizes a delay, then you could have different outcomes for different users running the same activity, and that outcome could be the difference in the activity going off without a hitch, or failing from one user to the next, all driven by a random delay generated by the code. That would be bad. Let the activity creator decide whether the signal response delay should be a minute (a dispatcher on the ball), or 10 minutes (a dispatcher not on the ball), or 2 hours (an intentional wait handed out by the dispatcher), and not the programmer or algorithm. This difference would plant the fix for this delay 'feature' somewhere in a new activity editor, rather than in the bowels of the code. Even if they give us some new tags that can be manually inserted into an activity file, in the interim, while waiting for the new activity editor, that would be an improvement. As long as the activity creator knows how to insert the trigger, and the code knows how to respond to the manually inserted trigger and produce the delay, the trigger can pre-date any new editor.

            A great topic for discussion.