MOTION_BLOCKING heightmap

[tim-kt]

Objective

Aims to implement #104. This is a draft, I don't necessarily need a review yet.

Solution

The server needs to generate a heightmap when chunks are generated, update them when blocks are changed, and send it in the ChunkDataS2c packet.

I think the implementation should be done in the following order:

• Encode (constant) heightmap and send it in the ChunkDataS2c packet
• Build heightmap in write_init_packets
• Find out which blocks are "motion-blocking"
• Implement a blocks_motion function
• Change weather.rs to test the functionalityWORLD_SURFACE
• Find out why one needs to add 2 to the heightmap

[dyc3]

I think it would be good to update the weather example to show this functionality.

[rj00a]

The way I think we should handle this is by keeping the heightmaps completely contained in the write_init_packets function. We can rebuild the heightmaps there from scratch whenever the ChunkDataS2c packet cache needs to be created. This would avoid all the complexity involved in updating the heightmap whenever a block is modified.

We should also figure out which blocks exactly are considered "motion blocking" by the game and extract that information. And also figure out what WORLD_SURFACE is used for.

[tim-kt]

It seems like "motion-blocking" blocks are more or less solid and liquid blocks, waterlogged blocks included. One way to check this would be to examine the packets of the vanilla server in minecraft:debug and from this, generate a mapping from block state to motion-blocking or not. Has something like this been done before for Valence?

[rj00a]

You'll want to take a look at the extractor/ folder. That contains the fabric mod we are using to get information from the game.

So it seems like the main thing we're missing is an is_solid method for BlockState.