SRL Archive - Help

Hey all.

Had this question sitting in the back of my mind for awhile now, how come some if not most scripts seem to go into a negative xp /hr or xp gained after a long runtime?

eg:


Just wanting to know the reason behind this and if there is a way to prevent this?

Isn't this because the xp bar that the script is reading goes above the greatest number that simba can calculate and therefore the maths screw up?

From: P1ng
Isn't this because the xp bar that the script is reading goes above the greatest number that simba can calculate and therefore the maths screw up?

Indeed.

From: P1ng
Isn't this because the xp bar that the script is reading goes above the greatest number that simba can calculate and therefore the maths screw up?

Since simba is running on 32bit, wouldn't the max number be 2,147,483,647?
XP bar is just shy of 117m.

Then why over time the Exp per hour goes down, (Currently at -75477)

From experience, it seems to happen when OCR fails to read the XP on the bar properly.
You could spend some time to create a failsafe for that.
(ie. store the initial value to an integer, then compare every reading with that, and only use the reading if it is bigger than the initial value)

From: litoris
From experience, it seems to happen when OCR fails to read the XP on the bar properly.
You could spend some time to create a failsafe for that.
(ie. store the initial value to an integer, then compare every reading with that, and only use the reading if it is bigger than the initial value)

^ Was happening constantly to my encahnting script's proggy after about 15 hours, I just find the intial amount of XP and Store it for the current player :P then reference that like litoris said

I can assure you this has nothing to do with the XP bar. None of my scripts determine XP based on the XP bar, yet after 10+/20+ hour runs I'll also have -XP/Hour.

From: Flight
I can assure you this has nothing to do with the XP bar. None of my scripts determine XP based on the XP bar, yet after 10+/20+ hour runs I'll also have -XP/Hour.

:O very weird

Numerical overflow occurs.

From: Shay
Numerical overflow occurs.

What if you made an array that filled a different point after every x hours, then added them together? Could it handle the simpler math that way?

No need, the script is coded incorrectly.

XPH := Round(XP * (3600.0 / (GetTimeRunning / 1000.0)));


Is how it should be. I know I used to do
Sec:= (1+((Getsystemtime-StartTime)/1000));
XPH := (3600*XP) / (SeC);

which gave me the negative integer error.

From: Shay
No need, the script is coded incorrectly.

XPH := Round(XP * (3600.0 / (GetTimeRunning / 1000.0)));


Is how it should be. I know I used to do
Sec:= (1+((Getsystemtime-StartTime)/1000));
XPH := (3600*XP) / (SeC);

which gave me the negative integer error.

we should be lookin at the root issue, not just creating ways to bypass it. the second equations is mathmatically correct (as far as i can see). the picture above looks like my script, so in most of my scripts, i use:

ExpPerHour := (3600*Exp) / ((Getsystemtime-StartTime)/1000+1);

so that is:

3600*(GetXPBarTotal-StartExp)
-----------------------------------
(Getsystemtime-StartTime)/1000+1

for this to be a negative number, one side of the equation (ether numerator or denom.) would have to be a negative number. so lets look at this one by one:

3600*(GetXPBarTotal-StartExp)
StartExp := GetXPBarTotal; //called at the  beginning of script

StartExp is called and set at the beginning of the script, and is never changed by a mutator method. so if you can get a positive integer off of this, then that means that this part of the equation will correctly display a positive integer. this is because i only use GetXPBarTotal, and if it works correctly in the beginning, it should work correctly every time.

(Getsystemtime-StartTime)/1000+1
StartTime := GetSystemTime;  // called at the beginning of script

once again, i never reset StartTime. It is called at the beginning of the script, and does not change. It uses GetSystemTime, and if that is correct, then it should be correct every time. If GetSystemTime is correct, then i do not see how this equation could be a negative number.



with that said, i do not see how either part of the equation can be a negative number. only four scenarios could occur to create the error:
1. I somehow messed up on my math, if so, please explain how as that equation looks solid to me.
2. GetSystemTime has a bug that will return a negative/small number at times.
3. GetXPBarTotal has a bug that will return a negative/small number at times.
4. numerical overflow error, so maybe use a Int64?

I remember when people were getting 50h runs on mine it would change the xp/h from 22000 to -310. At someones suggestion I just changed the way I calculated it and it fixed it. Kinda like what Shay said.

From: BMWxi
I remember when people were getting 50h runs on mine it would change the xp/h from 22000 to -310. At someones suggestion I just changed the way I calculated it and it fixed it. Kinda like what Shay said.

XD im totally fine with changing it, and i will change them on my comp, but i am very curious as to why this error occurs. as explained above, i see no reason as to why it is occurring.

From: x[Warrior]x3500
XD im totally fine with changing it, and i will change them on my comp, but i am very curious as to why this error occurs. as explained above, i see no reason as to why it is occurring.

http://villavu.com/forum/showthread.php?t=93295

I think Footballjds had it right, I still don't really understand why though :p

@Warrior
Dunno man, I use the same equation as you and always used to get a - number..
I assume that using an Int64 would solve it though

Wait so which one is the working equation?

From: litoris
Wait so which one is the working equation?

ExpPerHour := (3600*Exp) / ((getTimeRunning)/1000);

lol, ^ is what has been in my private library (for all scripts that arent my public ones) for months now XD. guess i forgot to update some things on my public scripts.

var
  GAINED_EXP,
  EXP_PER_HR,
  TIME_RAN: integer;

begin
  clearDebug;
  GAINED_EXP := 800000; // 800k exp gained
  TIME_RAN := (1000 * 60 * 60 * 14); // theoretical 14 hours

  EXP_PER_HR := Round(  (3600*GAINED_EXP) / ((TIME_RAN)/1000)   );
  writeln('exp per hr 1, x[Warrior]x3500''s post:');
  writeln(EXP_PER_HR);

  writeln('');
  writeln('');

  EXP_PER_HR := Round(GAINED_EXP * (3600.0 / (TIME_RAN / 1000.0)));
  writeln('exp per hr 2, Shay'' post:');
  writeln(EXP_PER_HR);
end.

results (for me);

exp per hr 1, x[Warrior]x3500's post:
-28074


exp per hr 2, Shay' post:
57143
Successfully executed.

ahh well both me and footbaljds (in the link above) are incorrect. might as well change things over, never had issues with it though

I found doing

 var 
 ms, xph: extended;

 
 xph := (xp)/(ms/1000/60/60);
 Writeln('Exp per hour: ' + ToStr(round(xph)));

Works :) You don't have to multiply the xp by a number especially by 3600. You do that and it'll screw things up eventually. easier just to divide by numbers to make the number even smaller.

Edit- Btw to verify myself the whole 800,000 * 3,600 = 2,880,000,000 I think is what's throwing that off?

Sweet, Thanks for the replies, ill be adding 'Round' to the procedure

From: x[Warrior]x3500
ahh well both me and footbaljds (in the link above) are incorrect. might as well change things over, never had issues with it though

no. I was right.