1.13 migration, aims & objectives - Printable Version +- 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: 1.13 migration, aims & objectives (/thread-3313.html) |
1.13 migration, aims & objectives - tigerw - 09-14-2020 Present architecture (BLOCKTYPE, NIBBLETYPE) Chunk.SetBlock(Pos, E_BLOCK_PISTON, 0x10); auto BlockType = Chunk.GetBlock(Pos); if (BlockType == E_BLOCK_PISTON) { auto IsSticky = Chunk.GetMeta(Pos) & 0x08; } (If we're lucky we might have an E_META_XXX mask.) Fast, but not type safe. There may be any number of metadata changes between MC 1.x and 1.y which silently broke our bitwise ops which we just don't know about. Doesn't support >256 block types. Next steps Need something that's fast and type safe. If Mojang changes some property in 1.17 say, the person who's updating to the new blocks needs to see a compilation failure for every use of a property that was changed or no longer exists, as well for not setting a property that was added. ⁂
Building on the recently added BlockState/BlockTypeRegistry/... These classes maintain a dynamic string mapping, akin to the Vanilla { "minecraft:block_name" : { "property1" : "value1" }}. This isn't the best format for Vanilla blocks:
Plan going forward A new Block struct (similar to cItem) for Vanilla. BlockState & BlockTypeRegistry for plugins. Block structure storage format struct Block { // Gets the type of this block BlockType Type() const; // Comparison operators // ... unsigned short ID; }; 16 bit short, in a typed Block structure. Consumes no more than BLOCKTYPE + NIBBLETYPE. Vanilla block handling Chunk.SetBlock( Pos, // Call the autogenerated Piston(...) function in the autogenerated Blocks namespace // Creates a Block struct representing a Piston with the given properties set // Can also do Blocks::Piston() to create a default Piston, using the default Mojang defined in their registry.json Blocks::Piston(eBlockFace::BLOCK_FACE_XM, /* sticky */ true, /* extended */ false) ); auto Block = Chunk.GetBlock(Pos); if (Block == BlockType::Piston) // Invokes comparison operator between Block and BlockType, converts a Block to its type automatically { // Call the autogenerated "Sticky" accessor in the Blocks::Piston autogenerated namespace // The accessor looks at Block (i.e. its ID) and returns if it's sticky. auto IsSticky = Blocks::Piston::Sticky(Block); } Lua script generated namespaces that can create a Block and query the properties of one. Baked in at compile time. Custom blocks, extensibility, plugins This isn't yet done, but could look something like this: Use a global dynamic registry, xoft's BlockState/BlockTypeRegistry classes. Plugins can register blocks with a set of string properties, attach their custom BlockHandler, and set BlockInfo properties (IsSolid, IsSnowable, etc.). For each combination of properties, the plugin receives a Block struct (so, basically an ID that comes after the Vanilla ones). Now this custom block can be used like any vanilla block, passed to SetBlock, returned from GetBlock. When native code needs information about this custom ID, it queries the global dynamic registry. Protocol Since the set of vanilla blocks are fixed, mapping Block (ID) to protocol ID is a switch statement. Custom blocks probably need some negotiation with the client, the plugin can be responsible for returning the right protocol ID. Serialisation Storage to Anvil needs mapping to and from namespaced strings, "minecraft:xx" et al. A bijective mapping in WorldStorage\NamespaceSerializer.cpp (BlockType <-> std::string) as exists for Statistics should do the trick. Again, unknown IDs are delegated to the global registry. Chunk storage Just a normal palette storing our 16 bit shorts. No special handling for custom blocks since this is just storage. Ideally in 1.16's Chunk Data format, so sending chunks need minimal processing. RE: 1.13 migration, aims & objectives - bearbin - 09-22-2020 Is this understanding correct, in comparison to the old proposal, that the differences are: PalettedBlockArea is to be forgotten, and the existing structures should be extended to use a global palette, which is mostly static and only partially dynamic. The changes appear to be less fundimental to the server, but also much less incremental, so this will basically have to be done in one go. Personally, this proposal appears sensible and if you want to go ahead with it and can complete it you should. One small point, is that I really don't like adding comparison operators to the Block struct that actually compare BlockType. It would be much clearer in use to to Block.Type() == xyz RE: 1.13 migration, aims & objectives - tigerw - 09-22-2020 I'm not entirely sure on PalettedBlockArea. The aim of this class is to have one implementation of 1.13 memory saving palettes that can be re-used in BlockArea, chunk generation, chunk storage. For the latter two though, which are comparatively short-lived but tend to be access-heavy, we'd want to prioritise speed (so no additional palette lookup) over memory savings. So the class may just end up subsumed into ChunkData for chunk storage. RE: 1.13 migration, aims & objectives - tigerw - 09-22-2020 About migration, it could be split into chunks storing our Block struct, with a translation <-> BLOCKTYPE/NIBBLETYPE, followed later by the huge change making GetBlock/SetBlock take Block structs. RE: 1.13 migration, aims & objectives - bearbin - 09-29-2020 Does anybody else have a comment about this - happy to approve @tigerw's vision for the future? RE: 1.13 migration, aims & objectives - Mathias - 09-29-2020 Sounds like a decent proposal to me. If you have a clear vision of the changes necessary from here on, and are willing to put in work, I say go for it. RE: 1.13 migration, aims & objectives - 12xx12 - 03-08-2021 So we have the autogenerated stuff in Registries/BlockStates.h .cpp So now we'll have to create the struct with the comparison operator and replace any operation taking a BLOCKTYPE, NIBBLETYPE with that struct - right? Any coversion of (BLOCKTYPE, NIBBLETYPE) is done in the code of the palette folder in Protocol. I'm gonna give this a go today. RE: 1.13 migration, aims & objectives - tigerw - 03-09-2021 There's already a BlockState struct in BlockState.h. RE: 1.13 migration, aims & objectives - 12xx12 - 03-09-2021 (03-09-2021, 10:14 PM)tigerw Wrote: There's already a BlockState struct in BlockState.h. Yeah - i saw that. I'm workign slowly forwand to replace everything. I'm stuck at unity_35 at this point |