BNLS_VERSIONCHECKEX, BNLS_VERSIONCHECKEX2: What's the difference?

[Hdx]

The reason 0x1a is good is that it is all the checkrevision information you need in one packet.
In theroy you could use BNLS for that packet and that one alone (Like Brew is doing with 0x09)
And I will repeat this again: 0x1A DOES SUPPORT ALL GAMES, IT IS THAT BNLS ITSELF (The Actuall local copy of the game) IS NOT PATCHED!
Brew, how would you obtain the updated verion byte?
How would you tell BNLS to use a spacific Checkrevision function (EXA: your users are connecting to a emu server)
This is how you should be useing BNLS if you JUST want the crev data:
    {
        1. Receive 0x50.
        2. Connect to BNLS.
        3. On BNLS connect, send the 0x1a.
        4. On data arrival, parse the 0x1a
        5. On parse 0x1a, the BNLS winsock is closed and the values of checksum, exeinfo, and exeversion are passed to Send0x51, The version byte is stored in the configuration file for future use.
        6. Send0x51 is sent to Battle.net.
    }
~-~(HDX)~-~

[brew]

cute....
the only thing I found different was a new verbyte. IN case there's ever an "in a blue moon" client update.

[Ersan]

Brew, you're an idiot, seriously.  Stop promoting outdated and soon-to-be-defunct methods.

[Don Cullen]

Was insulting really neccessary? Even if his methods were inefficent, was it really neccessary? Can't we just be professional here?

[Ersan]

No, I'm afraid the internets aren't serious business.

[Don Cullen]

It can be.

[Ante]

i always go with 0x18, and it always works.

0x1a is a waste of several extra bytes.

[Hdx]

how would you use it if bnet changed to randomly named mpqs?
for example:
pig.mpq
dog.mpq
monkey.mpq

Anyways, i'll try to refrane from posting ater my final comment.
BNLS_VERSIONCHECKEX2 was created so that bnls would have as much information as the game does.
It was created so that Skywing could be ale to simply update BNLS and all of the bot developers would NOT need to modify there products.
Which in turn saves  lot of hassel developer wise and consumer wise.
There is a prime examle right now.
StealthBot is widly used, but there are two versions of it out.
The oly diffrence is how t grabs the mpq archive id.
It woud be much less hassel just to sa something like the following:
Bnet has made some changes to it's method to verrify yu are useing the latest version f there game, so if you are getting te error [BNET] Version CheckFailed, please be patient, we are working on it.

And the other post being:
Bnls has beenupdated to reflect recet changes, your bots should now be working.

Its allment to make life easier even if right now its a waste of a FEW bytes.
~Hdx

[UserLoser]

how would you use it if bnet changed to randomly named mpqs?
for example:
pig.mpq
dog.mpq
monkey.mpq

Anyways, i'll try to refrane from posting ater my final comment.
BNLS_VERSIONCHECKEX2 was created so that bnls would have as much information as the game does.
It was created so that Skywing could be ale to simply update BNLS and all of the bot developers would NOT need to modify there products.
Which in turn saves  lot of hassel developer wise and consumer wise.
There is a prime examle right now.
StealthBot is widly used, but there are two versions of it out.
The oly diffrence is how t grabs the mpq archive id.
It woud be much less hassel just to sa something like the following:
Bnet has made some changes to it's method to verrify yu are useing the latest version f there game, so if you are getting te error [BNET] Version CheckFailed, please be patient, we are working on it.

And the other post being:
Bnls has beenupdated to reflect recet changes, your bots should now be working.

Its allment to make life easier even if right now its a waste of a FEW bytes.
~Hdx

Quit giving Blizzard ideas!

[Don Cullen]

Easiest way to do it is using the FILETIME struct which is two Long values. it's basically two DWords (A QWord, I think?). Just remember not to flip the high and low values.

So basically, I extract it in this exact order:

MPQLow = PktDeBuf.rDWORD
MPQHigh = PktDeBuf.rDWORD

Then when I send it to BNLS, it's done via

.InsertDWORD MPQLow
.InsertDWORD MPQHigh

This way, I'll avoid flipping it, right?

[UserLoser]

If you're using BNLS, you should actually be treating the archive FILETIME structure as an unsigned 64-bit integer instead.

[Don Cullen]

Explain please.

[Edited to add 'please']

[UserLoser]

Explain.

Don't copy the eight bytes from SID_AUTH_INFO into a Win32 FILETIME structure.  Just extract the eight bytes instead into an unsigned 64-bit (8-byte) integer.  This will ensure you that you will always be sending proper data to the BNLS server.

[Don Cullen]

I apologize for being stupid.

That being said, how exactly would I extract them into an unsigned 64 bit integer?

[UserLoser]

I apologize for being stupid.

That being said, how exactly would I extract them into an unsigned 64 bit integer?

Pretty much the same exact way you extracted the values into the FILETIME structure.  Just use a proper datatype