Towards 1.13

[Seadragon91]

If you want I could update the protocol to 1.14.4. As I read we would drop support for the old protocol versions:
- Merge all packets in protocol file for 1.14.4
- Removed all old protocol files
- Update packets: Ids, update fields
- Comment all packets that changed

[xoft]

Not yet, we first need the changes in the underlying representation - go from numeric BLOCKTYPEs to stringular, using the BlockTypeRegistry. If you want to help, I could use help after I get this first part merged, I'll take on the BlockArea rewrite and someone needs to refactor the block handlers, bring some sanity to them.

Unfortunately the protocol will most likely be one of the last things to do.

[xoft]

I think the registry is now ready, it's waiting for a review. It can be merged into master without disrupting anything, it is initialized but not used anywhere yet.

I'll start working on the next step, the basic BlockArea implementation that provides storage for text-based blocktypes.

[xoft]

As for the item type registry, that is not immediately needed, so I decided to let it wait until the BlockTypeRegistry settles down, we see how it works and then model the ItemTypeRegistry in a similar fashion. I'm still considering whether to make one template registry, specialized into Block- and Item-type registry, or whether to implement two completely separate Registry objects.

[xoft]

Basic BlockArea implementation is done (PalettedBlockArea class), it supports getting and setting individual blocks, and pasting other BlockAreas. There's no merging yet, that will need a bit more thought about how to define the merging process. It should be sufficient to support rewriting the world storage, loader and generator to the new BlockArea now, so that's what I'll try next. Not sure if I'll need the BlockEntity and Entity storage added to the PBA class, that could complicate things a bit.

[xoft]

More complications. PBA stores neither blocklight nor skylight, yet those need to be stored within the chunks. So chunks cannot be based just on PBAs. How should I combine these together?

This seems like the most reasonable skeleton:

class Chunk
{
  struct Section
  {
    PalettedBlockArea mBlocks;
    NIBBLETYPE mBlockLight[16 * 16 * 16];
    NIBBLETYPE mSkyLight[16 * 16 * 16];
  };
  using SectionPtr = std::unique_ptr<Section>;

  SectionPtr mSections[16];
};

The question is whether to make the entire sections optional like in the code above. If a section isn't present and a query comes for blocklight or skylight, what should the query return? Another option would be to make all 16 sections necessary, but each member of the section is optional. Now, looking at some 1.14 saves, I see that Vanilla sometimes doesn't store the BlockLight, sometimes doesn't store SkyLight, and sometimes neither. So it might be beneficial to wrap each of the light arrays into a structure that supports two states - either individual 16*16*16 values, or a single value for the entire section. That could produce some memory savings. However, it could be postponed as a later optimization.

[xoft]

Another option would be to store the light values in an entirely different class, with a separate get / set API.

[NiLSPACE]

Why can't PBA store the lighting as well like the original BlockArea does?

[xoft]

I don't think it should. We only need the light values stored when using it to store the chunk data, it doesn't make sense for it to store the light in any other scenario (can't copy & paste light, can't save to file etc.) And I don't want to end up with another set of BlockArea.baSkyLight flags, those didn't work too well.

[NiLSPACE]

In that case I like wrapping the arrays into a structure the most.