Closed floral-qua-floral closed 7 months ago
I don't think I can do anything about this. There would need to be some way to let HD know to properly close the sqlite database.
The file is huge, and unnecessary on a backup because it's just a cache that's rehenes automatically. I'd much rather it be omitted by default.
The Distant Horizons mod creates LOD data of the world to allow for much higher render distances than can be achieved with normal chunk rendering. The LOD data is saved within its world's directory in a
.sqlite
file, atdata/DistantHorizons.sqlite
. It seems that this file sometimes becomes damaged during the process of backing up or restoring it, which causes the LOD data to permanently fail to load upon re-entering the world after it has been restored from a backup. Of note is the fact that this file is exceptionally large compared to any other individual file I've seen in a Minecraft world, which may be why Textile Backup has problems handling it. The issue doesn't seem to always occur but it does seem fairly consistent; I've tested probably at least 6 times and I was only able to restore a world without damaging its LOD data in a single test.I was also able to confirm that manually backing up the world with copy-paste never causes LOD data to be damaged; the error only occurs when doing it through the mod.
Versions:
Steps to reproduce:
/backup start
to create a backup of the world./backup restore latest
to restore that backup.Here is a log file in which I follow a slightly modified version of that procedure, in which I:
/backup list
to double-check that no backups of the world exist already,/backup start
to create a backup,/fill
to place a large number of blocks, so that I will be able to visually confirm that the world has been rolled back after restoring the backup,/backup restore latest
to restore the backup,Prior to these tests, I disabled
shutdownBackup
&backupOldWorlds
and enableddeleteOldBackupAfterRestore
, so that I could more easily manage the backup files. However, I was able to confirm that the issue still occurs with the default configuration.I am able to provide three world files from the same test that produced that log file:
.minecraft/backup
folder (still available after restoration due todeleteOldBackupAfterRestore
being disabled).However, they are all above the maximum file size that Github will allow me to upload (25 MB), so attaching them to the issue report is challenging. The bulk of their size is from the LOD data files, which are the most relevant part, so those cannot be omitted, and they are too large to send even in isolation. If it would be helpful, I can probably stick the worlds or LOD files into Google Drive or something and provide a sharing link.