Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=984
I received a "unknown packet 0x1bc" disconnect when using the newly implemented /recall command, so I investigated...
turns out that there is a sort of problem in the packetdb loading code.
CODE
if (packet_db[packet_ver][cmd].func != clif_parse_func[j].func)
{ //If we are updating a function, we need to zero up the previous one. [Skotlex]
for(i=0;i<=MAX_PACKET_DB;i++){
if (packet_db[packet_ver][i].func == clif_parse_func[j].func)
{
memset(&packet_db[packet_ver][i], 0, sizeof(struct s_packet_db));
break;
}
}
}
In other words, if I use two different names (which use the same function) for 2 different packets, this thing will wipe out the first one of them. I have yet to find a reason why such a thing is done. Blame goes to Skotlex@
r2525, the very initial multi-packetver implementation.
Side note:
The embedded packet table seems to have packet lengths for client->server packets as well, although they're outdated and not used at all.
Side note:
CODE
packet_ver = MAX_PACKET_VER; // read into packet_db's version by default
while( fgets(line, sizeof(line), fp) )
{
...
if(strcmpi(w1,"packet_ver")==0) {
int prev_ver = packet_ver;
// copy from previous version into new version and continue
memcpy(&packet_db[packet_ver], &packet_db[prev_ver], sizeof(packet_db[0]));
now what this does on the first iteration (when beginning to process the first version, no. 5) is, that it memcpy-ies packetver 22 (which is totally empty at this point) into packetver 5 (which is equally empty). I'm not sure if this no-op is intended or not.
This post has been edited by theultramage: Feb 16 2008, 11:06 AM