Sometimes if you start a scenario that is not on a DTG Route you get Out of Memory. I was suggested on another forum to first go in to a Scenario on a DTG Route - just for a few mins. Then come out of the DTG Scenario and try the one you had a problem with It does work sometimes
Peter I have also seen that "fix" and it works about the same as if you load the scenario that gives you an OOM - let TSC crash and close then re-start TSC immediately and the "bad" scenario will sometimes work too without an OOM. I use both methods and in my case, I see around 60% success. Worth trying!
This really makes me curious. I'm taking TS (594 Steam DLC + 3rd Party Pay/Freeware) to the limits in terms of hours-long sessions, on-the-fly bin editing, Youtube and forums in the background, playing different routes, editing scenarios, Alt-Tabbing hundreds of times. It's been a long time I've managed to trigger an OOM - that was placing a 100-car consist in a yard trying to drag it to the right siding. Could you give me an example of a scenario that's prone to crashing?
Torf There are many (for me) in the JT sold version of the Metropolitan Line - typically - S7+1 Baker street to Harrow on the Hill (and S8 version) :\STEAM\steamapps\common\RailWorks\Content\Routes\13a0930b-1dac-417e-8680-cf94a782e1f8\Scenarios\09252541-d3fd-410c-8400-5aa815c0b529 (in both 32-bit and 64-bit TSC) I just tried (yet again) Peter's "fix" as above) and this scenario worked without OOM!! These errors (for me) started before the 64-bit version of TS2018 was introduced and it could be related to the limited 32-bt VAS address (2Gb for most systems) and subsequent VAS addresses not being fully utilised by the 64-bit version of TSC.
Just tried the Baker Street to Harrow Hill, no problems for me (Steam version). There should be no difference to the JT distributed version. Seeing the Steam reviews this route does not play well on many systems. And I've had trouble with the fact that JT mess up their own assets if you install different routes by them, had to sort some stuff out manually as I've written in other Technical threads. (The SWEX/Kyle combination led to missing coaches, then adding Cornish Main Line led to instant OOM - solved by manually installing to a blank folder then coyping and overwriting assets.) Then there was the Pennsylvania Steam thing which was apparently an issue for me only. So if this fix works for you, great.
Slight bump... Having just repurchased the Met Line after initially refunding, then going to resume a saved game... immediately had an OOM CTD. Great, as I doubt Steam will entertain a second refund on the same product in less than a week. This happened north of Harrow On The Hill. I also had a similar CTD with the New Zealand Midland route and JA steam loco, attempting to resume a saved game. So I do wonder if the process of restoring a saved game is "busting" some sort of limit and generating the issue. My PC is a bit of a potato but really no reason why it shouldn't run TSC adequately - I7 4700 @3.5Ghz, GTX 1650 GPU with 4Gb RAM and 24Gb of system RAM. Runs TSW fine without crashing. I have switched off Windows Gamebar or whatever it's called and upped my Virtual Memory to 8192 Gb as suggested elsewhere. I'll also try Peter's suggestion later. However TSC never used to do this a few years ago and running on lesser hardware too. High time DTG diverted a bit of coding and dev time away from TSW to try and fix the problem.
OldVern, I understand that's frustrating, but... Having studied the game engine and its mechanics for quite some time now, there is things we just have to live with. The core engine is simply not made for certain things. Developers have gone very far in terms of adding features by using very advanced scripting. Saving a game means creating a file that contains a list of all locations of rolling stock and their actual state. There's basic ones like the position of the regulator, the brakes, your speed, headlights etc. What made TS survive that long is also its weakness - the possibility to completely script your own loco, which means using a lot of variables to store the state of the loco's systems. So certain custom variables cannot be saved - as the game does not know about them, to put it simply. They work in the background to enable you to have features not deemed possible in RailWorks days. Some advanced loco's manuals will tell you to put the loco in a certain state before saving so the script will not crash after resuming which will mean some of the runtime variables will be reset to zero or an initial state defined in the script, some advise to not save at all - that's just how it is. That savegames are problematic is a known thing. Workshop scenario authors like my fav Not.Silent have their scenarios take about 20 to 50 minutes, so you can play them in one run. As nice at it would be, we cannot have the "perfect" simulator, TSC has been pushed to its limits already. And with issues growing, a developer will naturally come to the point one day to start coding a new game - TSW. Remember coding of TSC started around 18 years ago - and Kuju were very thoughtful to make the game open for improvements and modifications - but I doubt they would have thought it would last this long, and for that we have to be thankful for everyone who creates content and pushes the limits, but there's a price to it, but that's mainly just the savegame not being usable. If you enjoy this game still like I do, you have to live with some of its shortcomings, and I think the benefits still outweigh them. Find the time to play a scenario in one run, if you can't, pause the game and put your PC to Standby - which is kind of a savegame that just saves your memory to disk.
It's probably just a case of older hardware. Since I've been running on a 12th gen i5 with decent ram and a rtx 30 series ooms are a thing of the past for me. Although they do occasionally occur when running 3 or 4 merged routes. This is running win11 that's not supported apparently.
Any variables used by the locomotive script that need to be restored, after resuming a saved session, to the state that they had when the scenario was saved can indeed by restored properly. All the developer has to do is to put corresponding "control value" entries into the engine blueprint and save the script variable in said control values whenever the script has changed the values. Then, when resuming (which the script can detect), get the variables saved values from those control values and, importantly, act on them to restore the saved state. Note that the game saves all control values. It's not necessary to do this for absolutely ever variable, just those that are important to restoring a saved state (such as the state of windows and doors being open or closed, for example, if you don't want to find them all closed again when you resume). That's what I do in all my locomotives, which all resume flawlessly.
Thanks for the info Smokebox, makes me want to remove my post. Anyway, this might be of interest too (from JA Class manual)
