Towards 1.13
#51
The cubeset format will probably also have to change so the blockdefinitions use the 'minecraft:XYZ' names instead of ids.
Reply
Thanks given by:
#52
Luckily, the format already includes a version number, so it should be pretty easy to distinguish between old and new.
Reply
Thanks given by:
#53
Even better, the cubeset format basically IS a PalettedBlockArea, so it will be much easier to generate Smile
Reply
Thanks given by:
#54
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.
Reply
Thanks given by:
#55
Just out of curiosity I tried changing the storage in cChunkData from BLOCKTYPE[] to PalettedBlockArea, and hit the Compile button. Poof, 3500 errors Smile Long road ahead...
Reply
Thanks given by:
#56
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.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)