I too have a similar problem with the PRR Eastern Region. I even updated the camcfg file to one that would supposedly help with my problem but the route still crashes at one point or another.
I too have a similar problem with the PRR Eastern Region. I even updated the camcfg file to one that would supposedly help with my problem but the route still crashes at one point or another.
The PRR East is known to crash because of the memory usage, eventually the computer runs out of it. Misplaced sound sources are another cause of route crashes as well.
Beer is not a matter of life or death, it is much more serious than that.
But then how can anyone expect to run it?
Every time I have experienced a CTD in MSTS is when I have made changes to my shape files. When building locos I create a basic model, export it and test in MSTS after each building session. It is easier to find the cause of an error this way rather than spend six months on a model, finally export it and then find it wont work. In all my models to date, I start to get CTD under certain conditions when in external view once the model starts to exceed around 10-11,000 faces.
This is the test I use to ensure the model geometry is OK for MSTS.
When in game go to #4 view and position the camera in front of the locomotive, just off the centre line and just high enough so that the camera just clears the roof but does not cut into it. Then start the train and let it slowly pass under the camera. Invariably if there is an issue with the shape file then I will get a CTD as soon as the model is directly under the camera and the view has to rotate 180 degrees. If I can get the loco to do this three times in a row without crashing I know its good.
Before using this method, I would just test the model ‘in game’ using different camera views and it would (seemingly) randomly CTD but not always. This made it difficult to find the cause. Because I always test my models on my route I knew it wasn’t the route as I always start from the same location on the route.
If the model crashes using the test above, then I have to use shape file manager to decompress the .S shape file then I run shapefix on the model, then run shapefix again on the resultant fixed shape file then once again just to be sure. In fact once my models reach this crashing stage I run the above fix each and every time I create a new shape file because the ‘condition’ has never resolved itself. Note that I don’t have to run shapefix on the models if they are used only OpenRails.
I’m not saying that your CTD issue is due to a piece of rolling stock. I would suggest though, that if you are getting random CTD then run the above test on your rolling stock first as it is a known and replicateable cause. Once the rolling stock has been eliminated as a possible cause then you can move onto other possibilities.
Hope this helps.