+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Towards 1.13 (/thread-3215.html)
RE: Towards 1.13 - xoft - 01-24-2019
A bit of a problem with your solution is the conversion between BlockStateId and the block state represented as a map<AString, AString> that is serialized in the on-disk format and used in the network protocol. The part of old code you saved from refactoring is (imho more than) offset by the code that does the conversion.
RE: Towards 1.13 - peterbell10 - 01-24-2019
(01-24-2019, 12:07 AM)xoft Wrote: And that's the main problem of your solution - for some blocks this number is really huge.I don't see how this is problem, could you explain?
Quote:A bit of a problem with your solution is the conversion between BlockStateId and the block state represented as a map<AString, AString> that is serialized in the on-disk format and used in the network protocol. The part of old code you saved from refactoring is (imho more than) offset by the code that does the conversion.
I would expect you only need a single function per block type to perform the translation from the state index to (e.g.) a JSON value for the full block state itself. Whatsmore, I expect most of these to be pretty simple functions e.g. for Bamboo
Json::Value ReadableBlockState(BlockStateMeta Meta)
{
Json::Value State;
State["age"] = Meta % 2;
State["leaves"] = [&]{
switch((Meta / 2) % 3)
{
case 0: return "large";
case 1: return "none";
case 2: return "small";
}
}();
State["stage"] = Meta / (2 * 3);
return State;
}
Also it look like Mojang uses a global palette internally, or at least wiki.vg claims so:
https://wiki.vg/Chunk_Format#Global_and_section_palettes
RE: Towards 1.13 - peterbell10 - 01-24-2019
Actually, reading that wiki.vg page it seems like the global palette values are fundemental to the serialisation format. No maps or strings involved.
Maybe I had already read that when 1.13 first came out and that's why it was fixed in my mind.
RE: Towards 1.13 - xoft - 01-24-2019
Oh wow, I hadn't read the network format yet, and now it seems it's highly dependent on some internal block order and BlockState order. This is against any BlockTypeRegistry ideas that we may have. Is Mojang stupid or what?
RE: Towards 1.13 - xoft - 01-24-2019
All programming problems should be solved by a good night's sleep
To sum things up:
Vanilla network protocol uses a so-called global palette, which is fixed for the specific Minecraft version, both the server and the client have a copy of the palette, so it's not sent through the protocol at all. In disk-stored chunks, the block states are stored in full (map of key -> value) and translated into that palette in-memory when loaded. The server executable is capable of outputting the global palette into a json file ( https://wiki.vg/Data_Generators#Blocks_report ).
I think here's what we should do:
1. Allow any combination of block type name and block state in the world, and support storing it in the saved world.
2. Each 1.13+ vanilla protocol (each separate sub-version, like 1.13.1, 1.13.2 etc.) should read the block report file and use it as the global palette, translating the internal representation to the version-specific network representation. Any unknown block / blockstate should be replaced with some reasonable placeholder (air? bedrock?)
3. (legal: ) Can we distribute the vanilla-generated block report file, or will we need to instruct the users to generate their own and feed it to Cuberite?
4. Cuberite should support dynamic block registration and unregistration by plugins
5. At first we should focus on the minimum amount of code changes that support the 1.13 flattening; even if it means a performance drop at first.
For this reason, I still think implementing a global palette as the first step is not a good idea, especially considering the potential dynamic block registry. It can wait for later, if it is deemed reasonable.
RE: Towards 1.13 - tigerw - 01-25-2019
If you're looking for the minimum amount of changes, #4274 is the minimum required to connect and render.
RE: Towards 1.13 - NiLSPACE - 01-25-2019
Quote:2. Each 1.13+ vanilla protocol (each separate sub-version, like 1.13.1, 1.13.2 etc.) should read the block report file and use it as the global paletteCould future versions simply extend from the 1.13 palette?
RE: Towards 1.13 - xoft - 01-25-2019
(01-25-2019, 02:25 AM)tigerw Wrote: If you're looking for the minimum amount of changes, #4274 is the minimum required to connect and render.
That's too minimal (no palette at all yet). And I think we need to do the Flattening as well, on the internal block representation.
(01-25-2019, 04:41 AM)NiLSPACE Wrote: Could future versions simply extend from the 1.13 palette?
Not necessary, the (network protocol's global) palette is represented in a data file that is generated from the server, we won't need to write anything to support newer versions in this regard, just add a new data file.
RE: Towards 1.13 - xoft - 01-25-2019
Ugh, the block state report has a whopping 1.6 MiB, I thought we could add it to the repo, but that's too huge. Perhaps a separate repo for the reports and some way of downloading it automatically?
RE: Towards 1.13 - tigerw - 01-25-2019
You could deJSONfy it into a CSV?