[James Ross]

markus_GE, on 29 April 2015 - 02:05 AM, said:

Has the fix already been committed into the official code base?

No, but the Activity.cs patch on bug 1447222 looks good and should be committed soon.

[markus_GE]

OK, I´ll wait for it being comitted officiailly, before messing with the code myself in the tired state I´m currently in (night duty says hello...)

Cheers, Markus

[EricF]

:( I can confirm that as of x3050, the freeze on the Northeast Corridor v4 in Explore mode that I encountered last year is also fixed. Not sure if the specific fix came in at x3049 or x3050 because I didn't catch the update until x3054 was already out with the other patches already in place. But the bottom line is that the route will now successfully run straight through the problem area near Philadelphia that I encountered before.

With the F4 track monitor up, the signal logic is clearly very busy in the area where the hang would happen - changing signal states around my train now and allowing restricting indications ahead instead of trying to maintain green/clear all the way. It seems to be working well! :good2:

[Fred]

I may be experiencing the same bug.

The frame rate drops from the mid 30's down to 5 or 6 and the screen freezes. The sound continues normally.

This always happens at the same point in the route. It makes no difference whether I am in the the explore mode or running a simple activity with no traffic. Also it makes no difference whether I approach this point from the north or the south. I am running X3066.

Attached is a copy of the log file for the explore mode.

Attached File(s)

•  OpenRailsLog.txt (17.14K)
  Number of downloads: 175

[JeroenP]

Dear Fred,
Thanks for adding the logfile. Unfortunately, there are still a couple of questions I need to ask

• Which version of MBTA are you using? I do not think it is version 5. Is it the most recent (10-21-2014)? Did you also install all updates I could find on trainsim.com?
  
• The logfile also does not specify at which point exactly the problem occurs. Could you be a bit more specific? I would assume that if I have the correct version of the route it would be easy to reproduce, but I am still downloading.
  
• The logfile you added does not seem to show a problem. (The error that is in it is after the end of the game and does not show a stall of any kind)

Thanks. Jeroen

[markus_GE]

Just a quick question: Has the fix for the problem I initially reported already been added to the current X release? If so, I´ll try and test it some time during the workend - I mean, weekend ;)

Cheers, Markus

[JeroenP]

Markus,
Sorry for not informing this forum. The bugs https://bugs.launchp...or/+bug/1447222 (your original problem) and https://bugs.launchp...or/+bug/1448772 have been fixed in 3049/3050. However, there is no general solution yet (I just created https://bugs.launchp...or/+bug/1453255 for that, but that will be post-1.0). So it is possible that people like Fred find similar issues from different parts of the code that use the same DistanceTo function.
Best regards,
Jeroen.

[markus_GE]

Don´t worry about not updating here - If I´m interested in something, I´ll ask for updates on my own ;)

That actually does sound great, at least for me. Hopefully I´ll be able to complete said activity soon :)

Cheers, Markus

[JeroenP]

Dear Fred,
I do not think the issue you are facing is related to infinite loops. I do not see a stop in your logfile and any indication of a runaway process. Furthemore, the route does not have a loop as far as I can see.

I would suggest something else that is going on. When running this route on my laptop in debug mode, I get an out-of-GPU-memory error. If I run it outside the debugger, I get similar behaviour as you quote: sound keeps running but performance is really really low, almost invisible. But it does not really stop. I do see small updates (like a framerate below 1 frame/second, or perhaps GPU stalling.

On my PC (much stronger than my laptop), I see a strong decrease in performance at a certain point. It feels like throttling. And the performance indicators (F5 for showing the HUD and then some shift-F5 to get the proper debug windows. It happens when going past a 'wall of trees'. This happens some 4 minutes out of Providence. See the pictures attached. There is on the right side a wall of trees that seems to be formed of many many trees. The throttling starts when the trees come into view, and is gone when the wall is past.

I have added 4 screen shots showing what I see (sorry for the large size). So my guess is that your graphics card (or perhaps the on-board graphics card) is simply not capable of handling this rather strange structure. It might help to look outside of the left window when passing this point.

Best regards, Jeroen.

Attached File(s)

•  MBTA screenshots.zip (15.47MB)
  Number of downloads: 168

[dennisat]

JeroenP, on 09 May 2015 - 08:11 AM, said:

... It happens when going past a 'wall of trees'....

Have you tried the Video Option "Model instancing"? This has had a huge effect on one of my routes where the lineside scenery was continuous repetitions of the same objects. At one location the fps had dropped to 11 but checking the Model instancing option raised the fps to 60. I also have Vertical sync checked which limits fps to 60.

Dennis