[cjakeman]

Hi Dan,

A D REID, on 23 August 2022 - 07:31 AM, said:

While running an activity on the Long Island Rail Road (lirr_install.zip), I noticed jerky motion, so I changed the video options (removing the checkmark from Vertical sync), and this reduced the stuttering to a level that was barely noticeable (FPS 55).

P.S. If I remove the checkmark from Logging on the startup screen, frame rates increase significantly (FPS 90) and there is absolutely no stuttering (but Open Rails does not write to that "important" file that's needed for investigating problems).

If the logging drops the frame rate from 90 down to 55, then that's something serious that we should look at.
Can you upload a copy of that log file, please?

[A D REID]

cjakeman, on 23 August 2022 - 07:59 AM, said:

Hi Dan,


If the logging drops the frame rate from 90 down to 55, then that's something serious that we should look at.
Can you upload a copy of that log file, please?

Well, I didn't save that log file, and it was over-written.

I have tried, unsuccessfully, to re-create that situation, by resuming the activity from one of its saved games and running in autopilot to the end of the path, while paying more attention to frame rates. Although the frame rate is about 50 in most areas, I have observed it to climb as high as 90 in some areas, and fall to as low as 35 in other areas. In the situation I mentioned in my earlier note, I believe I had quit the game, turned off the logging, and resumed from an earlier saved game. My assumption was that the higher frame I saw resulted from turning off logging, whereas it may have been from running in a different area of the route.

I'm sorry for any excitement I may have caused by posting that claim.

Also, I have run that portion of the activity again, with Vertical sync checked, but did not experience any stuttering this time. So, perhaps the earlier effect may have been due to some external factor, perhaps other programs that were running on my computer at the same time.

Regards,
Dan Reid

[engmod]

engmod, on 18 August 2022 - 05:19 PM, said:

OR 1.5 rc1

Running one of my known activities from Bodiddly, Zanesville switching.

At the start of the activity I have to build a consist.
While doing the work, one of the switches behind stops responding.

You will notice in the attached picture, that the activity is in manual mode,
You will also notice that the switch monitor is showing the lower switch has a path set,

This set path should not be there, and appears after a particular set of moves.

With no errors in the log and this being a commercial route, how would you like to proceed.

This bug goes back to 2019, so not recent.

I have been able to verify the "manual path bug" with Paul Charlands route FJ&G activity 23-oct.
We now have a freeware route we can test further.

[charland]

"FJGv2", I have a test activity with all AI traffic removed and just the rolling stock left in the yard to switch.

I noticed yesterday that if you open the activity and the shadows do not appear, you can couple to the string of cars in the yard but when you use F9 to uncouple them nothing works. You can't scroll through the cars, and you can't uncouple, like your left mouse button stops working.

Paul :-)

[cjakeman]

Hi Dan,

A D REID, on 23 August 2022 - 11:35 AM, said:

My assumption was that the higher frame I saw resulted from turning off logging, whereas it may have been from running in a different area of the route.

I'm sorry for any excitement I may have caused by posting that claim.

No problem. That's an investigation we won't have to do, so I'm pleased about that.

Thanks for trying again and letting us know. Good to hear that you don't have stuttering - at least for now.

[A D REID]

Open Rails v1.5 -- Random Crashes

About a week ago, I was getting random (non-repeatable) crashes while running an activity on the Corbin-Knoxville route. Based on recent experience, I believe those crashes were related to the use of a new feature (Train Dpu Info -- shift-F9). I had saved some log files, which I am attaching now:

 OpenRailsLog 2022-08-20b.txt (13.26K)
Number of downloads: 151
 OpenRailsLog 2022-08-21a.txt (15.27K)
Number of downloads: 137
 OpenRailsLog 2022-08-21b.txt (31.39K)
Number of downloads: 137
 OpenRailsLog 2022-08-21c.txt (13.63K)
Number of downloads: 131
 OpenRailsLog 2022-08-21d.txt (29.42K)
Number of downloads: 144

Regards,
Dan Reid

[cjakeman]

Hi Dan,

A D REID, on 18 August 2022 - 10:23 AM, said:

While investigating this problem, I encountered another issue -- the simulator crashed when I tried to resume at a point that was 01:00:00 into the activity -- OpenRailsLog 2022-08-17b.txt

I also encountered another crash when I attempted to resume from a point 00:47:40 into the activity -- OpenRailsLog 2022-08-17-c.txt

I think these 2 crash reports are more concerning than the unexpected change in the behaviour (which is the topic of this thread), because the crashes could happen on any activity and any route. Thanks for reporting them.


The log shows that the first crash (resume at 01:00:00) is a signal issue. I can't tell yet whether this is bad data which Open Rails ought to report or good data which Open Rails should accept. In either case, Open Rails should handle it gracefully.
Do you still have the *.save file from which the Resume started? (Save files are kept in folder C:\Users\<username>\AppData\Roaming\Open Rails\)


The log from the second crash (resume at 00:47:40) shows a totally different cause, which is definitely a coding error. The code is scanning through a list which another part of the code has modified in parallel. C# can't cope with that and stops the program. It's another tricky problem as the log file only gives us one half of the story.

If you still have that *.save file, it would be very helpful too.

[A D REID]

cjakeman, on 04 September 2022 - 07:07 AM, said:

The log shows that the first crash (resume at 01:00:00) is a signal issue. I can't tell yet whether this is bad data which Open Rails ought to report or good data which Open Rails should accept. In either case, Open Rails should handle it gracefully.
Do you still have the *.save file from which the Resume started? (Save files are kept in folder C:\Users\<username>\AppData\Roaming\Open Rails\)

Hi Chris,

You are in luck -- I have that save file. I have just now tried starting from that point. The crash does not happen immediately, but I used auto pilot (and speeded up time), and the simulator crashed a few minutes later. I am including today's log file, as well as the original save file in this zip file:  NYD-1.zip (756.68K)
Number of downloads: 121

Regards,
Dan

[engmod]

We still have an old issue where on resume, the signal in advance of the train is not displayed on the track monitor.
The signal is also at red.

I have attached the log before the resume and the one after the resume.

Attached File(s)

•  cp 108 2022-09-03 14.18.39.txt (11.78K)
  Number of downloads: 131
•  cp 108 2022-09-05 09.09.30.txt (11.12K)
  Number of downloads: 146

[A D REID]

cjakeman, on 04 September 2022 - 07:07 AM, said:

The log from the second crash (resume at 00:47:40) shows a totally different cause, which is definitely a coding error. The code is scanning through a list which another part of the code has modified in parallel. C# can't cope with that and stops the program. It's another tricky problem as the log file only gives us one half of the story.

If you still have that *.save file, it would be very helpful too.

Hi Chris,

Again, you are in luck-- I have that file also. This is a puzzling situation, though. Before sending you the file, I have tried loading it several times, but did not experience a crash -- I was able to run the activity until the player train became trapped behind a traffic jam (and of course, the activity cannot be completed after that happens). Then, after several attempts, the simulator crashed immediately after resuming the activity. So, perhaps you should try repeatedly to load from this save file. I am including today's log file, as well as the save file in this zip file:  NYD-2.zip (719.96K)
Number of downloads: 126

Regards,
Dan

P.S. When I initially encountered these issues, I believe in BOTH cases, the simulator crashed immediately when loading from these save files -- so, perhaps you should try repeatedly to load from that other file I supplied today.