[8:28:21 PM] /ban owdei@USWest Locked
[8:28:21 PM] ÁY !!!! !!! !!!! !!!!!
[8:28:21 PM] ÁY ! ! ! ! ! ! !
[8:28:21 PM] ÁY !!!! !!!!! !!!! !!!!!
[8:28:21 PM] ÁY ! ! ! ! ! !
[8:28:21 PM] ÁY ! ! ! ! ! !!!!!
[8:28:21 PM] That user is not logged on.

This is what it looked like when i tested my bot on the fastest flooder i can find. I see its trying to ban before the spam, but it doesnt respond till its done. Would the be at fault of bnet laggin a little bit?

It's a fault of it being impossible to ban the spammer - the spammer disconnects before your ban reaches battle.net. Add millisecond timestamps to your output and you'll probably see why.

[quote author=Gangz link=board=17;threadid=4602;start=0#msg38411 date=1073277278]
[8:28:21 PM] /ban owdei@USWest Locked
[8:28:21 PM] ÁY !!!! !!! !!!! !!!!!
[8:28:21 PM] ÁY ! ! ! ! ! ! !
[8:28:21 PM] ÁY !!!! !!!!! !!!! !!!!!
[8:28:21 PM] ÁY ! ! ! ! ! !
[8:28:21 PM] ÁY ! ! ! ! ! !!!!!
[8:28:21 PM] That user is not logged on.

This is what it looked like when i tested my bot on the fastest flooder i can find. I see its trying to ban before the spam, but it doesnt respond till its done. Would the be at fault of bnet laggin a little bit?
[/quote]
Ofcourse your client is going to show the /ban message before the chat messages come up, that takes less than a millisecond - But to send the message to the battle.net server would take about as many milliseconds as your ping time is


Edit: bleh, posted this without reading Adron's response

Both links contain VB6 Source and a compiled version for people who do not have VB6 compiler.

Records GetTickCount when user joins.
Sends /ban username.
And when bnet responds..
It takes current GetTickCount and subtracts the recorded GetTickCount and displays the result in the titlebar.
http://www.sacred-soldiers.com/krazyturtles/BanResponse.zip
Tried my best to ban a flooder.. but I'm only a 56k user.
Maybe someone with a faster connection might get lucky and ban one for me. ;D

Records GetTickCount when user joins.
When user leaves..
It takes current GetTickCount and subtracts the recorded GetTickCount and displays the result in the titlebar.
http://www.sacred-soldiers.com/krazyturtles/WatchJoinLeave.zip

GetTickCount() is a low resolution counter - you should use your system's high performance counter (QueryPerformanceCounter(), QueryPerformanceFrequency()) for better accuracy.

I'm not quite sure what you hope to accomplish with this, though.

[quote author=Arta[vL] link=board=17;threadid=4602;start=0#msg39015 date=1073670649]
GetTickCount() is a low resolution counter - you should use your system's high performance counter (QueryPerformanceCounter(), QueryPerformanceFrequency()) for better accuracy.
[/quote]


Thanks for the tip :)

I'll go look up on it now since you suggested it..
but how far off can the results be?
I read up on high resolution counters before but never used them because it was generally for multimedia applications.
Does a high performance counter have cons?
Eats more processor time perhaps..
Why is there a lower resolution counter when there is a better one to be used..

Just thoughts that crossed my mind.. thanks for the tip Arta.
Did you look at the source?
Any change in code to improve the speed would be appreciated.

[quote]
I'm not quite sure what you hope to accomplish with this, though.
[/quote]

Well..
I got curious.
It was in response to Adron's suggestion of placing a timestamp with milliseconds for output.

[quote author=krazyturtles link=board=17;threadid=4602;start=0#msg39022 date=1073671675]
but how far off can the results be?
I read up on high resolution counters before but never used them because it was generally for multimedia applications.
Does a high performance counter have cons?
Eats more processor time perhaps..
Why is there a lower resolution counter when there is a better one to be used.[/quote]

The low resolution timer (GetTickCount()) has a precision of approximately 16ms on NT kernels and 55ms on 9x kernels IIRC. The high performance counter's main con is that, as a 64bit integer, it could be more difficult to deal with. Also, some systems supposedly don't support it, but I've never actually seen one.

[quote author=Kp link=board=17;threadid=4602;start=0#msg39023 date=1073672044]
[quote author=krazyturtles link=board=17;threadid=4602;start=0#msg39022 date=1073671675]
but how far off can the results be?
I read up on high resolution counters before but never used them because it was generally for multimedia applications.
Does a high performance counter have cons?
Eats more processor time perhaps..
Why is there a lower resolution counter when there is a better one to be used.[/quote]

The low resolution timer (GetTickCount()) has a precision of approximately 16ms on NT kernels and 55ms on 9x kernels IIRC. The high performance counter's main con is that, as a 64bit integer, it could be more difficult to deal with. Also, some systems supposedly don't support it, but I've never actually seen one.
[/quote]

The stuff you say about different resolutions sound familar.
I run Windows ME (it's Windows 98 with new features)
and on one of my test runs a result came out at 16ms.
Does Windows ME have a tick resoulution equivalent to NT?

[quote author=krazyturtles link=board=17;threadid=4602;start=0#msg39026 date=1073672864]
The stuff you say about different resolutions sound familar.
I run Windows ME (it's Windows 98 with new features)
and on one of my test runs a result came out at 16ms.
Does Windows ME have a tick resoulution equivalent to NT?[/quote]

I don't know. I've never used WinME and advise that you stop using it as soon as possible. It's a horrible OS. Switch to an NT-derived kernel. :P

[quote author=krazyturtles link=board=17;threadid=4602;start=0#msg39026 date=1073672864]
[quote author=Kp link=board=17;threadid=4602;start=0#msg39023 date=1073672044]
[quote author=krazyturtles link=board=17;threadid=4602;start=0#msg39022 date=1073671675]
but how far off can the results be?
I read up on high resolution counters before but never used them because it was generally for multimedia applications.
Does a high performance counter have cons?
Eats more processor time perhaps..
Why is there a lower resolution counter when there is a better one to be used.[/quote]

The low resolution timer (GetTickCount()) has a precision of approximately 16ms on NT kernels and 55ms on 9x kernels IIRC. The high performance counter's main con is that, as a 64bit integer, it could be more difficult to deal with. Also, some systems supposedly don't support it, but I've never actually seen one.
[/quote]

The stuff you say about different resolutions sound familar.
I run Windows ME (it's Windows 98 with new features)
and on one of my test runs a result came out at 16ms.
Does Windows ME have a tick resoulution equivalent to NT?
[/quote]

From MSDN:

[quote]
Platform SDK: Windows System Information
Windows Time

Windows time is the number of milliseconds elapsed since the system started running. This format exists primarily for backward compatibility with 16-bit Windows. To ensure that applications designed for 16-bit Windows continue to run successfully, the GetTickCount function returns the current Windows time.


You typically use GetTickCount to compare the current Windows time with the time returned by the GetMessageTime function. GetMessageTime returns the Windows time when the specified message was created. GetTickCount is limited to the resolution of the system timer.

The system timer runs at approximately 10ms.


Windows Me/98/95: The system timer runs at approximately 55ms.



Windows NT 3.1: The system timer runs at approximately 16ms.



If you need a higher resolution timer, use a multimedia timer or a high-resolution timer.

Windows time is stored as a 32-bit value, which means the system can record no more than 2^32 millisecond intervals before the 32-bit value overflows to zero. This is approximately 49.7 days. If you use Windows time, check for the overflow condition when comparing times.

You can use the System Up Time performance counter to obtain the time elapsed since the computer was started.
[/quote]

Thanks for the Input guys. :)

Found a link on the topic and posting it for others who might be interested.

http://www.vb2themax.com/Item.asp?PageID=TipBank&ID=244

[quote]
32-bit value overflows to zero
[/quote]

I'm not clear on the wording ..
Does that mean it starts over at 0 ?

What if I add a value that puts the result beyond the 32-bit value's limit. Crash? Or will IT overflow to zero as well?


I read up about Long number types.

I learned VB6 doesn't have conventional support for unsigned Long meaning the type is limited to 31-bits.. 1-bit is reserved for sign.
http://forums.devshed.com/archive/52/2003/10/3/92334
(Correct me if I'm wrong please.)

So this means GetTickCount's return is limited to a 31-bit value?
2,147,483,647 is GetTickCount's limit?
It start over at 0 when the limit is reached?

Sorry this is so off topic but it is related to the timing for ban.[quote][/quote]

In VB, GetTickCount returns the most negative Long right after it has returned the most positive Long (or would, if it returned every tick, seems to increase by 7 or 8). That is, it wraps around like you'd expect. The hexadecimal sequence is 0, 1, ... 7ffffffff, 80000000, ..., ffffffff, 0, 1, ...

In an unsigned long, those values are all positive. In a signed long, 80000000 is -2147483648 and ffffffff is -1.

You typically have wraparound which means that adding 6 to (largest number - 2) makes 3 (wrapped around). For GetTickCount, you assume that it increases by one every ms, and as long as you're only adding one at a time, overflow to zero and wraparound means the same thing.

[Kp edit: resaved post with "no smilies" box checked so that 8) stays as such.]