beg people not to disable chunk caching

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