The crash to desktop (CTD) problem has long plagued my attempts to set up my own Quick Drive from Carlisle to Stranraer on Western Lines of Scotland. I write my own Quick Drives as ( some of you will know ) I having been developing QD methods since they first came out. I suspect that this solution also applies to many other situations that cause CTD in scenarios but the experiment, findings, and solution has been conducted using the QD methods. This set of posts details the approach and sets out a solution. So, the situation is that I have written many QD scenarios for multiple routes that do not cause a CTD but for this particular scenario ( and in other similar complex QD scenarios on other routes ) I was getting a CTD as the QD loaded. However, there is a critical observation here. After I saved this complex scenario it would load and run provided I did not shut down & restart train sim or run a QD on another route. If I did this it would then CTD. Thinking about this the difference was that shutting down and restarting train sim caused all the databases to rebuild whereas running the QD directly after saving did not. This meant that any testing would need to be conducted after I had completely shut down and restarted train sim. The test scenario starts at Carlisle station and spawns a large number of static light engine consists for locos at Kingmoor and Dumfries loco sheds, Kingmoor Yards populated with spawned static wagons and trains, and a large number of AI consists spawning on the route. In order to try to establish what caused the failure I first rebuilt the QD starting with simply Player spawns at Carlisle, Dumfries, Castle Douglas & Newton Stewart. That worked fine. Next I added AI traffic in the opposite direction. That worked fine. Next I added some consist spawns for wagons and trains to the yards nearest Carlisle and starting from Carlisle did not induce a CTD - even after a complete fresh restart of train sim. I then added a consist spawn for Light Engines ( I use one eConsistTypeCustom5 to identify light Engine consists) to the MPD at Kingmoor. On restart this caused a CTD. That meant that either (a) there was something about Kingmoor MPD and/or something about eConsistTypeCustom5 that was causing the CTD. cont/...
cont/.. So next I deleted this consist and added a eConsistTypeCustom5 spawn to the loco shed at Dumfries. Starting from Carlisle did not produce a CTD. That suggested it might be something to do with Carlisle Yard - possibly. However, I have lots and lots of eConsistTypeCustom5 light engine consists as I have a lot of steam locos ! So I picked one light engine ( the weathered BR early crest O class from VictorianLad) consist and edited it to make the consist type as eConsistTypeCustom1 ( one I don't use normally ). Placing a spawn point at the Kingmoor MPD for eConsistTypeCustom1 worked fine, no CTD. I then added multiple spawn points to the yard all for that eConsistTypeCustom1 ( multiple versions of the same loco in the yard ) and again no crash to desktop. So this meant that it was something to do with my eConsistTypeCustom5 consists and Kingmoor yard. Stepping back I wondered if the source of the problem lay first with the consists. So I used SERZ to turn all of my eConsistTypeCustom5 light engine consists into XML files and then openned them all at the same time in an editor that could perform a find search accross multiple files at the same time - I use ConText but I think that Notepad++ does the same sort of thing.
cont/... For each consist I selected the <cConsistEntry d:id="47555893"> identifier for each CConsistEntry. That is the unique number given to each item in a consist. I then searched the all entries for this number. Effectively looking for duplicate CConsistEntry id's in all my light engine consists. Why ? Bad practice on my part means that I often copy an existing consist and edit it manually to create new consists especially in the first excitement of making light engine consists when I get a new loco. What I found were multiple light engine consists that contained the same CConsistEntry ID's. This was interestingly often the case for tenders where I had clearly not been as rigorous. So I changed the CConsistEntry ID manually, saved. and rechecked to make sure I simply hadn't duplicated another "random" number. This was not a short process, it took three evenings as I do have a lot of locos. All the .xml's were recomplied to .bins using SERZ.
cont/.. So now the acid test. I went back to my QD scenario and changed the Consist Spawn points in Kingmoor Yard back from eConsistTypeCustom1 to eConsistTypeCustom5. Saved. Closed. Deleted all the databases in CONTENTS directory. Deleted all blueprints. Then I restarted TrainSim. I then restarted a quick drive from Carlisle. No CTD on loading. So far so good. The a steamed past Kingmoor MPD and it was populated with lots of different steam locos. Repeated several times and each time no CTD and lots of selected locos in the MPD. Including some I hadn't seen before as Light Engines. That caused me to wonder if actually duplicate cConsistEntry ID's prevented a consist from loading. At which point I bit the bullet and repeated the process I had done for my light engine (eConsistTypeCustom5) consists for all my consists. Several days later after a lot of editing I found that my sloppy practice had produced many duplicate cConsistEntry ID's. Once they were addressed my Quick Drive was suddenly populated with a whole new range of consists of a much wider variety.
cont/.. So what does this mean ? (A) There is a specific CTD caused by duplicate cConsistEntry ID's. This is duplication of cConsistEntry ID's in any consist in any stock's/ loco's preload directory as all are loaded at the same time. (B) Somehow, this is not apparent until the main TrainSim databases are loaded at a fresh start of a TrainSim session ( when the Content databases are refreshed. (C) This one is the kicker.. For light engine consists there is a particular vulnerability. I think this is explained by the distance of the light engine to the starting player spawn point when the QD scenario is loaded. Any AI consist that is approached by the players train will not start to emit steam and do its thing until a certain distance is reached. On routes such as WLoS the long straight stretches of track often means one can see a static AI consist from some distance off and it is not until one get close that the locomotive heading the AI consist starts of ( usually seen by the smoke being emitted ). Starting from Carlisle Station of WLoS Kingmoor MPD is in the "startup" range for AI locos. This means that any light engine consists start-up emitting smoke when the scenario loads even if not moving i.e. the various simulation and scripting parameters start. This is, I think, why I had noticed that a CTD was caused by light engines at Kingmoor but not by light engines at Dumfries when starting at Carlisle station.
cont/... So how to address this issue ? Simply ( but painfully ) check for duplicate cConsistEntry ID's across all consists not just ( as I thought I had done ) within each Preload directory. I have a feeling that this issue of duplicate ID's in blueprints may also be one cause of CTD in "normal" scenarios as well but as I don't tend to build scenario's its not an issue I have come across. I resisted posting this short report until I had been able to establish a number of sessions of trouble and CTD free running on the existing WLoS Quick drive scenario I am building and also several sessions where I have successfully added further spawn points to the scenario and run successful sessions on that edited version. I am not claiming this is the only cause of CTD. I am sure there are multiple reasons some of which may be the result of the sort of Pagefile memory issues often suggested as cause and solution but I suspect that this particular solution points to a specific case where TrainSim can't allocate things to memory somehow because of conflicts and so dumps the program as a result of unreconcilable problems. This issue of unreconciled problems seems to me to be a far more likely generic reason for CTD than simply not having enough memory and would explain why a fresh out of the box version of TrainSim seems less prone to CTD than one ( like mine ) with a large amount of DLC and self built files. Hope this helps solve a few problems.
Scanning through your text - I don't author much so I believe it's more for devs and your fellows - it did remind me of one crash I managed to produce. I don't have the pic anymore. Important part, the message included out of (graphics) memory. I created a moderately busy yard at Roseville on Donner Pass. There weren't many wagons, but a bunch of all types, however I went crazy and included all my SP locos in the shed (one or two of each), plus a set of mostly UP around the fuel area. So far, so good. Then I wanted to add some AI so I placed two Sherman Hill consists with the intent for them to be AI. From this point onward, as soon as I faced my camera east at Roseville, it was dead. Scenario would start, but picking any loco, instant crash. Editor would start, but looking east to fly there would crash. Fun times! But I had a funny idea that I would fly around sidestepping the whole way in the editor, and delete the two SH consists. In contrast, I could create a magnificent scenario for Canadian Mountain Passes, although I didn't go far and only used CMP, Classic Assets (UP, BNSF) and the CN SD40/ES44 that I created the scenario for. 35 AI, set up in one sit. Lesson 1: the game cannot handle too many different assets at once. Issue 2: much more trivial, but there is something off with moving consists. No idea why, but when I try to position parts of consists precisely, it tends to crash very quickly. Even about a month ago, I had to split up a consist of 60 identical coal cars and 3 locos, all I did was pull the first loco forward, pull the middle loco to the adjacent rail, and pull the pushing loco back, and maybe click the second batch of 30 gondolas to start moving. Crash.
Not sure I agree with your lesson 1. I am currently running with probably 50+ individual consists added to a quick drive scenario on WLOS, which is itself a very asset heavy route. Some of these consists include 20 to 30 wagons or 10-15 coaches. Added to which I have also added a number of placed stock assets as "fixed" trains such as conflats and milk wagons. However, where I do agree is that if one has this duplicate cConsistEntry ID issue the sim is more likely to throw a CTD on an asset heavy section of a route than in a route or route tile that has far fewer assets. This would point to the handling of this error being related to the way that memory is being used to hold the assets in an area of a route and the capacity of memory to then handle the conflict that this duplication causes. Your lesson 2 would suggest that my idea about the CTD being caused by assets becoming live or changing their status ( as the scripting and emissions start up ) may well play an important role. But thanks for your thoughtful comment as it did cause me to think about this issue.
Just to add a technique for scanning for duplicate cConsistEntry ID entries that I found almost by accident. You'll need excel. First create all your consists as .xml files and drag them into a single directory. If you are looking at fragments as well you'll need a seperate directory for these as they have a slightly different structure. It is possible to use the Developer tab in excel to scan a Consist that has been converted to a .xml. This mapping creates a list of the xml fields ( for want of a better term ) that can then be dragged individually onto your spreadsheet as column headers. Obviously the key ones will be the cConsistEntry ID and probably some sort of identifier such as the loco name or stock blueprint name being loaded. You then use the import function and highlight all the xml files in your directory. Excel grinds away and in a few moments you'll have a spreadsheet with all your cConsistEntry ID ids listed in a column alongside some identifying info for each. Sort the cConsistEntry ID column into descending order. Using an empty column write an =if(Cell n = Celln-1,"Dup",OK") formula in the second row. Copy it down the column. Now you can look up to see any rows that have a DUP flag i.e the cConsistEntry ID is the same as that in the row above. Sounds complicated ? It is harder to write than to do. Saves having to check every consist and the beauty of it is that of course it also identifies numbers not used for cConsistEntry ID's that you can use to replace duplicates. Took my an evening to scan and edit duplicates in over a 1,000 cConsistEntry ID's.
Finally another finding was the absolutely critical importance of making sure that for Fragment Blueprints the filename and the <Name d:type="cDeltaString" header are the same. I had quite a few that weren't at that too was causing CTD's. For the older amongst you handling quick drive consists and fragments is beginning to remind of my early days of Fortran programming !
