GreenBox Posted March 16, 2012 Group: Members Topic Count: 9 Topics Per Day: 0.00 Content Count: 303 Reputation: 101 Joined: 11/13/11 Last Seen: October 11, 2023 Share Posted March 16, 2012 (edited) Hi, I was adding support for bRO clients packets and that seems weird to have alot of packet_ver's for kRO and adding one for bRO. There is no reason to use packet_db if every time you change your client you must change the PACKETVER and maybe change the packet_ver. It's best to hardcode the packetdb on the source code(like here), and choose the packets with the preprocessor based in the PACKETVER(and other #define's also) so we can have more control over the packets. Edited March 16, 2012 by GreenBox 2 Link to comment Share on other sites More sharing options...
Wildcard Posted March 17, 2012 Group: Members Topic Count: 2 Topics Per Day: 0.00 Content Count: 28 Reputation: 20 Joined: 01/22/12 Last Seen: February 3, 2019 Share Posted March 17, 2012 This is true, and has been brought up many times, it's just that noone has gone through with it yet. I added a TODO on the wiki. 1 Link to comment Share on other sites More sharing options...
simplynice Posted April 21, 2012 Group: Members Topic Count: 25 Topics Per Day: 0.01 Content Count: 128 Reputation: 4 Joined: 11/14/11 Last Seen: April 13, 2016 Share Posted April 21, 2012 I'm in to this. If we can optimise it then why not. Good suggestion sir. Link to comment Share on other sites More sharing options...
Skotlex Posted May 16, 2012 Group: Members Topic Count: 0 Topics Per Day: 0 Content Count: 6 Reputation: 0 Joined: 03/20/12 Last Seen: December 17, 2013 Share Posted May 16, 2012 Hmm.... I do have some objections to the idea behind this. It is troublesome that there are two places where packet definitions are stored (clif.c and packet_db.txt), however there is a reason for this: The packet_db file stores packets and their structures as they are received/sent by clients. clif.c holds packet lengths and definitions for replies to the client. The server uses a PACKETVER define to decide how to structure packets before replying. Why it can't use the packet_db information itself? Well, besides code-complexity, in many cases you don't know which version are the multiple recipients. And, you can always use an older PACKETVER value and the clients will still work as they usually have no problems accepting old packets as replies. The packet_db file is useful because it allows people to add the information required to parse new clients without having to modify the server code (by simply mapping the new packets to previous versions, or mapping them to be discarded if they cannot be supported yet). clif.c is slightly smart in the sense that clif_send calls will drop packets that are not supposed by a client (so if a server creates a response using a newer packet which is not supported by a target recipient, it will be dropped). However, this only applies to area packets that are send to multiple targets, not those who are directly sent to a single recipient. I suppose it would be possible to rewrite the system to use a single packet_db file that also includes the structure for server-reply packets (thus deprecating the need for PACKETVER), but that would require an almost complete rewrite of most functions in the clif.c file. Hmm... all in all, this would be no minor task. I do agree that server auto detecting the client version is no easy task (using the wantToConnect packet to identify the version), though it already doesn't hurt to leave the guessing in place, rather than lock down the server to supporting a single version. Link to comment Share on other sites More sharing options...
Recommended Posts