SRL Archive - SRL Development and Help

I have been using SPS fine for months now, last successful time was yesterday..

however, now walkPath only clicks the first coordinate in the array, and just stops.. I debugged SPS and it is working/getting position properly. I have tested it multiple times with different coordinates and maps..I really do not know what is going on..

as I said, iv been botting for awhile, today is the first time this has occurred..

Any help is great and is it working for everyone else?

well I figured it out..

it was the one thing I did not debug: t := (getSystemTime() + randomRange(15000, 20000));

I switched it to a TTimeMarker, still no idea why it was broken though..but the getsystemtime was messing up somehow and breaking out of the loop

From: Zef Style

it was the one thing I did not debug

We all know that feel ;)

From: Zef Style
well I figured it out..

it was the one thing I did not debug: t := (getSystemTime() + randomRange(15000, 20000));

I switched it to a TTimeMarker, still no idea why it was broken though..but the getsystemtime was messing up somehow and breaking out of the loop

Can you post your walking code please?

From: The Mayor
Can you post your walking code please?

It was happening with SRL's walkPath as well as my own..error was the same in both cases

From: Zef Style
It was happening with SRL's walkPath as well as my own..error was the same in both cases

Oh you mean the t := (getSystemTime() + randomRange(15000, 20000)); inside the sps.walkPath( ) function?

From: The Mayor
Oh you mean the t := (getSystemTime() + randomRange(15000, 20000)); inside the sps.walkPath( ) function?

yes, it was very odd

From: Zef Style
yes, it was very odd

Issue is that `t` is stored as a signed integer, so when it overflows (after your computer has been up for 25 days) it will "wrap around" to a negative number causing the timer to fuck up big time. `t` should be stored as UInt32 (unsigned integer) so that it wraps around to 0 (after about 50 days).
Tho best fix would be to use GetTickCount64 and store it as 64 bit integer (I assume TTimeMarker uses GetTickCount64), which will avoid any overflow.

From: slacky
Issue is that `t` is stored as a signed integer, so when it overflows (after your computer has been up for 25 days) it will "wrap around" to a negative number causing the timer to fuck up big time. `t` should be stored as UInt32 (unsigned integer) so that it wraps around to 0 (after about 50 days).
Tho best fix would be to use GetTickCount64 and store it as 64 bit integer (I assume TTimeMarker uses GetTickCount64), which will avoid any overflow.

Yes, TTimeMarker supports proggies longer as runescape will probably exist.