Session too busy?


New member
I recently extended my route by around 10 kms and some sessions that had worked perfectly well before now crash whilst others are OK. I have worked out that the sessions affected are the busy ones where there are several AI trains and parked wagons in sidings and the crash always occurs at exactly the same place - in an urban area. It isn't a frame rates issue but a full blown crash - fatal error, blue screen, the lot!

Clearly there is a combination of things at work here - extended route, urban area, AI trains, parked wagons all give the computer more work to do. But, when it comes to rectifying the problem, where should my priorities lie? My instinct told me to "thin out" the urban area where the problem occurs but this seems far less effective than removing some AI trains. Yet the crash always occurs at exactly the same spot so something on the route must trigger it.

Any advice would be welcome.
I would probably start with removing a few trains as these are usually high detail (and as a result high poly) assets.
I know there are a few "fake" trains available (splines of low-detail cars) that might replace trains that are there just as scenery, but I don't have them myself and doubt they are available for your old version of the game.

Did you import a lot of google-sketchup buildings into your route? Those are usually also extreme heavy in poly count and might cause your system to get problems.
Sessions are tied to the route as it was at the time of saving. If anything has been changed or renamed with regards to track and trackside assets that was on the original route, these sessions may fail. The session may be looking for something that no longer exists because it got removed. A piece of track that had a wagon on it in the original got replaced in the extended version is an example because the session is still looking for that track to place the wagon on. The other sessions that do work may be more recent.
In TRS2006 bad groundtextures could crash the program. These errors are hard to find, because CMP doesn't detect the error.

Your suggestion that things may be too busy could be correct. Working with another scenario system, I found sequences that functioned properly in individual tests went wrong when finally testing the complete scenario. The system I used has has a rolling debug log window showing what and when commands were working and it was evident that the command density was the problem.

I have experimented with objects of my own and noticed that if there is to much happening messages would get lost and the objects did not function correctly. The script engine in the present version cannot handle a lot of events. Also to many object will slow things down a considerable about and I have even experienced crashes on routes with a lot of objects.
A big thank you to all who replied with various constructive comments. Work is still in progress but I think the solution will lie in a combination of things. I took one of the sessions that had previously worked and now didn't and, firstly, thinned out one of the urban areas on the route itself. No luck. Then I removed several wagons and a loco from the sidings - now it worked at a speed of 60 km/h but crashed at higher speeds. Progress! More wagons and two more locos were deleted - my chemical works now has four wagons instead of about 24. This morning after about three days's work I managed to drive over the critical bit at normal speed. Fortunately I have avoided having to remove any of the AI trains which would have spoiled the session.
I was especially interested in Stagecoach's comments - I don't think this was an issue in this particular case but it's something I must remember for the future. The portal at the end of the original route has been moved down the line 10 kms on the new extension but I took care to keep the same name and it seems to work OK.

Thanks again