Atomic Systems

There could be something in this, my Normal Railworks/Kuju Folder is 13.9GB and I get frequent Crashes, no on my Clean RW Install the file is only 4.3GB and i rarely get any crashes.

@gptech. Sorry, forgot to say that I definitely agee with Mike Simpson. In fact, he and I worked on it together.

Bob.

@antonyperks There definitely is something to it. Check out the "Is TS2013 more "Fragile" than TS2012?" and "Problems with 3rd party routes in TS2013 with SBHH." threads.

Bob.

BobLatimer wrote:If anyone else has a total Kuju folder of more than, say 12Gb and doesn't get SBHHs after running the RW_Tools "Fix Prov/Prod" on the route involved, would you please post here the sizes of your Kuju\RailSimulator and Kuju\RailSimulatorUS folders. This will help either prove or disprove the theory.

Bob.

Hey Bob,

Just where did Mike hide the "Fix Provider/Product" button? I must be suffering selective blindness as I'll be damned if I can find it. (I'm using v4.0.47 of RW_Tools)

Cheers,
Trevor

Hi, I suspect that it has a lot to do with the size of the blueprints.pak files for the providers increasing with the number of assets in the folders. I can't see the folders themselves being loaded into RAM - my KUJU folder is bigger than the 8GB of RAM in my system. I am assuming that lots of cache files in memory reduces the amount available to the main programme & causes issues. Just my opinion anyway!

Edit Check route - view shapes- then button becomes available

JustRight wrote:Just where did Mike hide the "Fix Provider/Product" button? I must be suffering selective blindness as I'll be damned if I can find it. (I'm using v4.0.47 of RW_Tools)

Cheers,
Trevor

Hi Trevor

Just run through all of the various options in the Check Route section - fix providers is on one of those screens. Most people (like me for a while) don't find it because they exit the Check Route function after the first set of tests.

EDIT - Mark beat me to it!

Ash

Hi All

I thought I should give you a progress Report.

With tremendous assistance from Bob (Latimer) and utilising RW_Tools I have commenced the "Marathon" effort as I have 69 Routes Installed and just about every available Scenario for these Routes from UKTS and Steam Workshop.

My orignal Kuju Folder comprised :-
11.7GB
41,242 Files
5,040 Folders

Currently my New Kuju Folder comprises (after I have checked out 11 of the 69 Routes) :-
4.34GB
18,194 Files
1,357 Folders

Once I have completed checking out all the 69 Routes I will then run each Route again through RW_Tools and Fix the Route Properties.xml Files

Regards

Mike

I am not sure if everyone has realised that it is not a bloated kuju folder that is the cause. A large kuju folder is certainly a contributing factor. It is the total number of assets available (and therefore indexed) to a route that if it exceeds an internal game limit will cause the route to SBHH upon loading.

As the Kuju folder is one of the largest it contributes more to the number of indexed assets (if the developer filter is enabled for Kuju) more than most other developer folders. However, I believe the what triggers the SBHH is the number of assets available to a route (and therefore indexed) and NOT any single folder in particular.

For those people struggling with SBHH when a route loads then the best place to start when trying to fix the issue is to rename your kuju folder to something like kuju_old. Then do a verify cache in steam to make the kuju folder re-download and therefore be 100% default content only. Once you have done this try to load the route that was SBHH'ing. If it loads then you have probably fixed it by reducing the number of assets that route has access to (by using a 100% default kuju folder).

Hope that clarifies.

jevon wrote:Jim, your use of the term "mystery limit" suggests that RSC has still not published specs relevant to the issue.

I am not aware of them publishing specs on this issue.

jevon wrote:Is it that they simply don't know?

I don't know as I do not work for RSC.

jevon wrote:Were the programming changes that created this problem botched in some way and they're looking for a fix?

I had experienced the issue first in TS2012 so it was not introduced with TS2013. I suspect (but do not know) that it is an issue that has always been there but did not reveal it's existence until the amount of freeware content installed to the Kuju folder has grown. The freeware packs install a lot of content to the Kuju folder so they are probably a contributing factor also.

jevon wrote:Has RSC even acknowledged this as a problem? Does anyone have hard information on this?

I have reported it and that report was acknowledged. Not sure if that is the hard information you require.

Thanks

Jim

nobkins wrote:For those people struggling with SBHH when a route loads then the best place to start when trying to fix the issue is to rename your kuju folder to something like kuju_old. Then do a verify cache in steam to make the kuju folder re-download and therefore be 100% default content only. Once you have done this try to load the route that was SBHH'ing. If it loads then you have probably fixed it by reducing the number of assets that route has access to (by using a 100% default kuju folder).

Hope that clarifies.

Excellent and timely advice as I've been having a few problems recently and my kuju folder has grown pretty large so I'll give your advice a try.

Thanks.

It could take a fair bit of downloading so if you don't have unlimited bandwidth then this could use approx 3Gb of bandwidth. Also any content that was installed into the kuju folder that is not distributed using steam (mostly freeware re-skins) will be lost and will require re-installing.

Just FYI.

JustRight wrote:Just where did Mike hide the "Fix Provider/Product" button? I must be suffering selective blindness as I'll be damned if I can find it. (I'm using v4.0.47 of RW_Tools)

Run Check Route - when the first stage completes and the missing shapes report shows up, exit and choose to view the list of shapes. Then click on List Providers & Products Used - this gives you a button to Fix Prov/Prod.

Yo!! Found it!!

Thanks Mark, Ash and Alan

Just as an aside, I believe that RSC would have to know just what this 'limit' actually is. They have access to and control of the core program. You can bet it will be some fixed size Data Area, Array, or Memory Table that they either cannot, or will not, increase in size. As Jim has said, this is more a function of the sheer number of assets that the program has to 'index' when it loads a Route/Scenario combination.

This problem certainly existed in TS2012. I had started a personal project whereby I had moved ALL of the KUJU rolling stock out of the 'Railvehicles' folder and into separate Provider/Product directories. I was editing all the associated BIN files modifying the relative path references, including the GeoPcDx files. All this was going swimmingly, until I got to the much larger GeoPcDx files contained in the locomotive directories. It was then that I discovered that the version of SERZ.exe that RSC provide cannot re-pack these larger GeoPcDx files. You can unpack them and edit them, but not regenerate the GeoPcDx file.

None the less, I had quite some success with doing all the Freight items, and fixed many of my SBHH errors. But then TS2013 was coming along, and I foolishly hoped that RSC, being aware of this problem, might implement a code fix. But it was not to be.

What we have now is that RSC are using the same workaround I tried to implement for the KUJU folders. That is, separate Provider/Product directories for each 'Pack'. In fact they have been doing this for ages. This minimises the number of assets that the program has to load or 'index' for a given Route/Scenario. I would bet though that if you created a Scenario and ticked a fair number of the RSC Provider/Product check boxes that you could crash the program with an SBHH just the same as having a large number of assets in the KUJU directory tree.

The fact that RSC have not repaired this flaw suggests that it is a real problem in the core code that cannot be simply 'increased' in size. Some fundamental limitation in the design that they have found it simpler to work around rather than rectify.

Cheers,
Trevor

nobkins wrote:It could take a fair bit of downloading so if you don't have unlimited bandwidth then this could use approx 3Gb of bandwidth. Also any content that was installed into the kuju folder that is not distributed using steam (mostly freeware re-skins) will be lost and will require re-installing.

Just FYI.

I have a fast connection and no problem with bandwidth so I'll give it a try soon. I went a bit crazy downloading freeware stuff after paying my money to join here so it's needing a clear out anyway

nobkins wrote:I am not sure if everyone has realised that it is not a bloated kuju folder that is the cause. A large kuju folder is certainly a contributing factor. It is the total number of assets available (and therefore indexed) to a route that if it exceeds an internal game limit will cause the route to SBHH upon loading.
As the Kuju folder is one of the largest it contributes more to the number of indexed assets (if the developer filter is enabled for Kuju) more than most other developer folders. However, I believe the what triggers the SBHH is the number of assets available to a route (and therefore indexed) and NOT any single folder in particular.

Hope that clarifies.

Jim

Yes, but, I've got some big freeware routes installed from Britain, Europe and America that have maybe 30-40 different asset folders ticked, and don't have any problems with SBHH's.
I don't dispute your theory, but, as we all have different OS and CPU/RAM/Graphic card specs, surely, someone playing on a medium/high end computer won't have half as many problems as someone playing the game on a little girl's laptop, because we have capable machines to cope with the heavy graphical detail, etc.

The other thing that has already been mentioned over the years before on this forum is that in the scenery assets packs that accompany routes they are full of content complete with .cost and .tgt files, baks and blueprints files that undoubtedly get installed because everyone makes use of the package manager for simplicity, instead of looking inside every asset folder, utilising 7-zip, or, a similar tool, to extract all the ''rubbish'' inside 'em beforehand. For example, in 12 freeware routes I've obtained they all contained different assets created by Ice, every one of his folders contained ''fluff'', and I had to manually go through about 95 of them before I installed the clean folders onto my hard-drive, and I've currently got 170 folders of content from Iceman, as he's a prolific asset creator of high quality content. If folks have between say 350 - 500 asset folders on their hard-drives, have they cleaned them all out of the unwanted rubbish, I bet they haven't, if folks did some housecleaning of ALL folders and then defragged their systems accordingly, so, all folders/files are clean and together maybe the SBHH's might decrease if their system is only looking for a couple of files instead of the hundreds of rubbish ones also present in individual folders, this is where a lot of the bloatware also comes from, I'm sure, and if folks haven't cleaned their folders and never done a defrag in years, no wonder they're having problems, keep your installations clean and tidy and free from rubbish, time consuming yes, but, worth it.

Cheerz. Transport Steve.

I guess I wouldn't mind the time to do the cleaning, but I have no idea what is rubbish and what isn't.

It is possible that I don't have many SBHHs because I am running a high end system. That really can't be ruled out as a factor, I don't think, particularly given my experience with FSX.