I have an activity that works without a problem in MSTS. But in OR the screen freezes and I can only get out of that by rebooting the computer. This occurs halfway through a shunting exercise. Can anyone see any possible causes mentioned in the log file attached?
Hi Chris,
I'm no expert, but can't see any reason why OR would freeze, however, have you corrected all the reported stock errors? I can only find a few items and the errors are genuine - Damping values should be n/m/s. blocker.eng also has the Damping error, but I can't see why the other errors are reported, unless OR doesn't like the line : MaxPower ( 1hp )
I can't check the Class 158 errors because I don't have it, but, other than the Damping error, I suspect that the other error in both vehicles is probably in the Description section at the end of the .eng file.
The message "Information: Empty consists for AI train - train removed" might be the reason for the freeze.
Hi Chris,
A new post because I was out of time to edit my last one!
I have now downloaded the Class 158 (158824), and found that each vehicle has errors in their 'Description' section; some lines are not preceded by a double-quotes and not followed by a double-quotes and + (only the last line of the whole description should NOT be terminated with +).
Thanks for your reply. Having now replayed this short activity many times, I am becoming convinced that the moment of freeze occurs at the instant of recoupling after running around a batch of wagons.
Before you spend any more time, Ged, let me let you in on a little secret. I created that activity in one of my few test activities already in existence. But I forgot it had existing traffic in another area at a different time! The Class 158 was part of that traffic. I have since deleted that trf file. But the traffic from that file is still showing up in the log file! So I want to see what is going on.
The unnecessary traffic was still in the act file, and I have now deleted all reference to any traffic. The attached log file will be a lot easier and quicker to read.
Hi Chris,
May I suggest that you correct the Damping parameters on the Class 37s and the HTA wagons and, probably more importantly, the Adheasion parameters on the HTA wagons? Although they shouldn't cause any problem, there are still a couple of errors in the Class 37 .sms files which it'd be better to correct.
I have corrected all the major physical Log problems. As I am ignorant of sound, I deleted the two sound lines (cab and eng) in both locos (a double header). The screen still freezes at recoupling. The Log file is attached.
A couple of times the locos stopped a few feet before touching the wagons and the screen froze even then.
Background: To repeat, MSTS has no problems with this activity at all, but OR does. The start of the original activity has the locos coupling to the wagons with a run around - passing the wagons then reversing onto them. No problems.
Down the track there is some more shunting where the screen freezes. I made an activity of just this area, and all the logs and discussion are of this activity.
I also made a very small activity of this area in which the locos drive up to the wagons which are parked where they would be when the screen freezes. Driving the locos straight up to the parked wagons, the locos couple to the wagons without any freezing, and away they go!!!
I do know that open rails calculates the pre-start position of loose consists a bit differently than MSTS does. There is one MSTS activity for Cascades Crossing that involves the train making a pre-departure pickup from the yard, with all 3 cuts of the pickup on the same yard track. All 3 cuts are separated by only a few meters. While the activity is completed in msts, it can never be completed in open rails because it detects a collision between two of them and drops one out to the extent the work order can never be completed. The fix is sliding the consists a bit farther apart.
The recent batch of Diesels West activities for Feather River were suffering from no-show loose consists when the user substituted out any missing payware stock they didnt have. It would appear some of the loose consists serving as pickups may have worked in the as-designed configuration, but the spurs were too full with little tolerance for changes in loose consist lengths via substitution, so OR failed to allow them to show if you performed the smallest bit of substitution for missing equipment. The fix was reducing the loose consist car counts to stay within tolerances.
I had a situation where I was placing an entire train as a loose consist to represent an outlawed train. The siding the train was supposed to be outlawed on had a switch node for a spur near the middle of the siding, and the train was destined to be draped over the switch node. If the head end of the loose consist was set on the frog side of the switch, it failed to show in game. If I wanted the dead train to point only one way, I had to build the entire train consist in reverse, with EOT at the head end and the road power on the rear, and then place the consist starting on the points side of the switch node, and drape the train over the switch in that direction to get it to show.
Anytime you experience odd unexplained differences in behavior involving loose consist pickups when compared to MSTS, wiggling the location of the loose consist or slightly changing the length of the pickup should be the first diagnostic step.
Thanks for your constructive comments which made me replay the activity and drop the wagons off at the far end of the siding instead of the near end. After dropping off the wagons and reentering the siding under Autopilot, the locos gradually slowed to a halt in the area where previously the wagons had been dropped off and the screen froze (event A). The wagons were maybe 100 yards further ahead.
I then replayed the activity and changed to manual mode on reentering the siding and so was able to drive through the spot where the Autopilot had stopped the locos. On recoupling to the wagons at their different position at the far end of the siding, the screen again froze.
I also tried disconnecting the wagons before even starting the activity and running the locos on their own along the player path. As expected no problems occurred. The locos reached the end of the path with no problem.
I then removed two wagons from the consist and replayed the above scenarios. I got the same results as with the full consist - including coming to a halt in Autopilot far from the wagons - as in event A above.
Does the attached image after the freeze with a hand held camera tell anybody anything?
Did something (windows upgrade-wise) hose your XNA or DotNet installations? Perhaps a refresh of those are needed?
Was the path originally built by MSTS AE or the OR TrackViewer?
Download the latest OR X version to your desktop, unzip it right there on your desktop, and run the open rails executable found in there and see if a separate, clean, parallel installation produces the same result.
Thank you for taking an interest in what could be my unique problem. All paths were created in MSTS. I've done nothing yet with XNA or DotNet. All the following comments are based on using the experimental exe.
The player behavior is the same as before. But I now believe that the freeze does not only occur on recoupling. It occurs whenever the player locos have zero forward speed. And this obviously occurs on completion of coupling. Not only must the forward speed be zero, but the player must be on the same track as the wagons, between the same nodes as the wagons, and approaching the recouple location.
When in the activity I stopped between all pairs of nodes around the player path, and the only freezing occurred when the player was between the same nodes as the parked wagons and approaching the recouple location. I also simulated the activity by playing it in explore mode with no problems.
I ran the activity with a different consist of a different loco and different wagons with the same problem result.
Interesting problem. Could you zip your activity, add a stock list and attach it to a post here. I would like to try and replicate the problem and see what it takes to solve it. Alternatively you could PM me and attach the file there.
Beer is not a matter of life or death, it is much more serious than that.
Problem solved. Baldwin and myself have been exchanging ideas and modifications on the route in question. Thank you very much baldwin for all your support and solution.
The activity has two reverse points just after some protecting signals. They were positioned OK for MSTS, but too close to the signals for ORTS. When I moved them considerably further away from the signals there was no more freezing.
One final thought on 100% compatible activities between MSTS and OR - As I was running those Diesels West activities for Feather River that I mentioned last time, I ran into activity completion struggles caused by the pathing that clearly was built to traditional MSTS standards and that really no longer apply to Open Rails. The original path was set up for the player train to enter a signaled siding, stop, and make a pickup of 4 cars off a double ended spur that was about 6 cars long. The activity author employed MSTS-style reverse points to automatically bend the iron into the pickup spur and back the train in to make the pickup. I ran into trouble when I ended up perpetually chasing the reverse point that was behind the train and that I absolutely needed to trigger in order to continue forward with the activity. But Open Rails does not need those reverse points. In the real world, the dispatcher would route the train into the siding, but then it's up to the train crew to manually throw the switches and derails to execute the pickup. The only thing Open Rails needed was for the path to route the train into the siding and maybe throw an absolute wait point expiring at a set time in front the train (to keep the siding exit signal red and to allow other traffic to go by unimpeded on the main), and once in the siding, the player changes to manual mode, manually throw the switches, and backs in for the pickup, even going off-path briefly if needed. Open Rails was far more accurate at distinguishing which portions were automated by dispatcher and which were locally controlled by the train crew on the ground. OR did not require reverse points that officially changed the direction of the entire train briefly. Once I reworked the player path to eliminate the needless path-based flippy-flops in train direction via reverse points, and instead relied upon Open Rail's ability to go into manual mode to do all the localized switching as needed, returning to auto mode when switching was complete, then the activity was able to carry on to a success after the fixed time wait point expired and gave me the signal to depart.
When it comes to activities, there will never be 100% compatibility between MSTS and OR simply because some MSTS features (like employing reverse points to do simple switching) are obsolete in the OR world. At some point, you are just better off developing and warranting activities for one platform or the other, but not complex activities that attempt to work with both worlds. This really is part of the 2% in a 98% compatibility situation and where there really will never be any justification to dump all those programming resources into accommodating a work-around for one side's obsolete features.
There is a limited place and a time to use reverse points in Open Rails activities. When you run a built-for-MSTS activity in OR, you end up with reverse points being over-used in situations where they are not required, and leading to strange behaviors and unique problems.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, personalize advertising, and to analyze site activity. We do not share information about our users with anyone. For additional details, refer to our Privacy Policy.
By clicking "I UNDERSTAND" below, you consent to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment