Atomic Systems

To be clear - I am not suggesting people should not PLAY routes/scenarios that use the folder, as a player you have no choice in that matter. You may need to adjust your scenery quality to adapt to memory usage however if you find the content crashes, but this is my general recommendation (i.e. from me and nobody else) as this is the only setting that has any impact on memory usage - and it has an enormous impact on memory usage, e.g. in one test scenario that crashed exceeding memory limits, dropping it to minimum as a test bruoght ram usage down to under 2gb, that's an incredible saving of memory.

My suggestion is for authors to steer clear of it because it increases (to an unknown and unpredictable level because you have no idea what people have added) the risk that your content will crash on someones machine. On the flip side, if the content you want is IN the kuju\railsimulator folder such as a freeware reskin you want to use - then you need to be aware of the impact of bringing that folder on, check your ram usage under maximum "scenery quality" and don't bring in too many other asset folders.

All folders are subject to getting things added, reskins almost always go in the same folder as the product they were based on - but that takes a small folder, adds some small things and really has no ill effect. After a range of freeware addons are installed however the RailSimulator folder however can get hundreds of (admittedly awesome) class 47's, black 5's, hst's etc etc.

I'm not at all complaining about how the situation ended up here, merely guiding based on my knowledge of how the game works, how authors are best (in my opinion) moving forwards in order to make the best of the resources they have available.

and - if my comments are to be taken as anything other than personal thoughts, views and opinions, then no I cannot post here any more, I do not have the authority to post in any official capacity at all.

Matt.

NeutronIC wrote:because it increases (to an unknown and unpredictable level because you have no idea what people have added) the risk that your content will crash on someones machine

Which holds true regardless of whether Kuju\RailSimulator is ticked or not---if a user has a corrupt .bin file for an item a route builder/scenario writer has used then their copy will probably fall over. Of course we can't expect DTG to support these issues; that's where the membership come s in and I'd say that we do a pretty good job of that.
I agree that the Kuju\RailSimulator folder has grown exponentially for some; I recall one member stating he had 70+ class 47 reskins alone which of course begs the question "Why?".... with the dynamic numbering system we have there should be little need for individual loco reskins.
We already have one member who is now contemplating pruning folders---great, now could somebody tell him what to look for? I've 3,300 or so .bin files in my Kuju\RailSimulator folder and have no issues so is the threshold 3,400? Would someone with 3,100 but running with different settings/hardware have bother? There are just too many variables and no clear guidelines to enable anybody to properly evaluate the best course of action.
(Just for information, the number of .bin files in a default installation of Kuju\RailSimulator is around the 2,700 mark)

Just a question, can items be moved out of a folder to stand alone, as we have a number of routes that contain traction, ie. Brighton mainline class 377, South West Coastal class 175, GEMl class 360. can the traction be moved out of the asset folder to standalone so that only the traction asset is used rather than ticking the route folder., as this would save memory.

david1 wrote:Just a question, can items be moved out of a folder to stand alone, as we have a number of routes that contain traction, ie. Brighton mainline class 377, South West Coastal class 175, GEMl class 360. can the traction be moved out of the asset folder to standalone so that only the traction asset is used rather than ticking the route folder., as this would save memory.

No, because there will be pointers to the necessary folders/files that will be in the original locations. However, you can move out the unrequired folders/files (temporarily), clear the caches, and run. My working version contains only the routes that I am working on, and the essential assets from the developers I have chosen. When I select a scenario to run, I make sure that extra files are temporarily moved. Loading times are much reduced (the time saved is more than the time taken to remove then restore files).

david1 wrote:Just a question, can items be moved out of a folder to stand alone

Probably not---DRM would likely kick in and you'd get a corrupted screen. Those folders though should be small enough (in terms of .bin files, as that's what I've used earlier) not to cause issues. Which brings us back to the great unknown.....how many .bin files (assets/whatever) does it take to become something to keep an eye on?
Brighton Main line incidentally has about 1,200 .bin files in it.

Copying the stock's .bin files out may work, but who's going to decide on the best directory structure for such a venture?
Just tried with the .bin for a reskin of the Brighton 377 copied out to a ..\Assets\Rolling Stock\ EMU folder and that worked OK, or at least was place-able in a route and didn't need the main BML asset folder ticking. That still brings us back to the burning question though, how many .bin files can a folder house before it gets 'iffy'? as it'd be very easy to copy too many files over.

Nick...an unedited copy of the .bin would still point to the *right* location for the rest of the files.

EDIT:....it didn't work with a class 35, noting showed until the DTG\Class35Pack01 P/P boxes were ticked. Of course if it had worked it'd be a hell of a job getting every scenario edited to point to a new location for the .bin files, effectively making the idea a non-starter.

gptech wrote:

david1 wrote:Just a question, can items be moved out of a folder to stand alone

Nick...an unedited copy of the .bin would still point to the *right* location for the rest of the files.

EDIT:....it didn't work with a class 35, noting showed until the DTG\Class35Pack01 P/P boxes were ticked. Of course if it had worked it'd be a hell of a job getting every scenario edited to point to a new location for the .bin files, effectively making the idea a non-starter.

My thoughts were that you keep the "Rail Vehicles" folder, and move out all the other folders in the Asset/Developer/Route name that were not needed in the scenario. The cache would then be substantially smaller.

Gary
Just a thought - don't Just Trains in a lot of their stuff use the KUJU folder for assets.
Their DLC is pretty good.
They seem to fix any issues pretty quickly but I doubt that they modify the KUJU folder in any way?
IMO this folder only becomes a problem when it is "corrupted" by perhaps a not so robust add-on?
Comparison
Kuju Folder 11 GB in size - no issues
DTG Folder 24 GB in size - no issues
RSC 53 GB in size - no issues
So why don't the latter 2 folders crash being more than twice the size of KUJU?
I do not believe it relates to size at all - its more to do with some corruption of the data/code in that folder.
pH

It isn't the product folder, it's the provider folder.

Kuju\RailSimulator is what you should check

vs, for example

RSC\BrightonMainLine

The game doesn't care how much you have total in each provider at all, only how much is in the sum total of all the products you've ticked in the route and the scenario you're running on that route combined, regardless of which provider folders they're in.

Corrupt files certainly cause problems - but they're the other main cause of problems, with Out of Memory being the other.

Matt.

NeutronIC
Good points - but honestly I have never had a problem with the Kuju folder.
Yes the \kuju\railsimulator folder is around 10GB (but no addition since February 2016), and the \RSC\BML is less than 2 GB - quite a difference!
I haven't verified the cache since TS2012.
TS2017 seems to very stable until you start "messing" with it!
The editor seems to cause issues and that be another part of this puzzle.
Roll on TSW UE4 which hopefully will be able to access up to 8 Terabytes of VS.
Regards
pH

UE4 is 64 bit, so it'll do whatever 64bit apps can do

Matt.

Just wondering if anyone has a quick miracle fix for TS2017

When I run routes such as GEML, ECMLS, Liverpool to Manchester, WCML Trent Valley, DPS ECML I need to reduce the scenery quality setting from max to one notch above minimum to prevent me running out of memory.
Not every scenario requires this however, I tend to do it when there is lots of AI and when the track has OLE modelled.

The other option is to save at every station stop if I want to keep that setting on max. This helps to reduce some of the main causes of crashes as the AI will usually run into portals and disappear over time.

The game doesn't even look that bad with the scenery quality setting on low, it's mostly just the older stock inside the Kuju folder that look bad. All the latest DLC looks much better on lower scenery quality settings in comparison.