Joining the packet sources

[NiLSPACE]

how many phases are there? you now have phase 2 partial.

[xoft]

I expect three or four phases. But the current one is too long and it actually makes sense to commit it in partial increments, because things still do work in each such increment. I don't want to work on this for a week and then find out someone has been fiddling with the code in the same place and we have code conflicts that I need to resolve first, before committing. It also gives others a chance to comment on the new style.

[FakeTruth]

Another side-effect detected:
Some cPacket descendants were exported to Lua and plugins were using them, both to send packets and to handle hooks (BlockDig, BlockPlace). These will be removed, so Lua hooks' signatures will change and the plugins will not be able to invoke default behavior with a modified input data. I don't think this matters much, since it was a very under-documented feature anyway and I don't think anyone would be using that in a plugin anyway.
The interface change, though, is not so great. We'll have a new round of plugin incompatibility

I saw that. Unfortunately this breaks even more than just Lua functions, this breaks functionality.

Before your change you could alter the packets in Lua before sending it back to MCServer. I'm not sure why anyone would do this, but it was possible!

How about wrapping such hooks in a struct? Like before, but this time for ONLY storing the data and not for parsing etc. This should also make it easier to make protocol changes, because you can simply edit the struct and you don't have to change function signatures.

[xoft]

I don't think it's worth the trouble. If a plugin wants to perform a default handling on modified data, it can call the cClientHandle handler with the modified data. The handlers will be Lua-exposed, in the end.

[FakeTruth]

Okay

It would by like the OnTakeDamage callback though http://mc-server.org/wiki/doku.php?id=ap...takedamage that function uses a "TakeDamageInfo" object

[xoft]

I don't think Lua minds if you call its function with more parameters than it actually declares. So for added fields, we can simply add them and plugins will continue working. For fields that are removed, we can simply pass in a default value. And worst case scenario, changed fields, can be expressed as a combination of add + remove.

We'll see how it works, if it's not good enough, we can pack it in structures later on.

[NiLSPACE]

in what phase are you now?

[FakeTruth]

I believe it's phase 3.7delta-Pineapple

[xoft]

Something like that. I'm still removing cPackets from all over the place. so to recap:
Done:
- utility classes - cByteBuffer
- packet handling doesn't take cPackets, but their raw data (cClientHandle::HandleXYZ)
Doing:
- sending packets from various classes doesn't use cPackets, but their raw data (cClientHandle::SendXYZ, cWorld::BroadcastXYZ et al)
To do:
- move packet handling and packet sending from cClientHandle to a separate cProtocol class
- remove cPacket classes altogether, pasting their code directly into cProtocol
- add a cProtocolDetector that can detect 1.2.5 or 1.3.1 protocols
- add a cProtocol descendant for 1.3.1

[xoft]

I'm contemplating the actual need to implement MapChunk packet serializing once for multiple players. With how things work now, the only way for this to be actually used is when two players wander off the known world into the same place at the very same moment. With the chunk generator generating in excess of 50 chunks per second, this is almost never gonna actually happen on a real server.