Better Compatibility
From time to time I read through the Minecraft wiki 1, and just recently I stumbled upon a couple of things I had completely missed to support [^minecraft-addtions]. First thing was that Region format supported uncompressed payload. This was a rather easy thing to add, but it seems like they stopped using it since 1.15.1.
Second was that since 24w04a 2, LZ4 was added as supported compression. This is an optional feature you can enable for each server, but as most people do not need it, it is not a crucial thing to support, although welcome. Adding the dependency should be pretty straightforward 3, but I stumbled upon a couple of issues: Cmake support existed, but there was barely any information about it, so I had to read the source in a subfolder; Documentation was subpar, and there was very few examples on how to use the library; Streaming support existed, but it was rather hard to understand how to use it, so I had to settle with decompressing and retry with a larger size each time.
Third was that since 1.15 they added a new format called MCC. This is used for a really rare case, as mentioned by one guy encountering and reporting it 4, where the total chunk data, even when compressed, is larger than 1MiB, and therefore is saved in its own file. I initially thought this would be a hard nut to crack, so I started implementing separate cases, before I realized that I could integrate it entirely into the Anvil 5 implementation, and hence within an hour had finalized the support with less than 50 lines of code, in only two files. Problem is that it is a bit difficult to test this, as creating a chunk that large within Minecraft itself requires many unique entities and blocks in such an order that the compression will be futile. Even if it was difficult to find a full explanation for the feature, it was pure luck that I ran into the above mentioned post from a guy that reported it as a bug to Mojang.
Final additional fix was that since 24w05a 6, custom compression formats was added. However, there are very little information about this, so I left with just telling specifically in the logs that it does not support this type of compression. I suspect we may encounter it more in the future, and therefore will get an hands-on use-case I can implement against. However, I most probably will not start adding more libraries just to support them, but will at least output what algorithm is used. At most I may add support for plugins to be used.
All of this took a bit over a couple of hours, the longest was to add LZ4. I was not planning to do this, but it is good that I stumbled upon it in order for me to fix it. I expect more features in the future.