Cuberite Forum

True.

It also happens when one would regenerate a chunk while that chunk is surrounded by players.

Yeah, another corner-case

Still, I decided to make this possible. It elegantly wraps the chunk serialization into a separate class, replacing the serialization in cPacket_MapChunk.

There, it's done. Another phase finished, 3 done, 4 to go. Now for the more fun stuff.

and when phase 4 is finished mc-server is compatible with 1.3.2 or is that another phase?

It will take all 7 of those steps to get compatible with 1.3.1 (or 1.3.2, if it uses the same protocol)

ok and 1.3.2 and 1.3.1 are using the same protocol.

Half of the cPacket classes are gone (those that were S->C only) and are serialized now directly in the cProtocol125 class. Man, wasn't that a huuuuge change.

Nice job man!

Another phase down - rev 802. cPackets are now all gone.

cProtocol125 is now more or less what I had planned for it to be; there are some tweaks I'd do, but those can be done later.

Now I'm gonna have a look at the 1.3.2 protocol. Especially the handshake, as I'd like to be able to detect between the two protocols transparently and have the ability to support both. If that it not possible, I'll just start a 1.3.2 protocol and there will be a compile-time switch, until it is ready.
Tomorrow. I keep working on MCServer too much

Quote:Especially the handshake, as I'd like to be able to detect between the two protocols transparently and have the ability to support both. If that it not possible, I'll just start a 1.3.2 protocol and there will be a compile-time switch, until it is ready.

Why compile-time switch? Why not .ini key? (I mean, I can't imagine any case in which you can't have both protocols in server code, despite the ability to detect which one client is using)