08-18-2012, 08:06 PM
how many phases are there? you now have phase 2 partial.
Joining the packet sources
|
08-18-2012, 08:06 PM
how many phases are there? you now have phase 2 partial.
08-18-2012, 08:41 PM
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.
08-18-2012, 09:08 PM
(08-18-2012, 06:54 PM)xoft Wrote: Another side-effect detected: 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.
08-18-2012, 09:38 PM
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.
08-18-2012, 09:53 PM
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
08-18-2012, 10:43 PM
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.
08-24-2012, 10:40 PM
in what phase are you now?
08-24-2012, 11:27 PM
I believe it's phase 3.7delta-Pineapple
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
08-26-2012, 07:49 AM
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.
|
« Next Oldest | Next Newest »
|