BNCS 0x3B?

[brew]

I've never seen it on bnet, but i do see it being parsed at 1902D160 of battle.snp...
it appears to have a structure of:

(FILETIME) Filetime of patch?
(STRING) Name of patch?

The name is copied to a global char array.
After that, InitalizeDownloader is called, with the filetime and the name being passed to it.
also the fastcall params are:
ecx == 80000001h <--the BNFTP file request id (note on bnetdocs we only have 80000004 and 80000005)
edx == 3 <--- download type? maybe?

Since right after that call, the string "requesting latest version" passed to NotifyMsg, it's safe to name this packet SID_UPDATEREQ. or something.
Does anyone know more about it?

EDIT** i am assuming this was only for legacy (pre-xsha1 style) logons, since the same functionality can be achieved by parsing the extra info string in the 0x51 response, and an 0x33 request.

[MyndFyre]

So you're trying to name a packet, but you don't have... a packet?

You don't have a packet ID.
You don't have an observed packet dump of this happening.
Basically, all you do have is either a struct or a parameter list.

I mean, what are we supposed to name?

[brew]

I mean, what are we supposed to name?

We are supposed to name the aforementioned (probably defunct) packet that this topic is about. Obviously there is a packet... otherwise there would be no reason to parse it. I mean, where is the data that is parsed by this supposed to be coming from, pixie dust? People have most likely seen it before, but just was ignored. It's still nice to know about, am i right? The structure and purpose of this packet is quite obvious if you've looked at the code (and read my explanation). I've also observed the exact opposite-- the 0x4E packet is sent, but starcraft never parses it. Would you prefer to name a packet like that instead? It's much harder to document that than it is to document this.

[Kp]

The existence of parsing code doesn't necessarily mean it was ever used.  Some of the legacy clients have support for NLS, but it has never been activated.  I suggest leaving this as "legacy / not used" and move on to more interesting messages that're still in use.