Network messages for parts should be bulked together

[MrTJP]

Grouping together all part changes might be worth considering, as the overhead per packet can quickly add up, especially if you have a large number of parts per tile. Heres how I think it can be handled better.

1) Don't use the built in tile update method on tile entities. Chunk watch/unwatch events can be used to send tile descriptions to clients as necessary. As players enter chunks, all multipart tiles in the chunk are asked to write data to a single buffer which is flushed at end-of-tick

2) Part data updates which contain small, incremental updates (not the full description of the part, as that would be handled above) would also be handled the same way. All part updates for the entire chunk would be written to a single buffer and flushed end-of-tick. Should a part wish to send a full description, that can easily be handled by said part.

CB's ForgeMultipart had a similar implementation to this, and it had been tested and proven to drastically reduce packet overhead especially when you had a large number of multipart tiles in a small area that were rapidly changing. I am quite familiar with it's networking system and I can quickly write this up for you for your consideration.

For an example, consider a redstone circuit consisting of 500 wires. Each one needs to write a byte to describe its signal strength. That would mean sending 500 packet updates, each with an overhead more than double the actual data.

[2xsaiko]

Apparently this is implemented in MCMP2.