Ok, I'm not sure if this is on topic for this forum, but I was reading the BNLS Prot Spec (http://www.valhallalegends.com/yoni/BNLSProtocolSpec.txt) and I noticed something odd...
It claims that using BNLS_VERSIONCHECKEX2 (0x1A) will
[code]
request the current version code for the given product (eliminating the need for BNLS_REQUESTVERSIONBYTE)
[/code]
And I'm not sure I understand the purpose...
In order to get the reply from this packet and actually use the versionbyte from it, is to send the packet with the data received from SID_AUTH_INFO which is the only place you need the version byte (AFAIK), so why does this packet send the versionbyte, and why does it state that it eliminates the need for BNLS_REQUESTVERSIONBYTE?!?!
Can someone shed some light? Or maybe revise the Protocol Spec? thx

Send the cached one your bot has.
Then if you receive a different one in 0x1a, store the one you received, and then reconnect.
OR If you are using an older client, (Like JSTR) the verbyte is sent after you receive the vercheck info.
etc...
It would have more purpose if BNLS ever supports DRTL or the correct W2BN login sequence.
But as of now it really doesn't have any benefits.
~-~(HDX)~-~

Thanks Hdx,
That makes a little more sense, but the real question behind it is I guess, why did they actually state that it would eliminate the need for BNLS_REQUESTVERSION when in fact, it doesn't do that at all...

[quote author=Hdx link=topic=16072.msg161691#msg161691 date=1164344600]if you receive a different one in 0x1a, store the one you received, and then reconnect.[/quote]
That eliminates the need for 0x10.
The verbytes RARLY change (only like every other patch)
~-~(HDX)~-~

If the verbyte DID happen to change, and you were still using 0x1a, you would never obtain the newest version byte because you 'eliminated' 0x10 ;)

No.... Thats why you STORE IT
You get the latest VB in 0x1a....
~-~(HDX)~-~

how do you get the latest versionbyte from 0x1a if you can't send it without the current version byte. (because of the need to send 0x50 first)

[code]BNCS Connect
BNCS C->S 0x50 Config.VerByte
BNCS S->C 0x50
BNLS Connect
BNLS C->S 0x1A
BNLS S->C 0x1A
  If 0x1A.VerByte != Config.VerByte Then
    Config.VerByte = 0x1A.VerByte
    Connection.Reconnect()
  Else
    BNCS C->S 0x51
  End If[/code]

Understand now?
~-~(HDX)~-~

... I never didn't understand.
I don't think you do though.
[quote author=Hdx link=topic=16072.msg161698#msg161698 date=1164347260]
[code]BNCS Connect
BNCS C->S 0x50 Config.VerByte
BNCS S->C 0x50
BNLS Connect
BNLS C->S 0x1A
BNLS S->C 0x1A
  If 0x1A.VerByte != Config.VerByte Then
    Config.VerByte = 0x1A.VerByte
    Connection.Reconnect()
  Else
    BNCS C->S 0x51
  End If[/code]

Understand now?
~-~(HDX)~-~
[/quote]

S->C 0x50?
The server wouldn't send you the data you need in order to proceed, it would tell you that the game version is out of date because the versionbyte is old.

Yes it will.
Even if the verbyte is old, it still sends you everything the client needs to send 0x51.
AND THEN in 0x51 S->C it tells you you are outdated.

~-~(HDX)~-~

Thanks Hdx, I was completely unaware of that :-D
That will help out in my connection process ^^
<3

Think of it logically next time!
If the client is old, how would it know what file to download to patch?
The file name is sent in 0x51 S->C(Extra info string at the end of the packet)
And that is only sent when the server gets 0x51 C->S....
Also, TEST for yourself next time!
~-~(HDX)~-~

Why do people put version bytes in their configs for bots ;-p

[quote author=BaDaSs link=topic=16072.msg161707#msg161707 date=1164351103]
Why do people put version bytes in their configs for bots ;-p
[/quote]

Because they don't all use BNLS.

Hdx is correct.  This feature of BNLS_VERSIONCHECKEX2 is intended to be used as an optimization to eliminate an extra potential round trip time per logon that is used to retrieve a value which very infrequently changes.

The intended use is that clients should persist the last known version code value for each product.  When using BNLS, if a client receives a different version code in response to BNLS_VERSIONCHECKEX2, then it should drop and reconnect the affected Battle.net connection (instead of sending the SID_AUTH_CHECK request to Battle.net), and update its persisted copy of that product's version code.  The next connection attempt with that product should use the new version code supplied in the previous BNLS_VERSIONCHECKEX2.

Because the frequency of patching games vs logging on to a game with a client emulator is such that logging on is by the vast majority the common case, using this scheme can cut down on time to complete a Battle.net logon (and bandwidth overhead with respect to communicating with BNLS) in the common case of logging on after a previously successful logon, where the product in question has not just been patched.

The old mechanism required clients to request the latest version code explicitly on every logon attempt if they wished to use that mechanism to keep their version codes up to date automagically.  While you could previously achieve a similar effect by sending a BNLS_VERSIONCHECK and BNLS_REQUESTVERSIONBYTE simultaneously without waiting for a response on either, going this route 1) significantly increases the complexity of clients due to the asynchronous nature of BNLS responses (you must be careful to handle the case of BNLS_VERISONCHECK or BNLS_REQUESTVERSIONBYTE coming back in different orders than the one with which they were originally sent), and 2) reduces bandwidth overhead, as the overhead of sending an extra BNLS_REQUESTVERISONBYTE and receiving the response is now condensed into a single four-byte field.  With the new-style combined message, you now only need to wait for one message instead of two (thus freeing the programmer from request/response ordering concerns), and you get all of the information that you would need all in one shot, making handling the message an easier process to manage.

BNLS_REQUESTVERSIONBYTE is still supported for backwards compatibility purposes, but if you are writing a new client (or significantly altering an already-existing client), it is in general to your advantage to combine these two operations using BNLS_VERSIONCHECKEX2 if you are already using BNLS for both retrieving the latest version code and running version checks.