Efficient loading of blocks

@SycoPrime
@Yogoda

I was having a look at the code to see if the 0x33 packets could be used to improve efficiency of block updates. The packetss send a cuboid of data (the cuboid must be entirely within 1 chunk).

It seems that the server can already do this without any changes (not sure if this is a Bukkit thing or vanilla thing).

It queues block updates for each player and then sends them as a burst.

The burst is triggered once per tick or when you change chunk. This means that if you don't change chunk you can keep all your packet updates in one place.

This means that if you don't change chunk then you can update loads of blocks with a single packet.

I ran a test with a code that "flashes" a cuboid every 2.5 seconds. I had 3 settings

- "Worst" updated the blocks starting with the lowest plane and working upwards (y was the outer loop)
- "Normal" updated the blocks in vertical planes (y was the inner loop)
- "Best" updated all the blocks in one chunk at the same time and then moved on

Worst would change chunk the most as it processes the blocks one horizontal plane at a time.

The size of the zone was 100x100 and 10 blocks high and it was made up of a mix of 8 different blocks with the id updated by a counter.

The results were:
"Worst"
Period: 3s
Bandwidth: 131kbps

"Normal"
Period: 3.6s
Bandwidth: 155kbps

"Best"
Bandwidth: 97bps
Period: 3.5s

The period is the period of the flashes. It was set to 2.5 seconds, but server load meant that it didn't actually operate that way.

The "Best" ordering gave a reduced bandwidth but with higher CPU usage. The "Normal" ordering actually made things worse.

I think the problem may have been that compression doesn't help if the blocks are not regular.

This is probably subjective, but the client appeared to react better to the "Best" ordering.

Btw, with Move Craft, do you guys check if you are updating air->air and don't bother with it?

A potential problem with the server algorithm is that if you update more than 10 blocks in a chunk, it switches to 0x33 mode. This means that if you updated 2 blocks in each of the 16 corners, it would update the whole chunk instead of just sending the 16 blocks that you updated.

Anyway, looks like the compression doesn't give quite the boost I thought it might. However, it is still there. Also, it might be different when the server and client aren't loading down the same machine .