Heightmaps and Lighting

[gentlegiantJGC]

There are currently two open issues for heightmaps and lighting but there is one common issue that is stopping these being implemented. This report will cover those issues.

To start lets explain the problem. The issue is that the implementation of height and light data is specific to the platform and version the data is being saved to. Wherever the logic is implemented it will need to be aware of that to calculate it correctly.
The lighting logic will need to be aware of the light levels that blocks emit and how other blocks block the light which is information that we currently don't posses and I am unsure how we could access that data dynamically to support modded blocks. Lighting also has the complexity that it requires information from surrounding chunks and may need to also modify those surrounding chunks.
Historical and Bedrock heightmaps I believe just look for the first non-air block which is relatively easy to implement but the newer Java heightmap format is in a similar situation to lighting in that it requires data we don't have.

Assuming that we are able to dynamically access the required data, or manually find it per version for vanilla blocks, there are a number of different solutions.

1. The first but least user friendly option would be to have an operation that the user has to manually run and pick the data they need to calculate. This would give the most control to the user but would not be user friendly for new users.
2. The second would be to have that operation automatically run after every operation that modifies the world but before the backup logic runs. This would slow down all operations and in most cases would be pointless because the user may change the chunks before actually saving.
3. The third option is to somehow run this logic in the process of saving. This is the best option as it would only be run when required and would also work if directly using amulet-core. At a glance it would seem like the best place is in the actual chunk saving logic because that is aware of the platform and version and has access to the chunk but it does not have access to modify neighbour chunks. My proposed solution is that the operation runs at the point of the save logic starting and once finished does the backup logic before running the normal save logic. This will allow for modifying more chunks than just the ones which have been changed. The only negative effect of this is that a phantom undo will appear each time the user saves. With some modifications it could be possible to merge this with the previous undo batch.

Summary: My proposal is that an operation is run at the start of the save logic that can modify the world data in the same way a normal operation can before saving the chunks to disk. This could be extended to a system that runs customisable operations when saving of which light and height would be one operation

[Eiim]

The lack of 1.15/old Java heightmap support prevents correct conversion of 1.16 worlds to 1.15-. When attempting to convert a 1.16 world to 1.15, the 1.16 heightmap is currently kept. Everything appears fine in Amulet, but when opening the world in MC, the incorrect heightmap format causes a NPE when loading the chunks, and new chunks are generated in their place, completely removing the imported data. In the example image, I pasted heighmap data from a random 1.15 chunk into a single chunk in a world which had undergone this 1.16 -> 1.15 process, and that chunk was loaded correctly (other than that the heightmap is surely screwy) while all the other chunks threw errors into the console and were overwritten.

Since old Java heightmaps are apparently relatively simple, it may be worth adding them before new Java heightmaps. Alternatively, as a stopgap, a base heightmap could be added in the conversion process, such as one which corresponds to all y=0s or some such. This would cause rain to behave unexpectedly, likely among other issues, but it would be better than the conversion being useless altogether.

[gentlegiantJGC]

Amulet-Team/Amulet-Core/pull/121 fixes this