Atomic Systems

So, I just found out that my Kuju folder is over 11Gb. That, I think, must be the reason why I can't drive, for example, through the WCML after installing the AP's Class 90 and why I'm having some SBHH messages on other scenarios in which I have to use files located in the Kuju folder.

So, to those who have done this successfully, what should I delete? And which size should the Kuju folder be in order to make TS2013 work properly?

Thanks in advance

I too had problems with the AP/Waggonz c90 pack where the scenarios would cause a SBHH everytime ... I asked for support from AP & one of the suggestions was to slim down the ol' Kuju folder ... Rather than fuss about wondering what to get rid of I followed advice from elsewhere on the net and copied my WHOLE Kuju folder elsewhere, to a 1TB external drive in my case & renamed it something like 'Kuju Archive' ... the simple thing to do then is choose the 'verify' files option in TS2013 from within the Steam menu, this will give you back a default kuju folder with just the basics plus anything required by the stock packs you've purchased from Steam ... That should get the c90 up and running, about 4GB it became down from 10GB in my case ...

Of course your 3rd party sceanrios & even other AP extra stock packs will now cry out for items from the old Kuju folder when you try to run them, RSTools will tell you what's missing from problem scenario, it's just a case then of copying what you need, when you need it from your old Kuju folder (safely moved elsewhere) and copying the stock you need back into the new, slimmer Kuju folder !

I'll add that to be on the safeside myself I deleted my whole WCML folder before running the 'verify' files option just to be extra sure things went ok, so if you follow the above & still have issues you could try that also, I then re-installed the c90 pack, all my previous AP purchases and extra stock, plus anything purchased from Just Trains & 3rd parties just to make sure the basic stock from those packs was back in the Kuju folder

I've removed all the repaints I don't use by now and have a nice archive of everything I've previously installed should I need it later on, I'd imagine that installing any of the 'free' packs from UKTS will start filling up the Kuju folder once again, maybe RSC can work on the core software to allow it to deal with these big directories ? Or do something to smooth the software out so it loads what it needs etc ... hope this helps anyway !

It's my belief that there is some misunderstanding about what is happening here. It is not just and solely the size of the Kuju folder that matters. It is the total of all the assets called from all the asset folders that matters.

For instance, check the size of your RSC folder. If a scenario calls, say, the Kuju, RSC and several other folders the amount of data becomes overwhelming.

Culling from the Kuju folder may help because it may lower the data calls below a critical level. A better solution is to thin out all of the most bloated asset folders as much as possible.

A final solution may be for RSC to change the way a scenario references assets so that only the specific assets needed a loaded?

John A

And this is not helped by RSC selling one livery at a time meaning you need to tick more asset boxes to use a single loco on a game that crashes if you tick too many boxes. My Kuju folder was only 5GB so the Kuju folder is not the only cause but it helps not having it too large.

Yeah, I redownloaded a clean Kujunk folder then went to work separating all my routes into separate folders Content.German etc, making a copy of the default Kuju then adding all the necessary assets used for those countries routes, you need a big drive to put the steam folder on but it works by keeping the folders down in size.

A thought has just come to mind as to which Kuju folder should be active at the time RSC rolls out the new TS2014. Then again we will have to go about coping files to and fro to make some routes and scenarios work again.

I have the original Content & Asset folders renamed .all, just have to make sure on that date they are swapped back!

jarmstro wrote:It's my belief that there is some misunderstanding about what is happening here. It is not just and solely the size of the Kuju folder that matters. It is the total of all the assets called from all the asset folders that matters.

For instance, check the size of your RSC folder. If a scenario calls, say, the Kuju, RSC and several other folders the amount of data becomes overwhelming.

Culling from the Kuju folder may help because it may lower the data calls below a critical level. A better solution is to thin out all of the most bloated asset folders as much as possible.

A final solution may be for RSC to change the way a scenario references assets so that only the specific assets needed a loaded?

John A

Hi John,

This is not quite correct, it is not the size of the Kuju folder which is the problem, it is the size of the Kuju\RailSimulator folder which contains all of the assets for all of the default UK/German routes. So if your route only includes a single asset from Kuju\RailSimulator, TS2013 has to open EVERY asset in that folder tree when it starts up. Whereas in the case of RSC, they have separate folders for each of their route's assets so only the assets actually used by a RSC route are actually opened on startup.

So if your scenario calls for say Class 33 locos then only the RSC\Class33Pack01 is opened, whereas if a Black 5 is used, then Kuju\RailSimulator is opened.

Of course if a scenario uses large numbers of rolling stock types from different RSC packs, then they are all opened and you can still be in trouble.

Mike

Hi Mike
I think that both John and you are correct.
I have one install which is all default DLC and the Kuju Folder is 8GB in size and the Kuju\Railsimulator folder is 6.7GB. - No issues
Now on my other rig where I have used 3rd party add-ons from UKTS, RWA etc this has ballooned out to 11GB and 8.9GB respectively - SBHH on occasion.
This shows to me (in my case) that a lot of the third party stuff is loading into the KUJU folder
Then I noticed in the latter case using RESMON it was showing significantly more hard page faults than the default installation.
This could lead to the VAS being depleted and/or not have enough contiguous space for TS 2013 to continue loading into - result SBHH.
I then tried to monitor invalid page faults but could not find a suitable method (TASKMON possibly) because if you get one of these it would immediately trigger a SBHH error.

Again size could be a factor because TS2013 might be trying to "sift" and load far too much data that it could handle, and there may be mismatches in the data in that folder that trigger some fault in the system causing a SBHH.

Just an opinion.

PeterH

@Mike

Thanks for that very clear explanation. I understand things better now.

@Peter

I certainly find that SBHH prone scenarios are much more likely to SBHH if I've been running other routes/scenarios beforehand. If I clear cache then reboot PC and go straight to the touchy scenario it will inevitably run clean. I seem to remember the term 'Memory Leak' from a few years back. Could this be what is occurring?

Regards
John A

I have also found that if you pause a scenario rather than save, especially if using the Taurus, I then drop it to the taskbar and put the p.c to sleep if I have something else to do, on re-starting I have no problems and the memory used drops to boot.

JohnA
Yes on some routes/scenarios the VAS is not always "cleared" (VMMAP) after they are finished and if you do not clear the cache then you have a defragmented VAS or it is depleted and you usually see a lengthened loading time and if worst comes to worst a SBHH. Physical RAM, cpu cache and the paging file seem to be unaffected - I couldn't find a memory leak. Except on one occasion I was using process monitor to see what was causing a "Kuju" issue and suddenly the RAM usage rose to 100% and I had to reboot to get going again. Hmm.

I have got into the habit of clearing the blueprint cache at the end of every scenario and that seems to alleviate the problem. Funnily enough the later "complex" routes don't cause a problem.

Regards
pH

Hopefully, they'll fix this in TS2014. Together with the, sometimes, faulty TSX feature. It's quite annoying sometimes, specially when some textures start "mirrorizing" the windows and headlights

Guess we'll have to wait.

I have also had to slim down the Kuju folder. Is it only the WCML which is causing the problem? Or has it happened on any other routes?

Dean

Is someone clever enough able to do a simple step by step (fool proof) description of trimming down the Kuju folder?

And mods... can that be made sticky for future reference?


--
I would also like to see a sticky thread (locked if necessary) on how to access and edit workshop scenarios - some of those I have subscribed to use DLC no longer available and I would like to use RW Tools to swap out the stuff I can't buy and put in stuff I already own as a replacement to let me play the scenario.


Thanks