Towards 1.13

[NiLSPACE]

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.

What does that mean for multiple Minecraft versions simultaneously?

[xoft]

@tigerw Converting to a less chatty format sounds good.

@NiLSPACE multiple data files, each containing the complete report for the version. I assume there's little overlap between the different versions' maps, so it wouldn't make sense to try make the new ones dependent on previous ones.

[tigerw]

I suppose there wouldn't be overlap if Mojang say, kept on adding new states to grass thereby shifting all the mappings along each time. Otherwise they'd just be adding more entries to the end.

For the internal storage format presumably full backwards compatibility can be maintained if the format is as before (blocktype, nibbletype) but with larger storage types.

However, any sort of internal representation that isn't strings ("minecraft:potato_chips" crispness:1 colour:1000) would be impossible as now we would have to write and maintain a (internal <-> vanilla state) map in order to use the generated protocol mapping. Right?

If so, it seems like we are forced to use a slow option.

[tigerw]

But still, killing backwards compatibility altogether might be a bad idea, unless we have the time or can convince authors to update plugins. So, perhaps writing that BLOCKTYPE/NIBBLETYPE-to-String/State map might be worth it in the short term. In fact, I could add something to that PR I mentioned for that; it would be a start.

[xoft]

I like the new string-based format, it is highly extensible, plugins could finally be made to extend the blocks and items easily. And I don't think it's too much slower than current, in the end most of the operations are just number-based (and we're going from two numbers per block to a single number per block); the operations on strings only take place when manipulating something in a way that doesn't require too much performance, such as placing and removing blocks.
If we find that the string manipulation is slow, we could adapt it with additional performance boosters, such as hashing the entire BlockState to improve comparison, etc.

And, on the plus side, having a per-cProtocol map of block types means that we can finally support older protocols properly - the blocks not available in them can get replaced with a placeholder, rather than sent through and crashing the client.

[tigerw]

Ok. In that case can we update our Lua version? :)

[xoft]

Yea, we can do anything. Although I'd prefer not to do it all at once. Let's get the block type registy in first, then the item type registry, then BlockArea, and then all the rest.

[Aberts10]

Have the plans changed any? 1.14.2 has come, and the 1.13 support in Cuberite seems stalled (if going by the 1.13 branch)?

[xoft]

Yeah, well, real life has caught up, so the development is kinda dead now.

[xoft]

Astonishingly I got some free time despite the family matters, so I dived into this a bit more. I've started adding real blocks to the block type registry, and I have to say I'm surprised by the amount of blocks that got added to Minecraft since we last updated.