Atomic Systems

Using lots of different providers each with only a modest amount of assets would allow a route to run fine. Loading one provider with masses of assets (e,g Reskins etc) would cause a crash. In the former case using lots of unecessary providers, RW Tools may sort it out by deselecting unneeded providers. In the latter case only removing assets will help or if the Kuju folder downloading a clean copy will often sort it.

Presently I have a few separate Kuju folders pending getting time to do a massive sort out by using RW Tools to tell me what I need for scenarios and what I don't.

TransportSteve wrote:

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 spec. of the computer is not relevant. If I write a program capable of storing 10,000 items in memory it will run on most computers. If I had a super computer it would still only hold 10,000 items and go wrong if I have 10,001. Exactly the same will happen with a laptop or any computer. The limit is with the software not the hardware being used. The same way as a 32bit program is not able to address the same amount of RAM as a 64bit program. It does not matter if I run it on a 64bit super computer. My 32bit piece of software is simply not able of using all the resources my computer has available.

For the same reason I can have 100 developer filters enabled each with a few hundred assets in each. This might not be a problem if the total number of assets available to the route is under my imaginary limit of 10,000. I could have another route with only 5 developer filters enabled. However, each of those developer filters contains a large number of assets and I exceed the 10,000 limit causing the SBHH.

I have experienced this with my own route. The TPR route is a 100% freeware route being worked on by a team of people. It is very extensive. As such I used to have a lot of developer filters enabled. Some members of the team started to experience SBHH way back when TS2012 was around. I eventually tracked it down to the number of assets some team members had installed. We obviously all had the same route and the same dev filters enabled. However, some team members had many more assets installed than others, pushing them over the limit of the game. My own personal computer is not very good yet I had no problem. Some of the team members have very nice computers yet they had the problem.

I have fixed this on TPR by getting permission from many freeware developers to clone their assets into our own TPR developer folder and then disabling as many developer filters as possible. This is effectively what RSC do with their routes. Recent RSC routes have the assets required in a dedicated developer folder. The route now loads and works for all team members, even those with huge asset folders and very large kuju folders. The route DOES use Kuju and on some of the team members this is of a significant size. However, because most of the assets have been isolated in our TPR developer folder we are able to keep the route working.

Apologies for the long explanation. I have encountered (and reported this to RSC) quite a long time ago. Just checked my emails and it was way back on 26th September 2011 when I reported it to RSC. Due to the size and scale of TPR we were probably one of the first people to encounter the issue. I have also assisted fixing a number of routes where this was a problem so I would describe myself as being very confident that the cause is the number of assets rather than any one folder in particular.

There is a simple test to this.

If you have a large kuju folder and some routes are SBHH'ing. Create a brand new route and enable the kuju folder. Save and exit the game. Reload the game and see if the route loads without SBHH. If it does then the Kuju folder is not the cause of any SBHH's as you have successfully managed to create a route with the kuju developer filter enabled.

Of course a very large kuju folder increases your chances of experiencing the problem as most freeware routes have it enabled and thus the Kuju folder by itself might be using up 50% (or more) of out imaginary 10,000 limit.

Not sure I can explain it any more I of course could be wrong but I don't think I am. Feel free to experiment and find out what you can but so far over the 18 months I have been aware of the problem all my findings have pointed to the number of assets available to a route being the cause.

Jim

Agrees with my findings Jim. I started seeing this a couple of years ago and at first assumed it was corrupt assets. However when over time more routes got impacted I linked it to number of assets loading, Like many in the early days I downloaded lots of reskins and also had to install even more for loads of scenarios.

I now find splitting Uk, European and US routes over separate folders to reduce the asset count in any one set up.

My real 'beef' is that RSC knew of the issue but said nothing and in response to queries sent the usual , clear cache etc support e mails when that was never going to sort the issue.

Still we are where we are and all we can do as users is to manage the problem as best we can in our own way.

chrisreb wrote: My real 'beef' is that RSC knew of the issue but said nothing and in response to queries sent the usual , clear cache etc support e mails when that was never going to sort the issue.

Mine too, Chris. I couldn't have expressed it better than you've done.

Meanwhile, we have another multi-page thread with many very well-intentioned attempts to help people. Some work, some don't, and kudos to those who've taken the time and made the effort to assist the community. But, based on the varying degrees of success different people have had with the suggested solutions, it's pretty clear to me that there is no one-size-fits-all fix. Further, any direction of blame at end users for having very large Kuju folders is totally inappropriate. RSC never alerted the community that this was an issue, or that changes were to be made to the core program that would break routes and scenarios if this were the case.

The problem is squarely in the lap of RSC and they've elected to remain mute. Shame.

It's an issue on a number of routes. The withdrawal of DLC and its reintroduction today is to "de-kuju" stock, particularly sounds, couplings etc i.e. RSC are implementing a work around instead of fixing the core.

TS12 and TS13 became increasingly sensitive to this. Basically we now need Train Store to RW, which frankly is a sign of failure as a product IMHO.

Whilst I love this sim, I'm getting to the end of tolerance. RSC please prove me wrong.

B

bdy26 wrote:It's an issue on a number of routes. The withdrawal of DLC and its reintroduction today is to "de-kuju" stock, particularly sounds, couplings etc i.e. RSC are implementing a work around instead of fixing the core.

TS12 and TS13 became increasingly sensitive to this. Basically we now need Train Store to RW, which frankly is a sign of failure as a product IMHO.

Whilst I love this sim, I'm getting to the end of tolerance. RSC please prove me wrong.

B

We don't want you near the end of tolerence - all those wonderful route updates (nudge!).

Agree each sucessive update gets more sensitive to this issue for some reason

JustRight wrote:

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 Trevor,

Run the Check Route option and when it asks you if you wish to see a list of shapes used, then answer Yes. The Fix Provider/Product is on the bottom of the list of shapes - The program needs to know what shapes/lofts etc your route uses before it can fix your RouteProperties.xml file, so this seemed to be the best place to put the button.

Mike

mikesimpson wrote:Hi Trevor,

Run the Check Route option and when it asks you if you wish to see a list of shapes used, then answer Yes. The Fix Provider/Product is on the bottom of the list of shapes - The program needs to know what shapes/lofts etc your route uses before it can fix your RouteProperties.xml file, so this seemed to be the best place to put the button.

Mike

Cheers Mike, found it!

Seems a reasonable place to put it once I located it.

i have found that when my kuju folder gets above 12gb i cant run some non USA routes so i Make a folder called Kuju usa and put all the US files in it and my uk and europe routes work then because the kuju file has dropped to 10 gb or less. then if i want to play a usa route i just cut/ paste the US files back into kuju file. only takes a few seconds to do it too, but i also have a backup of files just in case

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.

Jim[/quote]

Hi Jim

I had approx 30 scenarios on various routes which all gave SBHH when loading and I tried everything I knew to make them work but got no joy so I left them alone for months.
On reading your post (above) I did what you suggested and now all the promblem scenarios load and run perfectly!!
Many thanks for sharing this tip on the forum.

Regards

Jim

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.[/quote]

Just checked mine and its 12.5 GB,

I get SBHH occasionally, but not as much as used to happen

Colin