[railguy]

Some background--I'm using Experimental version R134. Here is the issue that I found. I was testing a new and somewhat lengthy (4 hours+) activity that I created. I wanted to test how a meet would occur several hours into the activity. So, what I did was to start the activity, then switch from the player train to a static locomotive in view of the location of the meet. Once there, I used time acceleration to "chew up" about 2 hours or so of the activity to get to the time of the meet. Then, just ahead of the meet, I switched back to real time. I watched the meet take place. After that, I switched from the static locomotive back to the Player train. Every thing looked good, but then I realized that the physics of the Player train were compromised. Opening the throttle or going into dynamic braking caused immediate uncontrolled wheelslip. I tried saving the activity, then restarting it from the save, but the problems persisted. Apparently, the time acceleration caused data issues. I've checked the log files, and there were no error messages indicating any abnormal issues. Later, I restarted the activity from the beginning, and everything ran normally.

This, in my mind, compromises one of the main benefits of time acceleration--being able to "fast forward" in an activity to check behavior of meets, etc. without having to run the activity at the real time speed to reach that time point. My guess is the all the data processing needed to run the activity in accelerated time corrupts the data somehow. Please note that the activity I was running was on the Surfliner 2-3 Route, a particularly large and complex route.

Has anyone else run into this issue? Any thoughts would be appreciated. Thanks.

[Weter]

With ORTS I work mostly with TimeTables.
I do use time acceleration for checking these 24-hours long "activities", but I initially chose stationary locomotive in siding, which has very short path towards dead end - this won't cause any interference to the rest of traffic. This way I check how large station "works" and tune timetables as needed for right result. I define needed time of start for that special train for not to wait too long, when I'm sure, that everything's alright, or nothing important is happening before. (i.e. from mignight to specified time)
I also did use time acceleration, while exploring lengthy and plain routes, as I've no enough of time last year.

In both cases, as You can see, I didn't jump in former AI trains (which are acting using simple behavior with minimal physics model) TT mode even have no ability to switch player control between trains - you only control that one, You've selected initially.

Hence, I see Your issue not in time acceleration mostly, but in inability to recover to "normal" physics model usage after reassignment control to primary train.
Please, tell me, if You try to drive secondary train, used as "observer", does the same wheelslip occur, or it rolls alright?

[railguy]

Weter,

The stationary locomotive that I switched to was just that, a stationary locomotive that I did not move. I can see how this might be an issue in switching trains during an activity, though I have not experienced this issue before. That stationary locomotive is a model that I have run in other activities without problem.

Maybe it would be a nice option in OR to be able to put the player train in autopilot, then "jump" the camera view to a location on the route of the player's choice--sort of an "observer" mode. That way, the view would not be tied to a specific train, but rather to a place.

[eric from trainsim]

I've run into the uncontrollable wheelslip issue as well after time acceleration. It's usually when I go >500% and then things figuratively run off the rails.

And yeah, why did train jumping in timetable go away? I loved that feature...

[Weter]

@eolesen
As I understand, there never where neither train jumping, nor deliberate coupling/uncoupling (only actions, ore-defined in timetable)
Robert have said in manual, that's different logic, in compare with explore/activity mode.
@railguy
I understand, that You:
- Sure, the model, chosen for static train is OK
- didn't try to move it in that activity (but indeed that experiment would show the form of an issue)
- didn't check, how jumping + acceleration influences on other trains driving ability.

Press 8 key and Youll get two free cameras, press 8 more, for getting one more, press shift-8 to cycle your existing free cameras then, and shift them&tune them as You need. Jump to other train's locations to set other free cameras there, for not to fly too far. But I suspect, returning to control of player train while turning AP off would cause same result: AP as rest AI skips physics.

[Csantucci]

Railguy,
what locomotive is causing the problem? Can it be downloaded somewhere? Does that occur also with other locomotives? What occurs if you perform the same procedure, but don't accelerate time? Of course for this test you can switch back to the initial player locomotive before its train arrives where the static consist is.

[eric from trainsim]

@weter it's been a few versions since I used it, but prior to v1.4 we could jump between active trains in Timetable. Whether it was intentional or accidentally enabled and now disabled, I do not know.

[Weter]

Hello.
Switching views (2,3,4,5,6 cameras) is possible, taking control - not.
Since 2017, as I use ORTS.