+- 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 - NiLSPACE - 09-05-2019
The cubeset format will probably also have to change so the blockdefinitions use the 'minecraft:XYZ' names instead of ids.
RE: Towards 1.13 - xoft - 09-05-2019
Luckily, the format already includes a version number, so it should be pretty easy to distinguish between old and new.
RE: Towards 1.13 - xoft - 09-05-2019
Even better, the cubeset format basically IS a PalettedBlockArea, so it will be much easier to generate
RE: Towards 1.13 - xoft - 09-10-2019
I think it should be possible to actually implement most of the 1.13 protocol while still using current block representation, @tigerw was right, one can see the "shape of the terrain" and that's enough for the start. And then it could be switched, once ready. So I'll try to adapt his code.
I suppose it would make sense then to branch off the 1.13 development into a separate branch, where individual increments could be merged. The way I see it, first a lot of code is gonna go away, I'll cut off generator, loader, lighting calculator, anything that uses the blocks extensively, I'll keep just the bare minimum to make it possible to log in using the 1.13 protocol. Then it should be possible to switch the underlying representation a bit more easily, and finally add those features back in, one by one.
RE: Towards 1.13 - xoft - 09-27-2019
Just out of curiosity I tried changing the storage in cChunkData from BLOCKTYPE[] to PalettedBlockArea, and hit the Compile button. Poof, 3500 errors
Long road ahead...
RE: Towards 1.13 - xoft - 10-17-2019
We're inching towards the goal. With my latest PR (https://github.com/cuberite/cuberite/pull/4419), I've reduced the number of E_BLOCK constants within the server core considerably. There's still 92 more to go in cChunk alone, and they all need to go away - the chunk, chunkmap and world must not be tied to any specific block, everything needs to be provided by the blockhandlers, simulators etc. That way it can be cut off in a reasonably simple way and the replacement can be incremental.
RE: Towards 1.13 - xoft - 12-28-2019
I could really use the review for PR 4431: https://github.com/cuberite/cuberite/pull/4431
This is the groundwork class on which the 1.13+ chunks will be built.
Since I can't do much before that PR is merged, I started meddling with the build system, improving bits and pieces, such as the horrifying "output all binaries into a single folder within the source tree" we were using up until now (PR 4440).