As you may or may not know, BnetDocs has been updated quite a bit recently. Certain people who have made a number of contributions have been given permission to edit certain things, likely so that Arta doesn't get bogged down with questions or requests... :)
I've also been redoing my own bot a fair bit, and checking some things against BnetDocs, testing a few things, and updating some things (only three things have I updated at this point). I've also come up with a list of questions for myself.
I figured that with the amount of time that I really don't have to try to find the answers (most of them are simple, but my bot is not at a point for me to be able to answer them at this time), so I figured I might start a thread here for people to post questions about BnetDocs and answers to them. If you're feeling really bored, you can go through BnetDocs and find things that might be a little vague or perhaps not even fully documented, and either ask questions or provide an answer. Then, I'm sure some of the recently-made editors of BnetDocs would be happy to update the information to be correct.
This could serve the dual-purpose of providing a kind of version or update history of BnetDocs. Those of you who've already implemented your bot according to one (wrong or incomplete) statement on BnetDocs can read here and update your bot accordingly.
I'll get ya'll started with some things to do that I I don't have the time to find the answers for:
- Get valid results for S->0x78
- Get valid results for S->0x7A
- Verify Status is a DWORD for S->0x74
- Get valid results for S->0x74
- Get valid Type and Status values for S->0x67
- Verify Result is a DWORD for S->0x71
- "Commonize" naming for Result / Status byte (DWORD in some packets, apparently?) for clan packets (I would likely use "Result" as the name)
Here's the three items I've already done:
September 13, 2004 12:10 AM
- Added packet format for S->0x77
- Moved valid results for S->0x77's Format field to Description field
September 12, 2004 11:00 PM
- Added 0x07 (Not Authorized) to valid result for S->0x73
Hopefully this works out to an advantage... :)
I updated a lot of things recently. If you previously used BnetDocs for information on SID_AUTH_CHECK (from server), SID_NEWS_INFO (from client), SID_NEWS_INFO (from server), SID_QUERYREALMS (from server), or SID_QUERYREALMS2 (from server) then you may want to check the new information up on those messages.
Other things that need doing - combined message 0x44.
Quote from: Skywing on September 23, 2004, 02:10 PM
I updated a lot of things recently. If you previously used BnetDocs for information on SID_AUTH_CHECK (from server), SID_NEWS_INFO (from client), SID_NEWS_INFO (from server), SID_QUERYREALMS (from server), or SID_QUERYREALMS2 (from server) then you may want to check the new information up on those messages.
Other things that need doing - combined message 0x44.
I've submitted a couple of the combined messages on 0x44, and I'd like to keep working on further decoding. If anyone wants to help out, give me a holler.
Updates/additions from UL:
- Added format for BNCS S->C 0x7E
- Added packet 0x82 for BNCS
- Added packet 0x19 for MCP
- Added additional status codes for various MCP messages.
- Added additional status code for BNCS SID_AUTH_CHECK
- Added much more additonal information which is hiding for now. (defunct packets, pretty much every packet on there with no name given)
Todo from UL:
- Add S->C packets for D2GS
- Figure out uses of BNCS packets (both C->S), 0x66, and 0x80.
- Add BNCS 0x35
- Add e-mail related messages
- Other things, perhaps get Arta to add Storm information
Quote from: UserLoser. on September 23, 2004, 06:58 PM
Updates/additions from UL:
- Added format for BNCS S->C 0x7E
- Added packet 0x82 for BNCS
- Added packet 0x19 for MCP
- Added additional status codes for various MCP messages.
- Added additional status code for BNCS SID_AUTH_CHECK
- Added much more additonal information which is hiding for now. (defunct packets, pretty much every packet on there with no name given)
Todo from UL:
- Add S->C packets for D2GS
- Figure out uses of BNCS packets (both C->S), 0x66, and 0x80.
- Add BNCS 0x35
- Add e-mail related messages
- Other things, perhaps get Arta to add Storm information
What is the point on adding information about defunct packets?
Quote from: Minus on September 23, 2004, 09:43 PMWhat is the point on adding information about defunct packets?
It should be obvious; Bnet docs is there as a reference, and what I do when I see something wierd or I don't recognize is I go there. If it has information about it than it is no longer an unknown uncontrollable variable, hence better/more valid testing, and more reliable programming can be achieved because it reduces your chances of being surprised.
Thanks for all your hard work guys!
Minus: I'm sure you'll enjoy ripping all the new content for your website. Try to be a little less obvious next time, eh?
Quote from: UserLoser. on September 23, 2004, 06:58 PM
- Other things, perhaps get Arta to add Storm information
I have tons of Storm functions that I reversed/mapped out, and I'd be happy to share. I also have many that I have given names, but haven't gotten the parameters for yet, that I can also post.
If Arta wants to make an area for it, or however it works (?), I'll post up what I have.
Quote from: MyndFyre on September 23, 2004, 05:34 PM
Quote from: Skywing on September 23, 2004, 02:10 PM
I updated a lot of things recently. If you previously used BnetDocs for information on SID_AUTH_CHECK (from server), SID_NEWS_INFO (from client), SID_NEWS_INFO (from server), SID_QUERYREALMS (from server), or SID_QUERYREALMS2 (from server) then you may want to check the new information up on those messages.
Other things that need doing - combined message 0x44.
I've submitted a couple of the combined messages on 0x44, and I'd like to keep working on further decoding. If anyone wants to help out, give me a holler.
I might be interested in doing some work on this. Do you have an IDB for the latest game.dll that you are using..?
- Noticed "Formal name not known" for S->C SID_FRIENDLIST, but not C->S; is the formal name known for client-sent but not server-sent? ;)
- I remember something about getting the formal packet names from old Storm librarys, but that they're not in them anymore; are the clan packet's formal names known thusly?
Quote from: tA-Kane on September 24, 2004, 03:42 PM
- Noticed "Formal name not known" for S->C SID_FRIENDLIST, but not C->S; is the formal name known for client-sent but not server-sent? ;)
- I remember something about getting the formal packet names from old Storm librarys, but that they're not in them anymore; are the clan packet's formal names known thusly?
Blizzard stopped putting the names for the packets in Battle.snp a long time ago, AFAIK, the highest one last seen (in value), was 0x5B (SID_AUTH_DISCONNECT)
Quote from: Arta[vL] on September 24, 2004, 04:55 PM
I'd be more than happy to add a storm ordinals section to the site. What form would be best? Just a list, or do you think they should be database-ised?
I'd say a list
Well, my list looks something like this:
Quote508 int SStrCmp(char *str1,char *str2,size_t size);
509 int SStrCmpI(char *str1,char *str2,size_t size);
510 int SStrUpr(char *str)
Note - 569,571 and 570,572 are the same functions
569 char *__fastcall SStrChr(char *str,char c); // Returns the substring after the first occurance of the specific character in the string. Returns NULL if the character is not found.
570 char *__fastcall SStrChrR(const char *str,char c); // Returns the address of the final occurance of c within the string str. If it is not found, NULL is returned.
571 char *__stdcall SStrChr(char *str,char c); // Returns the substring after the first occurance of the specific character in the string. Returns NULL if the character is not found.
572 char *__fastcall SStrChrR(const char *str,char c); // Returns the address of the final occurance of c within the string str. If it is not found, NULL is returned.
579 SStrLwr(char *str)
Maybe three fields, the ordinal number, the prototype, and a description. I would say it's best to list them all together, though, because navigating through a list of single entries would be a pain.
I prefer databases over a single document, but whatever floats your boat.
I think a document (similar to the defines for various things) could be used for the declares to use Storm, and then a database with an entry for each call that describes the call, in terms of its parameters and what it does.
It might be worth pointing out that the Diablo II team screwed up some of the Storm ordinals, so some things you find may not work on the D2 version of Storm (or on other versions, depending on which you are doing your research with).
I think a database would be best. A list down the side, same as for packets, and then clicking on the functions should lead to a page explaining what the function does, possible GetLastError() values, and return values. That is quite a bit of work though, so if no one wants to get that far into it, perhaps just a list would be better - in which can I'll make a document for it.
Whichever is best for those involved.
I'd be happy to put some work into it.