Yeah, I noticed the 1 byte sized packet for Dismiss on SoD and UF as well, but in my collects from VoA, they are 0 bytes. I am guessing that the case is the same for the Timer Request packet, assuming that is what the packet is for. I am not 100% sure the opcodes are correct for those on SoD and UF compared to what I have for VoA, but the order looks correct as far as I can tell so it should be.
I think we could probably just change the size check to see if it is > 1 instead of != 0 for the Timer Request, which is what I set already for the dismiss request. I have no idea what the 30 (48 in decimal) means, but that is the same thing I was seeing in the dismiss packets in SoD and UF. It may be that the client is sending that because of some mistake elsewhere in the data we are sending in other packets, but that is just a guess at best.
The Unknown 0x3401 opcode is most likely not merc related. I don't see the equivalent opcode being sent in my merc collects for VoA. Also, it is near most of the earlier opcodes, and merc opcodes are much later and all near each other in the order, so it is probably for something else like deleting spawns or something.
Maybe I can get some time to mess with the suspend timer stuff and see if I can get that working.
I haven't messed with the code for it at all yet, but I could probably look into getting the extractor working for Live, and maybe SoD if that is an issue and is needed. Unfortunately, I kinda suck at reading packets that haven't been dumped, cause I don't know the packet header stuff too well yet. I am sure I could figure it out though. I think the collector only requires a minimum amount of correct opcodes and structures to function, so it shouldn't be too hard to get that working. I think one of the main things is to make sure the PP packet struct is correct size. I really don't know why it would error out on any DZ packet sizes, as that seems to be completely irrelevant to identifying client version unless Derision changed the extractor to use that packet for identifying the client instead of the one we use for EQEmu. It would probably take a bit for me to familiarize myself with the code for the extractor, but it would be good stuff to know anyway. I am sure Derision would appreciate help with maintaining it so he isn't the only one doing it.
|