New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I found the canonical name for every packet type #52
Comments
So I definitely think that this information needs to be in the documentation. The question is: should we replace the existing packet names with these, or should we simply add this to the existing packet information? |
Heh, Personally, I'd replace the existing packet names with these, while keeping the current name in a smaller font. |
Actually, this kind of relates to the big question, ticket #50. The problem is, the current documentation contains a list of "Logical Packets", whereas this is a list of "Real Packets" (the major types only). Previously, we haven't had any real mention of the major types by themselves. Only recently, when we sorted the packet list, did it become clearer that there are groupings of packets. I'm hoping we can, in #50, include a simple description of the parser (0xaabbccdd => such-and-suchtype, etc) which would mean we could use those names there. But personally, I think they should be of secondary importance in the documentation. |
I agree that there is a mismatch: our names are applied to subtypes, whereas these names only exist at the major packet type level. Personally, I think the packet names we have now are better, since they're more useful to the code that ultimately consumes this information. |
I think it be very helpful to show a simple 2-level parsing hierarchy, for the sake of overview. Something that looks like a set of nested switch statements. That could use these names, for clarity. I'll whip up an example when I get home |
I can confirm that packet 0xf5821226 appears to be a heartbeat packet. What's currently stopping anyone from giving it a name in the docs? |
v2.6.0 has a packet type 0x902f0b1a. I've seen exactly ONE of them, server to client. Don't suppose your magical brute-forcing script can reverse-engineer that one? Happened approx 2.5mins into a 5-minute game, no idea who/what triggered it, might be some new-ish variation of a gmText? We DID have a GM in that game (clientConsoles packet tells me so). 1a0b2f902d000000570065006c0063006f006d006500200074006f002000740068006500200041007200740065006d0069007300000065006500650065006500650065006500650065006500650065006500650065006500650065006500650000000300000020000000000003000000200000000000 # 2.6.0 payload Purely speculative guesses: |
Update: 0x902f0b1a == JamCRC("bigMess") |
Fixed by #82 |
Going with @IvanSanchez's idea, I was able to build an intelligent brute-forcing script to search strings and substrings for matching hashes. The results can be seen below. These matches are quite obviously not random :)
To me, this explains quite a few things! For example, why are the major types sometimes related in terms of function, and sometimes not at all? For example, 0x0351a5ac covers both Helm, Eng and Game Master. Now we know it's simply because of convenience, since 0x0351a5ac is a packet with a single float. This also tells us that we can always expect 0x0351a5ac to have a single float, unless the name is incredibly misleading ;-)
My personal favorite: Packet f5821226, which we suspected to be a heartbeat packet, is now known for sure to be a heartbeat packet. Also, packets like "valueInt" and "valueFourInts" tell us quite a great deal about the expected format, and how unlikely it is to change in the future.
To be honest, I like the existing names better than these ones, but it's certainly very interesting to have found the source of the packet IDs :)
The text was updated successfully, but these errors were encountered: