Say the sim has created internal data from the cache file that is important. We use the term “flush” to literally mean flushing the data out of the program into the cache immediately before closing down. It means Save, but with a few technical twists like it only saves to a small portion of the cache.
That’s the beauty of a rolling cache of 128GB, we could stream an updated Cessna tyre of 20Kb and just write 20Kb into the cache in a few milliseconds. Or we could stream a detailed airport of 8GB and write that into the cache. Next day all the new assets are ready to roll.
At the moment I expect only the Asobo devs could accurately spot a corrupt cache.
The current GUI will not allow us to shrink the cache; we can only increase it. Shrinking probably corrupts some data, so lets park that for now.
What I did is after 2024 shut down, I simply moved the RollingCache.CCC to a different folder. When the GUI boots up it creates an empty cache of default size in the original folder, then I could set a larger cache the size I wanted. I went from 16, to 32, to 64 and now 128 (Q: how do you spot a dev? they count in binary ) But jump straight to what you want.
[You can even shut down 2024 and swap .CCC caches, it boots up regardless and uses whatever data it finds. That’s probably not a smart thing to do at the moment - patches to the base sim may make older .CCC files incompatible.]
Map content of the world would be a hefty challenge to keep track of so as to keep the cache current. Maybe Asobo can do it however I’m very skeptical…
That’s taken care of mainly by the NTFS file system - its got to be robust in that area given how much Windows and apps crash. I think worst case if the sim crashes while updating the cache your just going to get a few missing records that would get updated next time around.
As to how it works, all I can say is the way that I think it SHOULD work.
It should store everything streamed including textures and photogrammetry.
It should only store fully complete objects/systems. If an object stream is interrupted by any network/server issues it should be marked dirty in the cache.
It should have a robust version control system that doesn’t require huge network bandwidth or CPU cycles to validate.
My observations and those of others documented here in the forum, lead me to believe that only some textures are stored. I don’t know about photogrammetry but I suspect that it is.
I think that points 2. and 3. are implemented but I think that both are currently sub-optimal. I think that there may be bugs in point 2. given the number of reports around missing textures/meshes etc. and I think that point 3. while correctly implemented is poorly optimised given the widespread reports of poor loading times.
I increased my cache from 16 to 64 GB this morning. I saw no improvement to performance during my 1.5 hr flight in the Friday Community Fly-in. Plus, I hit the same game-freeze-on-landing at KLAS that I’ve been experiencing since v1.1.10.0 was released.
I have no insider information, but one way to handle that is checksums.
That can be used to ensure that a local copy is identical to the remote file.
If not, the part of the file that is corrupt is re-fetched.
Many software use that mechanism to automatically verify each chunk’s integrity after download.
It may take a few days to see a rolling cache benifit.
You only see benifit in areas you repetitively fly in…for example when textures streamed yesterday are used again today.
So for your freeze on landing could you:
Press Esc at minimums, press Q for freecam. Then fly the camera around KLAS, getting close to everything around the runway.
Monitor Task Manager for the msfs2024 process, network activity. You should see a lot of network traffic as you pan around.
This sounds quirky, but the network activity will fill up your cache with runway textures, ready for the next landing.
Btw: If the freeze is reproducible a bug report can be submitted.
It would be tidy to create a new topic for the landing freeze, indicating runway, plane, cache size, VRAM, graphic settings etc.
If many simmers can reproduce the freeze every flight, then Asobo can investigate.
We check the rolling cache two to four times by performing the same flight. Unfortunately, you won’t be able to reproduce this flight due to differences in the traffic that was present during community fly-in.
I seem to have better luck over 120GB. I cleared it out and downsized it a few times and started getting blurry textures in cockpits that took some time to clear up(900+ up/down ping of 5 to the server). Of course, aircraft I dumped into the community folder are light years better about initial load in than streamed ones. And the Sierra is a fairly complex ‘simple’ aircraft with heavy textures and custom avionics and it runs like butter being on the HD-where it ‘hits’ about the same as a medium complex airliner in 2020. I may go back and try dumping the 2020 carenados into the community folder, it’s not like the EFB’s work on them now anyway. Pretty sure zero was done to what’s being streamed in, they didn’t even change the naming structure. Keeping 2020 up may be handy.
Will rolling cache also cache aircraft? Typically fly the same 4-5 aircraft and would be nice if I don’t have to stream them everytime I load in them. They said during the livestream they will have an option to download individual aircraft but I’m wondering if rolling cache would end up doing the same.
I decided to move my rolling cache to a different drive. I changed the location in the settings, and the sim immediately starting setting it up in the new location.
Once it had finished, and I’d exited the sim, I confirmed the new location was populated, and then checked the previous location only to find the cache was still there, taking up 16Gb of valuable space. Not good.
I presume I can just delete the now unwanted, unreferenced cache file without causing the sim (or even my system) to be damaged?
Yes. Id did same, created 128gb on another drive. Deleted in explorer the 16gb standard one. As a super check, check date and time. New one should be the time you created , old one when you last used.