Valhalla Legends Archive

Hey, i need the connection sequence for Extra High Latency... to connect to battle.net.

- VB6

SEND 0x50
RECV 0x25
wait a long time
SEND 0x25

Quote from: Camel on September 13, 2003, 04:52 PM
wait a long time

lol...usually everything is so technical sounding, now it's plain-english...this will take some getting used to.

Hahaha...

Ummm should i use Kernel32's Sleep for the "Long Wait"

Just use this to wait when you receive 0x25.

Sub Pause(ByVal fSeconds As Single, Optional ByVal AllowEvents As Boolean = True)
   Dim fTimer As Single
   If AllowEvents Then
       fTimer = Timer
       Do While Timer - fTimer < fSeconds
           Sleep 100
           DoEvents
           If Timer < fTimer Then
             fTimer = fTimer - 86400
           End If
       Loop
   Else
       Sleep fSeconds * 1000
   End If
End Sub

It would be better to create a null event, and use WaitForSingleObject(DWORD time);.  That way the process will enter a kernel wait mode and wont' take up any cpu cycles till the time runs out.

Is that more technical, the way you wanted it?

Quote from: iago on September 14, 2003, 08:35 AM
Is that more technical, the way you wanted it?

No.  

Quote from: iago on September 14, 2003, 08:35 AM
It would be better to create a null event, and use WaitForSingleObject(DWORD time);.  That way the process will enter a kernel wait mode and wont' take up any cpu cycles till the time runs out.

Is that more technical, the way you wanted it?

It would be best to use MsgWaitForMultipleObjects with a zero object count (yes, this works).  Then, use DoEvents when woken for a message-queue related reason.  Remember to adjust the wait time each re-wait.

Quote from: Skywing on September 14, 2003, 11:37 AM

Quote from: iago on September 14, 2003, 08:35 AM
It would be better to create a null event, and use WaitForSingleObject(DWORD time);.  That way the process will enter a kernel wait mode and wont' take up any cpu cycles till the time runs out.

Is that more technical, the way you wanted it?

It would be best to use MsgWaitForMultipleObjects with a zero object count (yes, this works).  Then, use DoEvents when woken for a message-queue related reason.  Remember to adjust the wait time each re-wait.

Ah, I didn't know you could do that!

And I assumed he was using multiple threads, so he wouldn't require a doevents since the message-queue would still be processing

...or you could just use sleep...

Quote from: St0rm.iD on September 14, 2003, 07:48 PM
...or you could just use sleep...

This is a Bad Idea if you have a GUI because to the user the program will appear to have completely stopped responding.  They may give up and try to end-task it as a result due to the window not being moveable or sizeable and not painting itself.

Quote from: Skywing on September 14, 2003, 09:15 PM

Quote from: St0rm.iD on September 14, 2003, 07:48 PM
...or you could just use sleep...

This is a Bad Idea if you have a GUI because to the user the program will appear to have completely stopped responding.  They may give up and try to end-task it as a result due to the window not being moveable or sizeable and not painting itself.

They wouldn't be able to move it very far while sleeping one second anyway.

Using sleep and doevents has been discussed before: here.

Quote from: Camel on September 15, 2003, 02:40 PM
Using sleep and doevents has been discussed before: here.

It might be worth noting that there are a fair amount of inaccurate statements there.

DoEvents doesn't have all that much in common with Sleep - the documentation says that it only "processes any Windows messages currently in the message queue".  This implies that there is no wait involved, and thus no giving up the thread timeslice early for a different thread.  A loop with only DoEvents should cause the program to use a fair amount of CPU because it won't relinquish its timeslice early.

Sleep, on the other hand, actually blocks the thread in such a way that the thread scheduler simply does not consider it as a candidate for running until the wait interval has expired.  Even if your thread were the only thread in the system (which is impossible, because there are a number of kernel mode threads required for the system to run), the kernel idle loop should be getting processor time (and not your thread) while execution is being blocked.

#define DoEvents while(GetMessage(&msg)) DispatchMessage(&msg);

Well, add something to stop it from sitting there forever...