Thoughts on P/Ps

[BobLatimer]

There are several threads discussing the issue of “bloated” folders and the problems they cause, mainly SBHHs. I’m going to try to consolidate my findings on the subject here.

The main problem is caused by P/Ps (Provider/Product folders, e.g. Kuju/Railsimulator) that contain a large amount of content.

Note that it’s not a problem with the size of the Kuju folder or the size of the RSC folder. It’s a problem with the size at the P/P level, e.g. Kuju/Railsimulator.

The problem arises when a route and a scenario combine to “call” a large total amount of content contained in the P/Ps selected. (Not,e that is “selected”, which may not be the same as “required”.)

One way to mitigate the problem to some extent is to make sure that only those P/Ps that are actually required are selected. In some circumstances I have found that de-selecting the non-required P/Ps will actually solve the SBHH problem.

Even after doing this, the P/Ps actually selected and required can combine to be a large enough total amount of content to cause an SBHH.

The solution that I have come up with is to first deselect the non-required P/Ps and then remove, from the larger P/Ps in my installation, any content that is not required by any of the routes and scenarios that I have installed. In my case these were Kuju/RailSimulator and Kuju/RailsimulatorUS. After working through that process, with the invaluable help of the latest version of RW_Tools, I am no longer getting SBHHs.

However, these are really only short-term solutions and not all users are capable of implementing them. It is possible, perhaps even likely, that in the future a user who has a very large amount of content, or a route-builder who wants to include items from a large number of P/Ps will run into “overload” SBHHs, even after going through the procedure outlined above.

The people at RSC have apparently been aware of this problem for some time (although they don’t seem to have made that awareness public) and, as a result are not putting new content into the Kuju folders any more. They are making each new route “self-contained” by including all the necessary assets in the route’s own P/P, rather than having to select one or more of the Kuju folders.

A longer term solution needs to be found. I doubt that RSC will participate in this search for a solution, since it (currently) doesn’t affect DLC.

Bob.

[briyeo1950]

Is it at all possible for community routes to do the same as RSC are doing with their routes? I don't really know what I'm talking about here, so I'm probably going to sound naive but.
You can't share a route publicly were you have moved Kuju or any other developer assets into a route specific folder, but is it possible to have a program that can do that for the end user in his own installation providing he legally owns all the required assets. I was just wondering, having seen what a simple (to some anyway) batch file is able to do within Railworks.
Would such a program infringe the EULA? Everything we do seems to do that though. Maybe something could be arranged just with the Kuju folder, that seems to be the major problem for routes.

[nobkins]

It is a nice idea but I think we would hit issues with EULA now that the Kuju\RailSimulator folders are part of the EU Asset Pack which is not free to those who are new buyers of TS2013.

For TPR I had the same issue (SBHH on some team members computers as they had a lot of content installed). I have resolved this and made TPR much more stable by seeking the permission of those freeware authors who allowed me to use their assets to clone only the items used into the TPR developer folder. Every freeware developer who I have been able to contact has generously granted me permission to clone their assets so I now have very few dev filters enabled. I still have the Kuju\RailSimulator filter enabled but by putting (where possible) the assets into my own developer folder it seems to have improved things greatly.

I even wrote a little script to parse the route and modify all the entries to point to the new cloned assets instead of the original. Unfortunately the cloning of the assets has to be done by hand and it has taken almost a month of steady work to get sorted.

Basically I think what I am trying to say is that it is not essential to clone Kuju\Railsimulator items. TPR (which uses a lot of assets) is now very very stable just by greatly reducing the number of enabled DEV filters and cloning only the used assets (where we can get permission) into our own developer filter.

Jim