moving starts in activities.

[gremlin1812]

G'day, does OpenRails handle moving starts in activities?
If so is it possible to change an activity from a standing start to a rolling start without using route editor, by editing the act file?
I am using route "3DTS Cajon Pass" activity "4449 Down Cajon"
I have also noticed that steam locos don't operate very well in OR (this is variable from loco to loco) it would seem that there may need to be some changes made to there files but still not up to speed with this yet.
I do realise that OR is still in development and this may have not been fully addressed yet, still trying to get a handle on where things are as it has been a while since last using MSTS/OpenRails.
Regards
Barrie

[R. Steele]

G'day, does OpenRails handle moving starts in activities?
If so is it possible to change an activity from a standing start to a rolling start without using route editor, by editing the act file?

Barrie, you're correct about the edits to make... one in the act file "starting speed" line, I cannot remember the units...someone will probably post the correct units.
Also in the player service file there is a StartingSpeed entry that needs an number.

Also do not forget to take a look at the Brake_Engine line in the player engine file. If there is a 1 in the last position player will start with loco brakes applied.

Brake_Engine ( 0 1 0.0125 0    [U]<<<last number needs to be a zero[/U]
                NumNotches ( 1
                    Notch( 0  1 Dummy )
                )
            )

[gremlin1812]

G'day Gerry, well done you were spot on with your answer, works a treat and it now means I have a fighting chance of beating that smelly old diesel.
Just to try and push the bounderies a bit I dont supose there is a way to make the train start in "autopilot" apart from hitting "alt-a" as soon as the activity starts.
Regards
Barrie


Edit:- StartingSpeed entry's do not require any units just the number, I think it defaults to the route/activity units.

[gremlin1812]

G'day, ran the activity to the end under autopilot, he did a great job and left that stinky diesel in a cloud of steam and smoke. Thanks for your help.
Regards
Barrie

[geepster775]

You can also adjust the start times of AI traffic by manually editing files. The start times are in both the ACT and TRF files, and both must be modified in unison. All the start time numbers are in seconds, and since 1 calendar day = 86,400 seconds, the start time value will be somewhere within 1 and 86,400, with 1 being 12:01 am and 86,400 being midnight the following day, and 34,200 being 12:00 pm noon. If you need to advance an AI arrival up by 3 minutes, then you just adjust the values downward by 180 (3x60)

If you get really adventurous, then you can add more AI traffic by adding lines to the ACT and TRF files, using either existing service definitions already used in the ACT (which repeats the AI consists) or by adding via copy/paste and modification a new .SRV file for each AI addition which allows you to choose another unused consist.

To test your timings, run the activity, place the player into autopilot, and advance the clock to around 1000% and run through a 6 hour act in about 10 minutes. Control + Alt + PageUp makes the clock and train position speed up and Control + Alt + PageDown makes it all slow down. Speed up in between the meet locations and slow it back down just before them to evaluate how the meets execute in normal time. I'm not sure if this works in situations where the player train is underpowered and cannot make track speed. When you are out of autopilot mode, tonnage, gradient, and gravity factors all seem to work at keeping you from making track speed, but in autopilot mode (a requirement to advance the clock), these underpowered player trains are known to defy tonnage, gradient, and gravity and keep closer to track speed, which makes the speedy test not accurately reflect a manual, non-autopilot run. Perhaps Gerry can confirm or deny that.

[R. Steele]

... I'm not sure if this works in situations where the player train is underpowered and cannot make track speed. When you are out of autopilot mode, tonnage, gradient, and gravity factors all seem to work at keeping you from making track speed, but in autopilot mode (a requirement to advance the clock), these underpowered player trains are known to defy tonnage, gradient, and gravity and keep closer to track speed, which makes the speedy test not accurately reflect a manual, non-autopilot run. Perhaps Gerry can confirm or deny that.

I do pretty much the same, also have observed that underpowered trains perform normally on autopilot, but I cannot maintain same speed outside of autopilot. So what I eventually do after numerous autopilot test runs to get the timing close is run the whole activity in real time to make sure that everything works well. Autopilot is a good tool to use, an imperfect one to be sure, but it does considerably help in testing activities.
After all that, you sure get tired of the activity.

[R. Steele]

...but in autopilot mode (a requirement to advance the clock)...

I think clock advancement is independent of autopilot. Manual section 7.11.1 Time of Day, however, the manual specifies Alt+PgUp and Alt+PgDn to alter time of day...which only changes the camera view position in certain views. Typo or incorrect entry in the Manual?

Using Ctrl+Alt+PgUp or Dn changes the Simulation Speed, according to the screen message. So Simulation Speed and Time of Day are linked, makes sense.

Geepster, didn't you start a thread about this...suggesting another way of time advancement?

[Vince]

I do pretty much the same, also have observed that underpowered trains perform normally on autopilot, but I cannot maintain same speed outside of autopilot. So what I eventually do after numerous autopilot test runs to get the timing close is run the whole activity in real time to make sure that everything works well. Autopilot is a good tool to use, an imperfect one to be sure, but it does considerably help in testing activities.
After all that, you sure get tired of the activity.

I've found after many, many runs with my see-if-it-breaks mega activity on the PRR east w/80+ AI trains;
When in AutoPilot mode, the meets and player overtaking traffic all take place at almost exactly the same time!
There are over 50 AI/Player interactions between NYP and PHIL alone so AP mode plays the sane every time.

And yes, OR has exactly zero problems running this kludge, that btw, takes thirteen ( 13 ) minutes to load! This is loading off a dedicated SSHD. ( not the C:\ ) i5QuadCore 8Gig, gtx650.
This is what sold me on OR ... big time!
Just to know, the activity crashes ( ctd ) MSTS, with, of course, no hint of what caused the crash. <evil grin>

regards and Happy New Year.