Hey, can you help me out on this? I haven't played this for some time (it used to work fine) and now it bombs me out to desktop everytime, no matter if I start a scenario or try to load it into World Editor ("Out of Memory"). Tried everything, 32bit, cache cleared, SDBCache rebuilt. All other routes work and I can use the assets from this on other routes without problems. Can someone who has this just tell me if it's loading or not for them? Thank you in advance.
I had not reinstalled this route when I moved my Railworks folder on to a bigger drive It was one that got removed when I was running out of space So I extracted it and got a small error Then I copied the files across and just tried one without a problem This was on a clean install of the route and stock You may think I don't like US routes but you would be wrong - I don't have an interest in Kettles Peter
Thanks Peter. Means I'll have to go hunting again. The extraction error is nothing to worry about, they put descriptive textfiles in the scenario folders to quickly identify them, maybe a development leftover. The two that are reported have zero bytes.
Code: 2022.02.15 14:42:31.201 - [NOT SET] - Assertion failed 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - ASSERT(mStartPos.isNearCurrentOrigin()); 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - cCurveStraight::setPosition() 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - cCurveStraight.cpp : 359 2022.02.15 14:42:31.221 - [NOT SET] - Assertion failed 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - ASSERT(mStartPos.isNearCurrentOrigin()); 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - cCurveStraight::setTangent() 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - cCurveStraight.cpp : 372 2022.02.15 14:42:31.221 - [NOT SET] - Assertion failed 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - ASSERT(mStartPos.isNearCurrentOrigin()); 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - cCurveStraight::setTangent() 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - cCurveStraight.cpp : 372 2022.02.15 14:42:31.221 - [NOT SET] - Assertion failed 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - ASSERT(mStartPos.isNearCurrentOrigin()); 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - cCurveStraight::setTangent() 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - cCurveStraight.cpp : 372 2022.02.15 14:42:31.221 - [NOT SET] - Assertion failed 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - ASSERT(mStartPos.isNearCurrentOrigin()); 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - cCurveStraight::setTangent() 2022.02.15 14:42:31.221 - [NOT SET] - 2022.02.15 14:42:31.221 - [NOT SET] - cCurveStraight.cpp : 372 This is what LogMate reports. Anyone who can make something out of that? Could this be a VisualC++ issue? I'll try reinstalling the supplied VC redistributable.
I ran it on a second install containing only the Kuju assets, DTG Academy and RSDL\Foliage01. Started Employee Excursion Part 3, camera zooms around the park then on a character and crashes to desktop again. So at least I could start a scenario. While browsing assets I found another thing I do not like. The S25 Heart of Berlin (very good addon) puts its Assets in the Kuju\RailSimulator folder and replaces a passenger file with their own (Scenery\Procedural\PlatformCharacters 00s DE.bin), effectively changing them for other routes. This is very bad design... So there might be some addon interfering by breaking rules like replacing official assets.
I managed to get it running on the clean offline installation only. Something's interfering on my full install. Hard to find out, but what the heck. As long as I can play it, it's ok.
The route does use the US and EU asset packs - if something got changed in one of those it could be the problem Use TS Tools to create a list of the Assets used in the route if you wanted to compare what you have Do you have anything else by GTRAX that might have overwritten a default file? And you could try another route that uses Kuju Assets - maybe a default one
No, I made that sure. My second install has just copies of my main installation's assets. And I'm very careful not to overwrite files, I even install rwp's manually to check nothing's gonna be overwritten. I've got 190 routes that run trouble free - just this one won't. TS Tools crashed when scanning the scenery tiles. But there's nothing missing, I even replaced the milk bottle's GeoPcDx with an OxPadd chimney to easily spot missing assets. I'm okay now using the second install for this route. Go offline - rename Railworks folders and play.
Update: I think I have found the reason for the crash. I can run it now, after editing a file in the assets which could (I am not sure about it) lead to memory glitches under certain circumstances / configurations. I will test some more and let you know.
By fixing this issue I've learnt some interesting facts about OOM, maybe of interest for you, Peter Hayes too. TS Tools reported a missing texture which was in fact not missing, but it stated the texture as being "Called by Texturing.bin" So I had a look inside that file and found something that seemed not alright. Each entry in this file has an ID, and I noticed there were some entries sharing the same IDs. So I went through the file and gave new (even numbers only) IDs for each entry, leaving a gap of 40 between each of them (taking Kuju\RailSimulatorUS\Environment\Terrain\Texturing.bin) as a reference. Started TS and the route loads fine without any OOM. What's interesting is: 1. The route worked on a clean install with the original "corrupt" Assets\G-TraX\BLE\Environment\Terrain\Texturing.bin 2. On my full (about 500 megs) install it refused to load - from the loading screen it crashed to desktop every time without exceptions 3. Adjusting the IDs it now works flawlessly on both installations. So I figure there it must be a correlation between a) the size of memory TS is using at the moment b) the position in memory and c) therefore a memory leak/illegal access maybe because of odd memory boundaries d) your operating system / Windows version maybe dealing differently with memory allocation - as I seemed to be the only one experiencing issues with PennSteam After all that was a very interesting bugtracking task, and it shows that you have to be careful prematurely blaming DTG. One thing I'd like to see would be some sort of error handling code / validity check that would give me a message like "Corrupt blueprint data in <filename>" and just kicks me to the main menu. Here's part of the blueprint that caught my attention. ID "30" is given twice. It was obviously not created with the blueprint editor, more likely copy-and-paste work. (The Localisation-cUserLocalisedString sections do not actually need an ID, I removed those too. For localisation (creating .lan files) only the <Key> is needed.) Code: <cMixTexDescriptor d:id="30"> <BaseTextureName d:type="cDeltaString">G-Trax\BLE\Environment\Terrain\Misc\Textures\MarkerIndustrial</BaseTextureName> <BaseSpringTextureName d:type="cDeltaString"></BaseSpringTextureName> <BaseSummerTextureName d:type="cDeltaString"></BaseSummerTextureName> <BaseAutumnTextureName d:type="cDeltaString"></BaseAutumnTextureName> <BaseWinterTextureName d:type="cDeltaString"></BaseWinterTextureName> <DisplayName d:type="cDeltaString">Industrial Marker</DisplayName> <LocalisedDisplayName> <Localisation-cUserLocalisedString d:id="31"> <English d:type="cDeltaString"></English> <French d:type="cDeltaString"></French> <Italian d:type="cDeltaString"></Italian> <German d:type="cDeltaString"></German> <Spanish d:type="cDeltaString"></Spanish> <Dutch d:type="cDeltaString"></Dutch> <Polish d:type="cDeltaString"></Polish> <Russian d:type="cDeltaString"></Russian> <Other/> <Key d:type="cDeltaString"></Key> </Localisation-cUserLocalisedString> </LocalisedDisplayName> <Wang d:type="cDeltaString">eFalse</Wang> <FloraIndex d:type="sUInt32">0</FloraIndex> <FloraDensity d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</FloraDensity> <Category d:type="cDeltaString">eMisc</Category> </cMixTexDescriptor> <cMixTexDescriptor d:id="30"> <BaseTextureName d:type="cDeltaString">G-Trax\BLE\Environment\Terrain\Misc\Textures\MarkerResidential</BaseTextureName> <BaseSpringTextureName d:type="cDeltaString"></BaseSpringTextureName> <BaseSummerTextureName d:type="cDeltaString"></BaseSummerTextureName> <BaseAutumnTextureName d:type="cDeltaString"></BaseAutumnTextureName> <BaseWinterTextureName d:type="cDeltaString"></BaseWinterTextureName> <DisplayName d:type="cDeltaString">Residential Marker</DisplayName> <LocalisedDisplayName> <Localisation-cUserLocalisedString d:id="31"> <English d:type="cDeltaString"></English> <French d:type="cDeltaString"></French> <Italian d:type="cDeltaString"></Italian> <German d:type="cDeltaString"></German> <Spanish d:type="cDeltaString"></Spanish> <Dutch d:type="cDeltaString"></Dutch> <Polish d:type="cDeltaString"></Polish> <Russian d:type="cDeltaString"></Russian> <Other/> <Key d:type="cDeltaString"></Key> </Localisation-cUserLocalisedString> </LocalisedDisplayName> <Wang d:type="cDeltaString">eFalse</Wang> <FloraIndex d:type="sUInt32">0</FloraIndex> <FloraDensity d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</FloraDensity> <Category d:type="cDeltaString">eMisc</Category> </cMixTexDescriptor> <cMixTexDescriptor d:id="249"> <BaseTextureName d:type="cDeltaString">G-TraX\BLE\Environment\Terrain\Banks\Coal001</BaseTextureName> <BaseSpringTextureName d:type="cDeltaString"></BaseSpringTextureName> <BaseSummerTextureName d:type="cDeltaString"></BaseSummerTextureName> <BaseAutumnTextureName d:type="cDeltaString"></BaseAutumnTextureName> <BaseWinterTextureName d:type="cDeltaString">G-TraX\BLE\Environment\Terrain\Banks\Coal001_Wi</BaseWinterTextureName> <DisplayName d:type="cDeltaString">Coal Dust001</DisplayName> <LocalisedDisplayName> <Localisation-cUserLocalisedString> <English d:type="cDeltaString"></English> <French d:type="cDeltaString"></French> <Italian d:type="cDeltaString"></Italian> <German d:type="cDeltaString"></German> <Spanish d:type="cDeltaString"></Spanish> <Dutch d:type="cDeltaString"></Dutch> <Polish d:type="cDeltaString"></Polish> <Russian d:type="cDeltaString"></Russian> <Other/> <Key d:type="cDeltaString"></Key> </Localisation-cUserLocalisedString> </LocalisedDisplayName> <Wang d:type="cDeltaString">eFalse</Wang> <FloraIndex d:type="sUInt32">0</FloraIndex> <FloraDensity d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</FloraDensity> <Category d:type="cDeltaString">eMisc</Category> </cMixTexDescriptor>
Torf That is of great interest. Not really. When you run a scenario TS loads the code into the VAS which is then directly loaded into the RAM - The working set. The working set SIZE in the thousands of Scenarios that I have run varies only by less than 5% The problem has nothing to do with size but to do with a memory mismatch between the VAS and the RAM. There are no memory leaks that I have ever seen with TS - in fact most memory leaks will result eventually with A Windows warning and a BSOD - NOT a TS OOM error. Remember RAM is hardware and we see OOM crashes in TS. pH
So it's hard to figure out why it crashes when run in a seperate environment. There's definitely an issue with giving two identical IDs for sorting the items in memory - even TS Tools noticed something was wrong (although the error message was not correct, it led me to the file responsible.) The interesting thing is it is different on different systems. The idea with odd memory boundaries came from the fact that Kuju's blueprints always use even numbers for those IDs (not to be confused with GUIDs) describing blueprint entries - and G-TraX did use odd numbers. In my younger days I did a bit of Assembler coding and you had to be very careful what you do or what number you put in which data/address register / memory address, or confusing bytes, words or longwords (Motorola speak) And what's happening can finally only be known by having the Railworks source code. I'm pretty much just doing reverse engineering and learning something new with every issue. But believe me I was so excited that editing this small file did the trick! My heart was bumping when I fired up TS after editing and watching the loading screen anxiously after having spent many hours on trying to get it to work and figuring out what was wrong... and without TS Tools chances to pinpoint the error were very small considering how many files this DLC has. To summarize: It is BAD DATA crashing TS. And the amount of DLC with millions of files available makes it hard for DTG to fix something. What they could do, and I say again, is to introduce a blueprint validity check before starting the game engine - maybe as a launch parameter if it would slow the system down to much. That would have saved the Ariane 5 rocket too.
Torf I have NO issue with any route crashing. My main OOM's are due to some Scenarios (mainly JT) giving me this spurious error. I'm surprised TS-Tools crashed when you used it - I usually find that if the TS Editor won't open a scenario - TS-Tools will - as Mike uses a different algorithm to edit files ie different to DTG.
I'm out of issues now too - this was the only thing left. TS Tools worked when run as admin...! It had trouble creating a form otherwise... I had this analogy coming to my mind just now. You by some IKEA furniture. You unpack all elements and there is two different ones having the same number sticker. You'll get mad, try to figure out what makes most sense and continue to assemble it. (Or bring it back getting a refund ). So why does TS assemble it correctly in one case, and always incorrectly in another environment. (Full/stripped down installation, and I made sure all assets loaded were the same.) And each one of us has a different collection of routes. Feel free to contact me on scenario issues. Good night.
Just a note on that old thread of mine. It's not important if xml IDs have uneven values, or how far they are apart. They just have to be locally unique inside a blueprint. The BlueprintEditor2.exe does this automatically, but as you cannot import cooked blueprints without their project files, using a TextEditor is common. That's where this happens, by copying an entry and duplicating it, thereby forgetting to manually give new IDs.
