beg people not to disable chunk caching

This commit is contained in:
Leijurv 2018-09-27 15:37:22 -07:00
parent de6d6c8714
commit 015462eddb
No known key found for this signature in database
GPG Key ID: 44A3EA646EADAC6A

View File

@ -407,6 +407,22 @@ public class Settings {
/** /**
* Cached chunks (regardless of if they're in RAM or saved to disk) expire and are deleted after this number of seconds * Cached chunks (regardless of if they're in RAM or saved to disk) expire and are deleted after this number of seconds
* -1 to disable * -1 to disable
* <p>
* I would highly suggest leaving this setting disabled (-1).
* <p>
* The only valid reason I can think of enable this setting is if you are extremely low on disk space and you play on multiplayer,
* and can't take (average) 300kb saved for every 512x512 area. (note that more complicated terrain is less compressible and will take more space)
* <p>
* However, simply discarding old chunks because they are old is inadvisable. Baritone is extremely good at correcting
* itself and its paths as it learns new information, as new chunks load. There is no scenario in which having an
* incorrect cache can cause Baritone to get stuck, take damage, or perform any action it wouldn't otherwise, everything
* is rechecked once the real chunk is in range.
* <p>
* Having a robust cache greatly improves long distance pathfinding, as it's able to go around large scale obstacles
* before they're in render distance. In fact, when the chunkCaching setting is disabled and Baritone starts anew
* every time, or when you enter a completely new and very complicated area, it backtracks far more often because it
* has to build up that cache from scratch. But after it's gone through an area just once, the next time will have zero
* backtracking, since the entire area is now known and cached.
*/ */
public Setting<Long> cachedChunksExpirySeconds = new Setting<>(-1L); public Setting<Long> cachedChunksExpirySeconds = new Setting<>(-1L);