@xmcl/world - Chunk corruption fix for palette sizes >=16

[John-Dean]

Fix for palette size >=16 by implementing code from here: https://github.com/spoutn1k/mcmap/blob/fec14647c600244bc7808b242b99331e7ee0ec38/src/chunk_format_versions/section_format.cpp#L6

[John-Dean]

Added a second minor commit to support the new Minecraft Chunk format (aliased Palette/BlockStates with block_states.palette and block_states.data respectively)

Added a new exported function to directly export the section's block array directly for non-legacy section formats, otherwise returns a blank array.

[ci010]

Sorry maybe I missed something,

Added a new exported function to directly export the section's block array directly for non-legacy section formats, otherwise returns a blank array.

Which function do you mean here?

I just want to make sure we still have legacy support.

[John-Dean]

No worries I should have been more clear.

When it detects a new chunk format (not the legacy one) it uses getSectionBlockIdArray to get the block id array (variable was previously called vector).

I have also marked this function as exported so you can choose to use this directly.

This should be a non-breaking change that both maintains backwards support with older versions, fixes the chunk corruption and adds the new exported function getSectionBlockIdArray useable on sections with a non-legacy format.

Please let me know if this doesn't make sense.

[ci010]

No worries I should have been more clear.

When it detects a new chunk format (not the legacy one) it uses getSectionBlockIdArray to get the block id array (variable was previously called vector).

I have also marked this function as exported so you can choose to use this directly.

This should be a non-breaking change that both maintains backwards support with older versions, fixes the chunk corruption and adds the new exported function getSectionBlockIdArray useable on sections with a non-legacy format.

Please let me know if this doesn't make sense.

Sure, let's update the branch with master and run tests for it. As long as the old tests for 1.12.2 and 1.14.4 don't fail, it will be totally ok for me.

[ci010]

Also, can you add new test files (.mca) under mock/saves/<your-tested-version>? With test file, we can later refactor code with knowledge that if the change is breaking the old test.

You just need a single chunk r.0.0.mca (or more mca file if you need, but please keep size minimal) and the mock.txt which contains the actual block data from Minecraft there.

To generate the mock.txt (containing the dump data). You can run following script in MinecraftForge environment for your test level. https://gist.github.com/ci010/27415d55a3e72399924433b759924f2e

[John-Dean]

Hu @ci010 I've merged the master branch with this and I've added in some test .mca files - but I have no idea how to generate the mock.txt files (I've never used Forge and upon installing it I couldn't work out how to run the .java file you provided).

I've explicitly made sure the test regions have >16 types of block in at least 1 region so we can test the palette corruption fixes.

Can you either generate the mock.txt file or post a walkthrough of how to generate them?

Thanks,
John

[ci010]

Hu @ci010 I've merged the master branch with this and I've added in some test .mca files - but I have no idea how to generate the mock.txt files (I've never used Forge and upon installing it I couldn't work out how to run the .java file you provided).

I've explicitly made sure the test regions have >16 types of block in at least 1 region so we can test the palette corruption fixes.

Can you either generate the mock.txt file or post a walkthrough of how to generate them?

Thanks, John

Sure, let me add the mock.txt files then