Not related to the 26.3 update but easier than having to deal with merge conflicts after the public release.
Signed-off-by: Florian Reuth <git@florianreuth.de>
This also moves Fabric and Sponge resource files into the universal dir; we do not publish platform specific jars and this otherwise only leads to a more complicated project setup
The general idea behind the four storage types is the same, except ids are now
1) written as id deltas instead of absolute values
2) written with zigzag encoding (always positive)
3) written as varints
The previous commit made extra mapping data go down by 85% (both uncompressed and compressed).
Combined, this is about a megabyte less uncompressed and 125kb less compressed data bundled right now (not including ViaBackwards).
Reading has become ever so slightly faster due to the reduced file reads (despite now needing more complex decoding), but that's negligible anyway
Merge en_US properties and lang mappings into a single file that still decodes into the same values; store block connections as shared "profiles", since there are only so many different ways of connecting to neighboring blocks; store block states with shared properties; reduce redundant info in the recipes file and store the rest in a more compact/type-specific way as well.
On top of that, store ranges of ids much more concisely (by far the biggest win)
At the moment only relevant for ViaBackwards, but the client throws when getting environment attributes it does not recognize in biome or dimension registry data
Only uses a single long now with a simple long set instead of an expiring cache. When an invalid token is read, it no longer throws but moves back the reader and continues to maybe possibly not interfere with other plugins for some reason sending their own data with the packet id 1000
Entirely negligible on most servers, but if running on the backend with many players and newly added entities / other uses of it across many different threads, random UUID generation is synchronized with its shared SecureRandom use
If two protocols were trying to load the same identifier file very close to one another, the first load attempt would not have been added to the cache yet, so the second would have also started loading the file. This makes it wait for the first load instead
Instead of going through each of the 4096 blocks in a chunk section, check the palette values first to then also skip actual id getting and simply check palette indexes via an array lookup
After the improvements from a month ago it already became a good bit better, but was still the most time and memory consuming task by far. This cuts down up to 90% of it by skipping raw data extraction entirely unless actually needed in fairly rare cases as well as making packing and unpacking much more direct
Nassim Jahnke
Florian Reuth
Beanes
itslilscorp