lockdown-IX86-XX.mpq update?

[dope]

yes I'm logged on Europe with d2 on BNLS.

[Kp]

BNLS doesn't currently support mac in versioncheck, does it?

And why is the lockdown-IX86-XX.mpq timestamp necessary for determining checkrevision, shouldn't bnls have the timestamps already?

Unless you anticipate different versions of the mpq with the same filename but that doesn't make sense because of BNCache.dat (Blizzard wouldn't release an mpq with a conflicting filename in the event that a client uses the cache'd version and fails, i think?)

It's possible.  If the client does a strict equality check, it will recognize that the cached version is too new and download an older versioning library instead.  Even if it doesn't (i.e. it checks "age(cached) >= age(proposed)"), Blizzard might have different libraries on different clusters.  As long as clients stay on a single cluster, there'd be no problems.

[Skywing]

BNLS doesn't currently support mac in versioncheck, does it?

And why is the lockdown-IX86-XX.mpq timestamp necessary for determining checkrevision, shouldn't bnls have the timestamps already?

Unless you anticipate different versions of the mpq with the same filename but that doesn't make sense because of BNCache.dat (Blizzard wouldn't release an mpq with a conflicting filename in the event that a client uses the cache'd version and fails, i think?)

BNLS always uses the PC version check files, and all BNLS clients expect to receive version check data for PC version check files.  Switching it over to Mac would be a gross protocol violation with severe backwards compatibility implications.

The reason why the filetime and filename shall be sent to BNLS is so that BNLS always has the same amount of information that a real Battle.net-enabled game would get from Battle.net.  This allows for the ability to update BNLS (without altering any BNLS clients) to compensate for things that have previously required client-side changes to BNLS-enabled emulator clients.  It is primarily intended as a future-compatibility mechanism for any later changes made to the system by Blizzard.

[Ersan]

What format is the timestamp in?

[Skywing]

A count of 100-nanosecond intervals since Jan 01, 1601 UTC that is divided into two 32-bit halves.  You should be able to directly copy this data when sending it to BNLS.

[Ersan]

You could've said FILETIME

Oh it's in 0x50 s->c, nevermind all that.

[Hdx]

Just a little note, I don't want to start a big argument.
But 95% of my userbase is Stealthbot... So for the time being WC2, SC, D1, and SSHR report the mac revison.
Once we figure out how to implement the new lockdown-IX86 crev, I will revert everything back to IX86 files.
Tho, I will continue to support Power PC and OSX version checks along side IX86 in 0x1A. I don't see how this would break some backward compatibility.  (Yes it would make the user have to make a choice to use only my server for pmac connections... but I don't see a problem with that, but this is no more then adding more products)

Also, quick question? What would BNLS do when it encounters a PMAC/XMAC archive? just return failed?
On a lighter note: I have been working on lockdown... and i'm getting a better understanding, yet i'm still far off.
~-~(HDX)~-~

[Ersan]

Yeah are you going to support PMAC/XMAC archives in 0x1A?

[Skywing]

Not initially, as there is no reason to support them.  I may create a mechanism to request the Mac vercheck files, but I do not at present want to maintain both PC and Mac filesets.

[Newby]

This thread has been successfully transformed into the mac logon method thread. Fun.

You honestly didn't have faith in anyone here (besides a few) actually solving this, did you?

[Skywing]

BNLS support for the PC version check files is expected to be released today.

Client authors are encouraged to review the new BNLS_VERSIONCHECKEX2 message in the official protocol specification, which is the recommended way to use the new version check system.

For a select few products, BNLS will enable a compatibility mode where it will attempt to make a best guess as to which version check system is used (for the old messages supplying a dll version number).  It is recommended that clients transition to the new message for maximum future compatibility, however.  The new message will allow BNLS to adjust for any future changes to the version check system with a minimum chance of BNLS clients needing modifications.

Please note that at this time, there is no support for using the Mac version check files with BNLS.  The PC version check files are sufficient for use with BNLS, and there is no reason to maintain three parallel sets of version check files when one will suffice.

Therefore, any clients using BNLS should continue to assume that they are receiving version check data for the PC products and not Mac products.  As a result, I cannot recommend the use of third party servers that do not conform to the BNLS protocol and supply version check data for products associated with the wrong platform, as this is a breaking change that negatively impacts backwards compatibility with existing clients.

[Eric]

This thread has been successfully transformed into the mac logon method thread. Fun.

You honestly didn't have faith in anyone here (besides a few) actually solving this, did you?

I think that he's more concerned with the work ethic than the actual ability to produce.

[Ersan]

Skywing: You shouldn't be treating a filetime as a ULONGLONG, it can sometimes fault because of misaligned pointers when casting from filetime to ulonglong and it's not really correct.

[Skywing]

It is treated as two 32-bit halves by BNLS.

[Ersan]

k your doc says (ULONGLONG) Timestamp for version check archive.