Precaching:How to disable?

:n:... Now TRS2019 has the "Precaching" crap yet again,in the newest beta. I find that the precaching is just a plain waste of time and one big reason I see that makes it absolutely pointless is this:While doing a database repair on TANE or TRS2019... one part seems to be something like "caching content"... and that makes it seem like the content was already cached... so what is the point of precaching? But the issue I find with it is that it's slow... very,very,very,VERY slow. (Or is it that my PC is slow causes it to be slow.). But the thing is... in TRS2019 build 96000,there was barely any precaching at all. No precaching on Lilbs 40ft boxcars,or on any other rolling stock. I only encountered it once or twice in build 96000...


But N3V can't even make precaching optional? So the people who want it can have it,and the people who don't want it don't have to have it? Or is a old,slow,2.5 GHZ dual-core CPU to blame for how slow it is?


On a side note,please try to respond to the topic of this thread,and please don't turn this into a "Defend the precaching" thread.

The point of precaching (and why it's not optional) is so the game can interpret the information in the assets into a form that allows it to be loaded in quicker in future loads of that asset.

The only content that is normally already cached is the built-in content and DLC content as this is done by N3V before the content is released.

Shane

EDIT: Just had a thought. The likely messages you are getting regarding precaching during a database repair is if for some reason it cannot download the precached information for one or more DLC items from N3V's servers. There is a cost to this as it normally has to cache these when they are first used.

shaneturner12 said:

The point of precaching (and why it's not optional) is so the game can interpret the information in the assets into a form that allows it to be loaded in quicker in future loads of that asset.

The only content that is normally already cached is the built-in content and DLC content as this is done by N3V before the content is released.

Shane


EDIT: Just had a thought. The likely messages you are getting regarding precaching during a database repair is if for some reason it cannot download the precached information for one or more DLC items from N3V's servers. There is a cost to this as it normally has to cache these when they are first used.

Click to expand...

Well I'm not sure if this is working as it should then. If I load a route or session, it is very slow as RailFan500CA says.

You say this allows it to be loaded quicker in future loads. Yet if you exit the game, come back later, load the exact same route or session, you get the same long wait. So it only saves it until you close the game. Next time you start anew, it's the same very slow process to Precache. Is that how it's supposed to work?

brucem56 said:

Well I'm not sure if this is working as it should then. If I load a route or session, it is very slow as RailFan500CA says.

You say this allows it to be loaded quicker in future loads. Yet if you exit the game, come back later, load the exact same route or session, you get the same long wait. So it only saves it until you close the game. Next time you start anew, it's the same very slow process to Precache. Is that how it's supposed to work?

Click to expand...

This doesn't sound right, however, it seems to be working fine for me. To confirm that there's an issue, I just opened up a route I was editing and fiddling with last night and it loaded up in less than a minute where as last night I had the pre-caching message for a good five minutes.

Keep in mind that this stuff is read from disk and should the disks be full or highly fragmented, the process can take a lot longer and anything we can do to make things go faster we need to do.

I recommended defragging the hard drive, SSDs not included, disabling antivirus from scanning those folders, and ensuring there's plenty of disk space on the system drive to allow room for swap and temp files to grow.

If it's not quicker on future loads that doesn't sound right to me either and may require a bug report. It sounds like something has gone wrong on the precaching side in the program code.

Shane

JCitron said:

This doesn't sound right, however, it seems to be working fine for me. To confirm that there's an issue, I just opened up a route I was editing and fiddling with last night and it loaded up in less than a minute where as last night I had the pre-caching message for a good five minutes.

Keep in mind that this stuff is read from disk and should the disks be full or highly fragmented, the process can take a lot longer and anything we can do to make things go faster we need to do.

I recommended defragging the hard drive, SSDs not included, disabling antivirus from scanning those folders, and ensuring there's plenty of disk space on the system drive to allow room for swap and temp files to grow.

Click to expand...

I had an extended Precaching session yesterday, on checking Resource monitor, Defender was busy scanning things, not Trainz related leastwise not obviously as I have it excluded but everything else...... when it stopped the precaching quickly finished. I have to wonder if TANE / TRS19 are caching things somewhere in the user folders or such like.

No problems today whatsoever.

clam1952 said:

I had an extended Precaching session yesterday, on checking Resource monitor, Defender was busy scanning things, not Trainz related leastwise not obviously as I have it excluded but everything else...... when it stopped the precaching quickly finished. I have to wonder if TANE / TRS19 are caching things somewhere in the user folders or such like.

No problems today whatsoever.

Click to expand...

Hmm. That's interesting. Will have to poke around and see where the temporary data is stashed. That would make sense why Defender would cause the process to take a bit longer unless the precaching is such a system hog that the extra tiny bit of a load that Defender puts on the system is causing the slow down. (Hoping that isn't the case.)