Atomic Systems

smarty2 wrote:when coming out of one scenario and starting another the game is still holding onto over 2 gig of memory

I think you are confirming my point. The game is holding something cached in memory that it shouldn't.

eyore wrote:

smarty2 wrote:when coming out of one scenario and starting another the game is still holding onto over 2 gig of memory

I think you are confirming my point. The game is holding something cached in memory that it shouldn't.

The game simply doesn't frees the memory sections that are not used anymore. I think this is called as "memory leak". It's a programming error, and these are usually getting fixed in patches, by other developers, but not by RSC.

A lot depends on what you're using to measure memory usage; just because Task Manager shows railworks.exe as 'claiming' a chunk of memory doesn't mean that it's actually full of data. I do agree though that the memory management routines in the game need attention, remember that despite the improvements we've had it's still a game based on old code and written before the larger amounts of RAM many are using was the norm.

Eyore
Good point but why does it only happen in the KUJU folder and not the RSC folder?
Just a thought
pH

peterfhayes wrote:Eyore
Good point but why does it only happen in the KUJU folder and not the RSC folder?
Just a thought
pH

For the simple reason that it is not the Kuju folder which is the problem but the Kuju\RailSimulator folder which includes all of the scenery/rolling stock for EVERY UK route which they provided PLUS all of those reskins which were added by reskinners before they realised what the problem was they were causing. So when you load one of the old UK routes, or any route calling for Kuju\RailSimulator, then all of those files are opened by TS2013

Similar thing has happened with the Kuju\RailSimulatorUS route if you have been downloading all of the US repaints.

In the case of the RSC folder, they have used a separate sub-folder for each of their routes, so when you run a RSC route, it only opens the files actually used by the route, hence no problem.

Mike

malcolmfhill wrote:Coincidentally, I've just discovered this re reducing the size of Kuju folders. Scroll down the accompanying pdf file....

http://railworksamerica.com/index.php/l ... -in-ts2013

That tutorial has been on the RW_Tools site for some time now, ever since Bob was declared persona non grata on this site.

Mike

Peter,

If I need something from the Kuju\Railsimulator folder, I select it. That "activates" (on my installation) a folder of 6.61 Gb (and that's after stripping it down) and whatever files TS2013 then loads.

If I need something from, say, the RSC\Falmouth Branch folder, I select it and "activate" a folder of 547 Mb and whatever files TS2013 then loads.

That's why the RSC folder has (on my installation) 52 sub folders. So that if you need something from one of them you don't have to select the lot.

Or have I missed the point you were asking about?

Mike
Thanks, and I apologise for raising it again - I was raising what Phil said about caching data in the KUJU folder in that purely from a Windows point of view it shouldn't cause a program to crash merely on the folder size or structure, or how many files it has to cache. Now if there is an improper call for whatever reason then that would certainly crash the program.
I have recently seen an anomaly where the VAS usage suddenly peaks during some scenarios particularly on routes pre TS2013, the contiguous space lessens and there is an increase in fragmentation - I tried to correlate that to the KUJU folder usage but couldn't do it. On my system it then rectifies itself very rapidly. but maybe on other systems where there have been add-ons to the KUJU folder, at some critical point it could compound the error and cause a SBHH even on a 64-bit OS.
Just a theory.
Regards
pH

Peter,

(As a relative newcomer to the forums I'm still on "moderated posting" (grrrr) so my posts pop up totally out of context.)

I strongly suspect it's not Windows that's having the problem with folder size, it's TS2013 having problems with being told to load too much "stuff" (whatever that "stuff" is).

If you were around in the MSTS days, it had an internal issue where if you had too many consists and paths it would freeze up, not because of a Windows issue but because MSTS had an internal problem whereby it got "overloaded".

I would think that the SBHH issue with TS2013 is similar, in that, for some reason, there's some kind of internal limit on what it can handle.

peterfhayes wrote:one day we will crack this thorny issue!!

RSC could resolve this mess with a single informational post. That they've not done so since the release of 2013 is totally lame. I'm sure they have their reasons, but it would probably require a law degree to understand them.

gptech wrote:Assets don't use .xml files Peter, therse can safely be deleted.

Before I delete the 9,100 .xml files in my Assets folder (holy momma!), can someone confirm that they're not necessary?

Thanks.

Jevon
This may not be RSC's fault AFAIK it only happens when you load up the KUJU folder with a certain amount of add-ons from 3rd parties, ie NON-RSC stuff.
My Kuju folder has been around 12 GB on one machine, 11GB on the other and I have never seen a SBHH due to its content.
I have 3,800 xml files and 5,500 on the other and yes it would be great to get a definitive anwser as to whether or not they can be deleted.

Found this on RWA :http://railworksamerica.com/forum/viewt ... f=6&t=1538 probably here too:

You also don't need any .xml files you find in your Assets folder tree. These are leftovers from processing blueprints into .bin's and are usually 2-3 times the size of the .bin file.

So it looks like in the ASSETS folder we can delete .tgt, .cost, .bak, .xml and possible ace/psd if you are not into repaints.

Gary hope you can confirm that this is not the ramblings of a madman!!
Regards
pH

peterfhayes wrote: So it looks like in the ASSETS folder we can delete .tgt, .cost, .bak, .xml and possible ace/psd if you are not into repaints.

All of those files are not need in the assets folder for an end-user. I delete them before I package up my rolling stock & I have yet to hear of anyone having an issue.

malkymackay wrote:All of those files are not need in the assets folder for an end-user.

I concur, but we don't know if their presence has any effect on the issue raised - SBHH errors supposedly caused by the size of the Kuju directory contents. My gut feeling is that this only relates to .bin files but the problem is that we really don't know for certain. But removing those files would certainly help those limited on disc space.

The Kuju directory is critical to many routes and scenarios so it is something we can't really live without. With TS2013, RailSimulator.com copied certain assets to individual route directories - I don't believe this had anything to do with this issue (as some think) but related to distribution of TS2013 with certain routes only. The biggest issue has surely to be the huge number of free add-ons in terms of reskins for default Kuju locomotives and stock and I mentioned in another thread that the UKTrainsim Freeware Packs play a major part in this. These really need to come out of the dark ages and allow us to install only the items we want - each time I install an updated version of a pack I go through the directories deleting a massive amount of repaints that I know I will never want. This may be why I haven't yet experienced such SBHH errors but it is clear from reading these forums that a lot of people do.

John

http://railworksamerica.com/forum/viewt ... 538#p11105

I have just made a copy of the DeleteJunk.bat batch file designed by Alanch (thankyou) using Notepad and placed it in my Assets folder (NOT !!! the Content / Routes folder) with a shortcut to the desktop and have been able to remove 4,500 xml tgt cost and bak files and can confirm that my routes /scenarios still load and run correctly.

I would RECOMMEND you back up everything first, though!

Now let's see if I still get those SBHHs......

A lot depends on what you're using to measure memory usage;

I'm using cleanmems mini monitor. RSC should fix the problem, however that is only possible if they are aware of the problem?