SVN 394 / new exp function give error player.lua 1514

[d003232]

Now I get the second time a 'player.lua:1514: attempt to compare number with string' error. Seems that there should be some more check to avoid wrong data from RoMScript?

I was sitting on front of the PC. Don't touching the keyboard and see that error happens while my character was in the middle of a fight.

[Perfectworld]

That's right, use 'toNumber(maxExp)' instead of 'maxExp' at line 1532 of player.lua (self.TimeTillLevel = (maxExp - newExp) / self.ExpPerMin;).

[Administrator]

More information is needed. How often does this happen? How do you reproduce it? Apparently, one (or both) of the values is a string, so what does it contain? I can only assume it is a blank string, therefor it cannot be converted to a number. In this case, it will need to assume default values. I've already committed a change for this.

[Perfectworld]

More information is needed. How often does this happen? How do you reproduce it? Apparently, one (or both) of the values is a string, so what does it contain? I can only assume it is a blank string, therefor it cannot be converted to a number. In this case, it will need to assume default values. I've already committed a change for this.

This happens everytime when the bot recalculates the EXP, and yes, it works, since I had the same error and fixed it. But this is more of a short-fix, since it should never return a String since it only can contain numbers.

[d003232]

More information is needed. How often does this happen? How do you reproduce it? Apparently, one (or both) of the values is a string, so what does it contain? I can only assume it is a blank string, therefor it cannot be converted to a number. In this case, it will need to assume default values. I've already committed a change for this.

I had the problem 3 times this afternoon. I was running at 100% CPU (my Seti client was running) and I started a second RoM window. After that I inserted a debuging line to get more information. But I don't the error again. But I don't was running at 100% CPU. My speculation is, that I perhaps get back an old RoMScript value. Simply because RoMScript was not executed (because of the 100% CPU) and the bot reads old macro 2 values (some string from the inventory update). If so it would be a good solution, as you said, to take default values if we get back invalid data.