diff --git a/src/api/java/baritone/api/Settings.java b/src/api/java/baritone/api/Settings.java index 97337d2a..15ae9eee 100644 --- a/src/api/java/baritone/api/Settings.java +++ b/src/api/java/baritone/api/Settings.java @@ -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 * -1 to disable + *

+ * I would highly suggest leaving this setting disabled (-1). + *

+ * 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) + *

+ * 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. + *

+ * 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 cachedChunksExpirySeconds = new Setting<>(-1L);