08-11-2012, 06:14 AM
I'm not planning on having that old protocol support forever. It's just a temporary measure for when there are two versions out in the public. Once there is a prevalent version of the protocol, the old one can be cut off (or left in if it's not too much of a trouble).
Also, most changes to the protocol don't include changes in the chunk block serialization (an exception being the change in chunk height and axis direction, but that happenned once). I don't plan on modifying the sent blockdata dependent on block support in the clients (such as replacing emerald block with stone for older clients), so once serialized, the block data will be used by all protocols.
The simplification will go only to the granularity of "metadata changed" event, no further. When in today's code you construct a cPacket-desendant instance you'de be sending a protocol command instead in the new version.
I even think the refactoring I'm proposing will make things faster, because packet objects won't have to be allocated (especially on the heap while queueing them), and copy-constructed, thus getting rid of two potential bottlenecks.
Also, most changes to the protocol don't include changes in the chunk block serialization (an exception being the change in chunk height and axis direction, but that happenned once). I don't plan on modifying the sent blockdata dependent on block support in the clients (such as replacing emerald block with stone for older clients), so once serialized, the block data will be used by all protocols.
The simplification will go only to the granularity of "metadata changed" event, no further. When in today's code you construct a cPacket-desendant instance you'de be sending a protocol command instead in the new version.
I even think the refactoring I'm proposing will make things faster, because packet objects won't have to be allocated (especially on the heap while queueing them), and copy-constructed, thus getting rid of two potential bottlenecks.