Hi all, I'm currently battling an ongoing issue with out of memory crashes when creating scenarios. These crashes seem to happen most often on two workshop routes I have, South London and Thameslink and North London, GOBLIN and South London to Brighton by Danny Leach which are merges of two or more DTG routes, and I'm not quite sure what's causing these issues but they are hugely frustrating. On one scenario I'm creating on the North London, GOBLIN and South London to Brighton route (which is a diverted TPE/LNER Class 80x delivery run from Eastleigh between Three Bridges and Harringay via the BML and WLL), I was adding AI to the scenario mainly using AP stock and placed everything I needed between Three Bridges and Clapham Junction. At this point, all seemed well. Then I tried to add a DTG Class 378 at Clapham Junction to work a West London Line service, and placed the train successfully but when I tried to change the coach numbers & destination, I suddenly had an out of memory crash. Luckily by this point I'd saved my work so only lost the Class 378. A day later, I tried adding the Class 378 again, however the same crash occurred. Now I can't seem to access the scenario via the editor or playing it after starting up the game without an out of memory crash and it seems the only way to bypass the crash is to play something else for 45 minutes or more before trying to access the scenario which seems very strange. I'm not too sure if this is being caused by the train or the workshop route itself in this case, but this crash has happened on various scenarios I've tried to create on the mentioned workshop routes. Before the issues occur I'm usually in the middle of adding AI trains or teleporting to another location on the scenario before I have an Out of Memory crash out of the blue. Once I have one OOM crash on the scenario, they keep repeating which renders the scenario unloadable unless I play something else first, and these crashes seem to be occurring once I've added a certain amount of AI to the scenario. This makes me wonder if the root cause of the OOM crash is too much AI? The AI trains I add are based on the working timetable the scenario is set around, so for example the scenario I'm making at the moment is based on the December 2019 timetable when more trains were running. For those unaware, the Brighton Main Line is a busy route in suburban London so quite a bit of AI is required. Nearly all stock in use on the Brighton Main Line is represented by Armstrong Powerhouse packs so I use them as AI (with DTG stock for trains not represented by AP) and they seem to work fine on other routes so I'm very confused. I do however use quite a lot of static AI at depots/sidings and at terminuses such as London Victoria and London Bridge to represent what they would be like in real life, would removing any unnecessary static AI help to reduce these OOM crashes? However, I tried to play a scenario I downloaded off the Alan Thomson Sim site on South London and Thameslink with AI to represent a working timetable and this seemed to load without a problem which makes me even more confused about how to solve these annoying crashes. If it's the route that's causing the crashes, I know unsubscribing from the route is a possible solution to the problem but I've created quite a few scenarios on these workshop routes which I've put a lot of time and effort in. If I unsubscribe and then re-subscribe to the routes, would I lose the scenarios I've been making? I've tried contacting DTG support a while ago about these crashes with the crash report but they weren't very helpful. My computer is a Dell G5 5000 desktop with 16GB RAM so surely it has more than enough memory to run these scenarios? Has anyone else experienced these issues before and if so, are there any solutions I could try to stop these crashes? They are very frustrating indeed for someone who enjoys creating scenarios. Many thanks in advance!
Your scenarios should not be deleted when unsubscribing - but it is safe to back them up anyway. Just copy your scenario folders to a safe place. Build menu tells you the file paths, or NameMyRoute.exe comes in handy too. To spot them easily, I put a prefix, in my case "[tm]..." in each scenario name, so you find them quickly using NameMyRoute.exe. There's various methods of safely installing workshop content, I subscribe (TS not running) from Steam and then copy the "Content" folders inside the zipped workshop files - which are found in Steam\steamapps\workshop\content\24010\ after subscribing - to my RailWorks folder. I then delete all files from 24010 and unsubscribe everything. Because if you delete the files from this folder before unsubscribing, Steam does not remove the content (because it doesn't know where they are and cannot sync both 24010 and installed content. Instead your workshop menu stays clean and you can avoid syncing issues. This method makes sure scenarios are not being corrupted when TS modifies the ScenarioProperties.xml to add Workshop tags - which is not needed anyway if you play the scenarios from the Career/Standard tabs and NOT from the Workshop tab which still has issues. And again you can get into Syncing troubles if you happen to accidentally modify workshop content, which can lead to redownloading and possibly corrupting WS content in consequence. You can spot corrupt installed scenarios often if you see characters or text missing in the scenario description. That's a clear indicator of TS corrupting the xml while installing via Workshop tab. So this is just my method of having a stable TS installation - however all this may have nothing to do with the OOMs on your end. There is just a few OOMs which could be traced down to specific files - most of them depend on your installation, DLC library and hardware.
I generally play my scenarios from the standard tab so not from the workshop tab When you mention modifying workshop content, does that include modifying the Quick Drive as that's the only thing I've modified on South London and Thameslink? Last night after driving something else for an hour, I was able to access my scenario again, and whilst I was on it I removed a few static trains which weren't doing anything to see if it fixed the problem. However, once I pressed play, the scenario initially loaded but then crashed 5 seconds later with an OOM issue
If it's a workshop quickdrive only. When making QDs, I make them being easy to identify by giving the waypoint "friendly names" a prefix, because the QD menu collects all QD scenarios to present their paths. So when clicking a starting a location I know which scenario will be loaded. The game tries to prevent you from editing synced WS content ingame, in the Pause menu the "World Editor" will be greyed out. You can still edit it using the Build menu though.
Hi all, Sorry to bring up an old thread from 2022 but I am encountering these issues again, this time for another scenario I made between Brighton and London on the same route (South London and Thameslink and North London, GOBLIN and South London to Brighton) driving an AP Class 455. If I try and load the scenario from initial start-up the game crashes straight away with a fatal error in mode Loading. Usually if I drive something else for 15-30 minutes and then load the scenario, it loads. Any idea why this happens? I've also had occasions where the scenario would crash minutes after I leave Brighton with an out of memory issue (in mode Drive) or an AI train which I have given the correct path for suddenly derails or crashes into another train, or an AI train suddenly starts moving at 0.5mph. It is hugely frustrating having spent so much time creating scenarios like this only for them to be unplayable the majority of the time. I've attached an error and crash report from my most recent try in trying to load the scenario, but if there's any more information that you may need to help resolve this issue, I'll be more than happy to provide it. DTG Jamie TrainSim-Steve tagging you both as you may be the right people to help investigate this further!
You need to run LogMate.exe (in the RailWorks folder), then run the scenario and post the FULL log (found in the RailWorks root folder) to find out which asset might be related to the crash. Also which version of RailWorks.exe (32, 64bit, DX12 Experimental) and version (official, beta). Best to also supply a zipped copy of the scenario, otherwise it's almost impossible to reproduce the error. We can only test what we have on our system. And everyone has a unique TSC installation.
Thanks, I'll give this a go the next time I play the scenario! Can I attached a zipped copy of the scenario in question on to the forum or would this be better placed in a support ticket? Didn't think it could and it would be a great help to try and get to the bottom of this if someone from DTG were to look at it.
Thanks class455, very much appreciate the detail and the crashdump. From your crashdump, this does appear to be an actual instance of running out of available memory but we have managed to nail down the cause and we're hopeful the next Public Beta build to roll out will have a fix for this very issue. Best, Steve
That's great to hear, thanks for taking a look at this Steve! Could you provide a little more detail of the exact cause, and is there anything I can do in the meantime to stop it from happening or live with it until the next public beta comes out? This seems to happen more often on this particular route, though in fairness as it is a merge of three different routes it is rather large so wouldn't be surprised if that has something to do with the constant crashing. It's quite annoying really as I make most of my scenarios on this particular route since it's the most up to date version of the Brighton Main Line and includes London Bridge!
The exact cause is simply that there was insufficient space in the heap. So, as part of the beta, we've doubled the size of the heap from 1GB to 2GB and that should take care of the problem. You could mitigate the issue by reducing the amount of geometry on the route. Simply setting the display options wouldn't be enough. Best, Steve
Steve I increased my DesktopHeap to 2GB (via Regedit in Windows 10) back in the day when DTG/RSC introduced TS20XX 64-bit, do I need to change that back to the default? I also changed the HeapDeCommitFreeBlockThreshold in the Registry and for me that made TS20XX much more stable with fewer or no SBHH's or OOMs seen.
Hi Peter, So that setting essentially just increases the heap for vram and page files particularly for applications that are likely to make use of page files like TSC was before we reworked how memory is allocated to take full advantage of your system ram. As long as things are operating normally as far as you're concerned, it should be safe to assume it is ok to leave it as is. I'm a big believer in the saying "if it isn't broken, don't try to fix it". One test that you may wish to try is to reset the value back to default, then restart your PC and note if there are any notable differences between the two settings. I don't believe there should be any difference but until you try it you won't ever know. However, I would ask you to consider whether it's worth the effort if everything's working fine as far as you're concerned - sometimes it's just better to leave things alone. Hope this helps. Best, Steve
Steve Thanks - I totally agree - it has worked for me since around 2018/9 (and is working now) - so I'll keep the settings without change.
