the footprint of compressed chunk batches is so small now that it doesn't make sense to disable it out of the box. The performance gains from caching chunks are more than worth it.
As of 1.2, the average footprint of these caches is usually ~2% or less of the size of the actual chunk itself. Moving around a lot will frequently cause the same chunks to get sent several times as it passes in and out of your render distance, and the chunk isn't even changing in that time, so the chunk is getting needlessly re-serialized over and over again. So even if your world is not static (for example a creative server) chunk caching will still offer benefits, and the memory expense is so small it's a no-brainer.
zero is not allowed because it's pointless, just raise your compression threshold if you want zero compression.
Chunks will always be compressed regardless of threshold because they are huge. It doesn't make sense to allow uncompressed chunks when even compression level 1 will reduce their size 50x. The point of the last two (reverted) commits was to prevent compression level zero being used on chunks. Probably obvious that I was up late and not thinking very clearly.
Revert "Reduced chunk compression level to 7"
This reverts commit 49ac2555ce.
Revert "Always use best compression for chunks"
This reverts commit 42dd9d6abd.
According to benchmarks 8 and 9 are simply orders of magnitude slower while not saving enough bytes to make it worth the performance loss. 7 is a good balance.
- nametag visibility flags don't work properly, only players show them all the time
- invisibility overrides nametag visibility
- scale 0 triggers asserts on debug builds
..... how hard is it to NOT break these simple things each update Mojang?
closes#1205
