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