Duplicated Files

[nuthatch]

I am rapidly running out of hard disc space on 'C' drive and cannot upgrade to a better computer at this time. However on running File Finder on CCcleaner I appear to have a very large number of duplicated files particularly with Railworks. These range from a single duplicate to some files having fifty five or more. Within each file the line details show identical information even to the dates created. My question for the experts out there, is can I get rid of the duplicates without compromising my Railworks installation? Their MB lengths vary but added together they would free up a great deal of disc drive space. If this is possible is there a quicker way than ticking each box in CC cleaner? I have RWTools. My thanks for any help that can be offered, Bill B.

[nobkins]

In short the answer is no.

Let me use the Class 37 Diesel to explain.

For every version (skin) of the class 37 many files need to be duplicated. However, if each file is not present in the correct location for that skin then you will get missing textures. This means that it takes up a lot of disc space but if you want it to work you need to keep the files even though they could be identical apart from the folder they are located in.

Jim

[Easilyconfused]

I would say that is a very bad idea and asking for trouble. The files are there for a reason is most cases and once you start deleting stuff, especially with an automated tool you are in for no end of trouble.

I use CCleaner myself but only to remove the files I am confident I don't need like hundreds of MB of internet cached stuff today.

[nuthatch]

Thanks for your swift replys and for saving me from myself, much appreciated, Bill B.

[firetrap1]

You could try purchasing an external plug in and play hard drive and move all your video and pictures and music onto it. I have over 1TB of media on my seagate external HDD. It's quite fast and only cost £45 two years ago. Prices have got better now as well.

[mikesimpson]

Unfortunately, since RSC worked out that the original Kuju folder was getting far too large, and that the idea of a single place to keep Assets was unworkable. They have now started adding identical files to each route they produce. e.g. the Scenery\Vegetation folder is very large and contains virtually the same files in every route they produce.

It would be possible to point the Scenery .bin files in each route to a single Vegetation folder, but the work involved would be huge. As already stated, it would be better to just buy a plug in USB disk and put all your photos/videos/music on it.

Mike

[shanyiqua]

For repaints the files need to be duplicated. However the most of the files that are duplicated are identical. A big part of the Kuju packages are included with each routes, same files over and over.
And the reason for it are these: http://store.steampowered.com/app/208300/
http://store.steampowered.com/app/208306/
http://store.steampowered.com/app/208301/
http://store.steampowered.com/app/208302/
http://store.steampowered.com/app/208307/
and the other old, originally bundled contents.

[shanyiqua]

Unfortunately, since RSC worked out that the original Kuju folder was getting far too large, and that the idea of a single place to keep Assets was unworkable. They have now started adding identical files to each route they produce. e.g. the Scenery\Vegetation folder is very large and contains virtually the same files in every route they produce.

It would be possible to point the Scenery .bin files in each route to a single Vegetation folder, but the work involved would be huge. As already stated, it would be better to just buy a plug in USB disk and put all your photos/videos/music on it.

Mike

Kuju folder doesn't really changed since Railworks 1 was released. Anyway, you can reference on multiple folders, so you don't need to put anything in kuju. This is how it was before TS2013, Kuju assets were referenced in every route, but the new/unique assets were placed in the route's own folder. Now everything is placed in one folder duplicating a lot of files, and making things more chatoic(back then the route editors knew which assets could be found in which package, but now...). So the reason for that change was something else...

[gptech]

As the guys have already said, many files are duplicated for a valid reason so these are best not deleted but there are a number of files we all 'collect' that can safely be junked.
Assets don't use .xml files, which are often left in reskin packages: files with the .bak extension are usually back-up copies generated by RW Tools so once you have a newly installed skin running OK these back-up files can go: temporary files left by modelling programs often have the extension .cost; once again you don't need these.
Routes however DO use .xml files so don't delete any you find in the Content\Routes folders but .bak files from here can also be safely consigned to the bin.

All this deleting of 'junk' can be nicely automated by using a batch file (.bat), there have been many examples posted in the forum so a search to see what others use could be worthwhile----to set the ball rolling I have a file named ClearJunk.bat in my Assets folder which is only a text file containing a few DOS commands:

Code: Select all

del /s *.pak
del /s *.tgt
del /s *.cost
del /s *.bak
del /s *.xml
pause

the * character is a 'wild card', it just means 'anything, whether it's a single letter or a paragraph' so 7.pak will be dealt with in exactly the same way as reskin_of_loco_number_7.pak
working through the list of file types it gets rid of, .pak are the games cache files,
.tgt and .cost are temporary files left by modelling programs,
.bak are the backups as mentioned earlier,
and .xml files are just the redundant .xml versions of .bin files.

If you copy that lot above, or just the lines you want to use, into a new text file in your Assets folder and then rename that text file to something that makes sense to you with the .bat extension you'll have your own junk deleter for your assets folder. You can create a desktop shortcut for the batch file, so that you don't have to drill down the folder structure in Windows Explorer every time you feel the need to tidy up a bit.

[mikesimpson]

Kuju folder doesn't really changed since Railworks 1 was released. Anyway, you can reference on multiple folders, so you don't need to put anything in kuju. This is how it was before TS2013, Kuju assets were referenced in every route, but the new/unique assets were placed in the route's own folder. Now everything is placed in one folder duplicating a lot of files, and making things more chatoic(back then the route editors knew which assets could be found in which package, but now...). So the reason for that change was something else...

The official Kuju folder has not changed, and is around 4 gigs in size. What I referred to was all of the reskins and badly designed assets which also ended up in the Kuju folder. I have heard of Kuju folders approaching 14 gigs in size. These are frequently the cause of the SBHH problems which have been occurring with TS2013.

Mike

[shanyiqua]

The official Kuju folder has not changed, and is around 4 gigs in size. What I referred to was all of the reskins and badly designed assets which also ended up in the Kuju folder. I have heard of Kuju folders approaching 14 gigs in size. These are frequently the cause of the SBHH problems which have been occurring with TS2013.

Mike

This won't stop addon makers from use it wrongly. I just surprised how much addons i still see with Developer/Addon structure
I have 5,5 gig sized kuju folder, and i've not getting SBHHs more frequently than with addons using other folders. SBHHs are caused by the incorrect settings of the badly designed assets placed in kuju folders(and of course the overwritten "hacked" kuju files), and not by the size of the folder.

[peterfhayes]

Mike
My Kuju folder is around 7GB but the "biggy" is now the RSC folder at 19GB.
Simmers always talk about the kuju folfer being too large and creating some issues - well if that was the case so would the RSC folder as it is major big.

Like Gary says all those junk files in the Assets folders can be cleared but the space gained will be minimal as most are only a few KB in size- I cleared mne recently and gained a measly 2MB in space.
Tip back up your assests folder before you "clean" it.

pH

[malkymackay]

There is quite a difference between the Kuju folder & the RSC folder though. The RSC folder contains many sub folders which can be selected as needed. This is less of an issue than one bloated Kuju/RailSimulator folder.

[gptech]

Isn't it more a case of the number of .bin files being referenced/available thats the issue rather than the total size of the folder? We've only latched onto describing the Kuju folder as being bloated when it gets large as that's more readily seen than the number of files, or indeed the number of files of a specific type that it contains. It's a reasonable corrolation between size and number of files though, reasonable enough to give a clue as to where those with issues should begin to look for an answer but it isn't exactly engraved in stone.

Clearing out the junk files may not yeild a vast amount of 'extra' HDD space, but if you have a smaller disc it could be a worthwhile percentage gain.

[mikesimpson]

If you check the work done by Bob Latimer on testing the SBHH problem, there is no doubt that it was often caused by the sheer size of the Kuju\RailSimulator file when filled with extra re-skins (It can of course be caused by other factors such as faulty rolling stock, RouteProperties.xml files which include lists of Providers/Products which are not actually used by the route etc).

If you run ProcMon then start TS2013 to run a route which has Kuju\RailSimulator included in the RouteProperties.xml file, you will see that EVERY .bin file in the Kuju\RailSimulator folder is opened by TS2013. There then becomes a limit to which this file can grow before the whole thing crashes.

RSC were well aware of this problem and it is why each new route from them now comes with just a sub-set of the old Kuju files repackaged in the RSC sub-folder. This has been confirmed to me by a senior member of the RSC staff.

Mike