SC2/D3 speculation thread

[Camel]

Things I'm particularly interested in include statstrings, which namespace the accounts will belong to, and login procedure (presumably NLS?). Has anyone heard any good rumors, or disassembled any interesting binaries?

From what I've heard, BNCS is going to be seeing a huge amount of new stuff for SC2.

[Hdx]

Well lets jsut assume they are gunna use NLS v3.
When ti comes to statstrings, I'm going the whole WC3 style for SC and D2 style for D3.
I dont feel like looking, anyone got a firm release date for SC?

[warz]

i speculate everything is doing to use an xml-based protocol. it'll all use udp, too. udp without tcp-mimicing features. it'll use another modified SHA-1.

this is pure speculation, though.

[topaz~]

Using XML would be pure stupidity.

[warz]

Oh, I forgot to mention that I also speculate that it will bring back channel warring.

[iago]

Using XML would be pure stupidity.

Explain.

[Camel]

Using XML would be pure stupidity.

Explain.

It would violate one of the primary laws of physics: blizzard makes no effort to support the botdev community.

[iago]

Using XML would be pure stupidity.

Explain.

It would violate one of the primary laws of physics: blizzard makes no effort to support the botdev community.

That doesn't make using XML stupidity, it makes it unlikely.

[MyndFyre]

Using XML would be pure stupidity.

Explain.

It would violate one of the primary laws of physics: blizzard makes no effort to support the botdev community.

That doesn't make using XML stupidity, it makes it unlikely.

Come on iago.  If a game action required a single byte of data, XML would require it to be wrapped in 30-40 bytes of text.  It's a waste.

[Camel]

Could you even do XML over UDP? Doesn't UDP not guarantee that order is preserved?

[iago]

Come on iago.  If a game action required a single byte of data, XML would require it to be wrapped in 30-40 bytes of text.  It's a waste.

We're talking about chatting, not about games.

They already send a whackload of metadata with one byte of data. With XML, it would be more expandable, so when they decide to add new features in the future they wouldn't have to hack on a new packet or pad an empty field with 0xbaadf00d anymore. Right now, they're stuck with the identical packets they used 10 years ago.

[Camel]

We're talking about chatting, not about games.

Actually, looking back at the thread, that isn't entirely clear. If we're talking about chatting, XML makes sense. If we're talking about gaming, it does not (because the game protocols are program-specific, and can be kept in sync with the server more easily).

[Joe]

Come on iago.  If a game action required a single byte of data, XML would require it to be wrapped in 30-40 bytes of text.  It's a waste.

We're talking about chatting, not about games.

They already send a whackload of metadata with one byte of data. With XML, it would be more expandable, so when they decide to add new features in the future they wouldn't have to hack on a new packet or pad an empty field with 0xbaadf00d anymore. Right now, they're stuck with the identical packets they used 10 years ago.

I speculate that over the next short while, all SID_AUTH system games (everything except for Diablo 1?) will download their Battle.net libraries over BNFTP as part of the logon sequence. That way, only SID_AUTH_INFO, SID_AUTH_CHECK, and BNFTP_* need to remain constant, and Blizzard can fuck up anything else they please.

EDIT -
And as I explained in the other thread, I feel that SID_AUTH_CHECK was designed pretty well and should have no trouble supporting either new game.

[MyndFyre]

Come on iago.  If a game action required a single byte of data, XML would require it to be wrapped in 30-40 bytes of text.  It's a waste.

We're talking about chatting, not about games.

They already send a whackload of metadata with one byte of data. With XML, it would be more expandable, so when they decide to add new features in the future they wouldn't have to hack on a new packet or pad an empty field with 0xbaadf00d anymore. Right now, they're stuck with the identical packets they used 10 years ago.

Eh, I don't know that that's true.  Depending on the structure of the client handler, the server could potentially send more data than the client handler expects.  For example, supposing they send a packet with header length of 40, but only 25 bytes is used (by the version defined by older clients).  Newer clients can recognize that the actual length of the packet is longer and know to take some action with the rest of the data.  Nothing has to be done with special markers or anything like that.

[Camel]

Didn't the botdev community decide that they most likely only bothered to switch to NLS because of some obscure security flaw -- something that the SID_AUTH_*PROOF packets were supposed to take care of? I don't even remember what information they prove, but I am correct in my assumption, then it seems rather unlikely that they will re-reinvent the login sequence, as far as the packets that are used. We may well see a new version of NLS, though.

[edit] Am I correct in inferring that the client silently discards the unused portion of the packet buffer? I tend to verify that my buffers are empty post-processing for debugging purposes (raise a warning, but continue anyways) for most of my packet handlers.