Clear Cache - Blueprints.pak

[749006]

A discussion is taking place on another forum as to Clearing the Cache - deleting the Blueprint.pak

I still do this before I start the game but some people think it is not necessary.

Do we still need to do this?

Peter

[alanch]

A discussion is taking place on another forum as to Clearing the Cache - deleting the Blueprint.pak

I still do this before I start the game but some people think it is not necessary.

Do we still need to do this?

Peter

I only clear it from the relevant folders when I've installed new stuff, or do a complete clear with my batch file when I've installed lots. Otherwise I leave it alone and I rarely have any problems running 64 bit.

[johnrossetti]

I only use it when I have installed new scenery or Scenario

When I am editing I use it each time I make a change.

Cheers John

[gptech]

Do we still need to do this?

Short answer....NO

As the guys have written, it's only considered needed when you've added stuff as it ensures that the game re-indexes/re-caches the installed items so that they're guaranteed to show as available. It used to be a "must do" when adding reskins, but today it's not always necessary.

When simply playing it's of no use at all, as the re-indexing/re-caching of assets can slow loading down.

[peterfhayes]

P749
For what it's worth I still clear the blueprints.pak files after each session of TS.
I always feel that if something is left behind it may affect the running of TS - who knows?
On opening, TS can read up to 14,000,000 lines of code so a few hundred/thousand in the blueprint.pak files whether there or removed are unlikely to make much of an impression.
Plus don't they only work as a cache if you open the same route plus a scenario with the same assets that you might have loaded previously? That is, if you ran a steam loco scenario using say the Woodhead line, would you then see a faster load up time, whatever, if you then ran a diesel scenario on the same track, or then used the NEC?
I just get rid of them because I can and have always done so.
Send 'em packing is my motto!
pH

[gptech]

Plus don't they only work as a cache if you open the same route plus a scenario with the same assets that you might have loaded previously? That is, if you ran a steam loco scenario using say the Woodhead line, would you then see a faster load up time, whatever, if you then ran a diesel scenario on the same track, or then used the NEC?

Each product in the game has its own Blueprints.pak file, so running a Steam scenario on a route and then a diesel one will not be any slower if the diesel loco is in the same product folder.
Once cached each packs assets stay referenced, so if you run another scenario on another route using stock you've used at any time previously then the game will load the stock/pointers to where to go to find it from the cache rather than *hunt* for the files by drilling through the folder tree.
In theory the cache makes for faster loading of routes/scenarios by virtue of being more accessible to the system than tracking the files down---in practice, tn these days of fast CPUs/drives/memory considerably reduce the *lag* introduce by a search.

A quick test would be to pick a single scenario and time how klong it takes to load from an un-cached state and then after restarting the game time it with the cache in place.

[gptech]

A quick test would be to pick a single scenario and time how klong it takes to load from an un-cached state and then after restarting the game time it with the cache in place.

Just tested with a very busy scenario for WCML-South, un-cached took 1 min 55 secs to load.
Following a restart of the game, the presence of the cache meant that time was reduced to 1min 20 secs.

[peterfhayes]

Gary

Just tested with a very busy scenario for WCML-South, un-cached took 1 min 55 secs to load.
Following a restart of the game, the presence of the cache meant that time was reduced to 1min 20 secs.

That is my point exactly, the .pak files may only "save time" if you load the same scenario?
Was this reduced time reproducible over many loadings?
You would need now to load another scenario in the same route - would the loading time be affected before and after you saved the quoted .pak file?
If the presence of a .pak file reduces the time reduced to load for ONE (the same) scenario, then it should apply to all scenarios if you had created enough blueprint.pak files?
BUT, how many blueprint.pak files would you need to load/save to actually save time in opening up any scenario in TS?
Would the sheer number of .pak files saved/needed to decrease loading times for all routes and scenarios, etc outweigh any speed up benefits?
Is this a throwback to older PC's (older code) and disk drives and has NO relevance now with a "better" OS, faster PC's and SSD's?
Regards
pH

[Carinthia]

The Blueprints.pak files seem only to store information about a file, and if the file has changed it should automatically update that data. Many games have a similar feature under a different name. It isn't a "cache" at all, of course - a true cache stores files separately, and this may be why people think it is important to clear it (like you might want to do with a web browser cache).

I never "clear cache" as it doesn't seem to have any benefits. Dovetail only recommend it when there is a problem, not when installing new add-ons and especially not all the time. Presumably that's just an elimination measure to ensure it hasn't failed to update for some reason. Many people say it speeds things up to clear it each time but quite frankly I can't see how that can possibly be so as the files all need to be examined and re-indexed.

The most distinct difference in loading time is noticable when first loading TS, other games, or other resource-hungry software after booting up. Windows itself maintains an index of recently-used files and the second time of loading TS will be significantly faster as it knows where to find them. Presumably that applies to loading senarios and the editor in TS too. This index is not kept when the computer is shut down, so it indexes afresh the next time.

John